Stop equating bad code with bad developers. Stop equating code criticisms as a knock against you as a person.
To me, what I find jarring is how common bad code is and how incredibly rare well-designed systems and good code are. It seems obvious that the causes of bad code are numerous (only one of which is unskilled developers) and the conditions that allow good software to be created are very rare. You have a lot of "goldie-locks" variables that ruin everything if out of a narrow range. One of these is time pressure. If there are tight, rigid deadlines the code will turn bad, but if there's no sense of time pressure at all the code will usually rot in a different way (becoming increasingly "clever" and impractical after the project is essentially finished but no one wants to admit that).
I've come to the conclusion, over the years, that getting mad at people for "writing bad code" is both useless and wrong, because (1) you really don't know what conditions caused the code to become bad, and (2) it means you make an enemy of the one person who can help you out. I've generally come to view standing code-quality problems (and the lack of budgeted time and resources to fix them) as a managerial fault.
I was considering elaborating on this point in the post, but the post was long enough already. So I decided to keep it out. But I think this is a very important point.
(1) you really don't know what conditions caused the code to become bad
There is totally a spectrum all the way from laziness to understandably tight deadlines to unreasonable deadlines. You totally hit the nail on the head. There is a lot more context surrounding why code is written the way it is than just "This guy/gal is horrible".
(2) it means you make an enemy of the one person who can help you out
There are peers of mine that I look up to, that I consistently am impressed with and they continually push me to be a better developer. The funny (and slightly embarrassing) thing is that for most of them that I met early on I thought were idiots. The favorite phrase "You're doing it wrong!"
I'm lucky that I kept my mouth shut and honestly tried to digest their perspectives/opinions. Now I may still disagree with them, but it's from a place of respect, not out of condescension.
I joke with one of my favorite coders, https://twitter.com/#!/bkeepers , that the first time I met him I thought "This dude is a complete asshole." And I ignored him for months afterwards. That was all from my own insecurity. Brandon is a hella smart and nice guy.
To me, what I find jarring is how common bad code is and how incredibly rare well-designed systems and good code are
I've mentioned before my rule of three. That is, my code will pretty much suck until about the third time that I've solved (or refactored) a problem.
If I ever come across code that I think is particularly nice, it's quite likely that the developer either reworked said code or has solved a very similar problem multiple times. If, on the other hand, I come across bad code, I generally assume the developer was simply pressed for time and created as much value as possible under the constraints.
To me, what I find jarring is how common bad code is and how incredibly rare well-designed systems and good code are. It seems obvious that the causes of bad code are numerous (only one of which is unskilled developers) and the conditions that allow good software to be created are very rare. You have a lot of "goldie-locks" variables that ruin everything if out of a narrow range. One of these is time pressure. If there are tight, rigid deadlines the code will turn bad, but if there's no sense of time pressure at all the code will usually rot in a different way (becoming increasingly "clever" and impractical after the project is essentially finished but no one wants to admit that).
I've come to the conclusion, over the years, that getting mad at people for "writing bad code" is both useless and wrong, because (1) you really don't know what conditions caused the code to become bad, and (2) it means you make an enemy of the one person who can help you out. I've generally come to view standing code-quality problems (and the lack of budgeted time and resources to fix them) as a managerial fault.