[danwee]

> I would rather not maintain a system that was built on quicksand, where dependencies cannot be upgraded without breaking anything.

To each their own. I prefer to maintain a bad system because:

- I can make it better

- If something doesn't work as expected it's because of the current state of the system, not because of my lack of ability

On the other hand, I don't really like to maintain very good systems (crafted by very intelligent people) because:

- There's little I can do to make them better (I'm a regular Joe)

- If something breaks it's because of my ability as a programmer (all the shame on me)

So, it's like playing in two different leagues (but the paycheck is rather more or less the same, so that's nice).

[jon-wood]

This is an interesting perspective which I'm inclined to disagree with. There's little pleasure to be found in having to deal with a system that broke because it was badly designed or implemented, although I guess it means you've got a reasonably secure job for the time being. Being able to gradually refactor it can be fun sometimes I guess, but I'd still rather not have to.

Your second category is more interesting to me - you're interpreting a system is hard to understand and work on as being made by super intelligent people. I would interpret that as a system that was badly designed, unless you're doing some new and revolutionary thing (you're probably not). A system that has been designed in such a way that only someone with deep knowledge of the thought process can work on it has been designed badly. I know this because I have in the past designed many such systems. Coming back to them a few years later even I hated myself for it, so I'm deeply sympathetic to the people who had to work on them who weren't me. Thankfully in most cases I got to task a few people with ripping out the system and replacing it with something better.

[whstl]

"you're interpreting a system is hard to understand and work on as being made by super intelligent people"

I read it as the opposite. GP says that if a system is good, it needs no improvement, so there's no fun in refactoring and redesign.

And those good systems are easy to understand and work no, so when something breaks you can't blame it on the design. You can only blame yourself.

[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?

[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.