[whstl]

I also enjoy improving bad software, high five.

But funny: I was trying to think of "good" systems that I ever worked on, but drew a blank. It can't be that I only worked on bad code, right? Maybe this is one of those "when everyone around you is an asshole..." situations!

But now that I actually think deeper about it, the reason I don't remember doing a lot of work in good systems is because I barely had to touch them. They just worked, scaled fine, required very little maintenance.

And on those good systems, building new features was painless: they were always super simple and super familiar to newcomers (using default framework features instead of fancy libraries), because they never deviated from the norm. Things would also pretty much never break because there were failsafes (both in code/infra/linters/etc and in process, like code review).

At my previous job the other person working in our backend was the CTO, which worked part-time and had lots of CTO attributions. I remember spending about 20 hours tops in the span of 2 years on that backend. It was THAT good.

[samsquire]

> At my previous job the other person working in our backend was the CTO, which worked part-time and had lots of CTO attributions. I remember spending about 20 hours tops in the span of 2 years on that backend. It was THAT good.

It might be "cargo culting" but I am curious what properties of that good system were true?

[whstl]

It was familiar, because it used a popular framework used the “vanilla” way, the way the author of the framework recommends. So even a junior dev would be able to do stuff in the first day.

There were very few optional third-party libraries or smart-pants patterns. If it wasn’t necessary, it wasn’t imported.

Some database views were used instead of complex ORM queries. Sounds trivial but saves a lot of time debugging.

Control flow was so predictable that I rarely debugged. Honestly for a lot of features I just did TDD without much exploration at all, even on the first uses.

Features were super well isolated and decoupled. If there was some strange, awkward, cross-cutting concern between two distant parts of the domain, it was decoupled using async events rather having domain-model-#1 call domain-model-#2. So any weird interaction between distant parts was well documented in a specific “events” folder.

Dependencies were very up to date and everything was simple so very few issues updating the framework.

Most important: test suite was comprehensive and very fast.

[blowski]

There's a bit of selection bias. Developers are more willing to stay working on good systems for much longer, so there are fewer job openings for other developers to work on them. Hence, most job openings are to work on crappy systems.

[whstl]

You are 100% correct, but my observation was more about how I actually got to work on good projects and enjoyed, but I just don't remember much about them because they barely needed my intervention.

Naturally I'm not counting the stuff I built myself: I definitely worked a lot of time on them and they were a breeze to maintain, but I won't classify them as good bad, since the one thing I'm sure of is that I'm biased about their quality ;)