As a 20+ year vet, what worries me is when someone starts talking in terms of good or bad. It's a spectrum, not a binary. There is code that's just egregiousl

As a 20+ year vet, what worries me is when someone starts talking in terms of good or bad. It's a spectrum, not a binary. There is code that's just egregiously bad. There's code that's just egregiously good (and it's not clear which is more expensive to produce and maintain). But the vast majority falls into the grey area in between those extremes. The other poster (koonsolo) has just seen enough different codebases to have come to the conclusion that it's not nearly the most important aspect of a projects success. And I agree with them on that point (wholeheartedly in fact). Developers concentrate on it because it's what they're in all day, the same way that a DBA is going to concentrate on the data model because that's where they're at all day. But in the grand scheme of things, developers way overblow the value of great code. I also have reservations about the claim that most developers even know what great code _LOOKS_ like, I've seen too many terrible codebases that were claimed to be well designed by their creators. My point is that if the code isn't actively causing you problems then leave it be, and stop calling it good or bad. Call it what it is, working code that doesn't need to be bikeshedded over.