Well, I don't know that we can separate external forces from why people might dislike bad code... being held to a standard that is unachievable because of someone else's mess and someone else's expectations is all too common in life, and the reality is that your livelihood might depend on meeting those expectations. If you like programming, you might also like maintaining or refactoring code; it goes with the territory, and it can be fun to see how something can be improved or challenge yourself to see how far you can improve it. But it tends to be less enjoyable when your ability to eat and house yourself rides on someone else's bad code.

> If you try to do something right and take pride in your work, your teammates will be resentful that you're not closing your bugs fast enough.

Right, but why would they resent that? Probably because management has expectations on the team, and they are concerned that you're sandbagging the metrics. It ends up being a management or cultural problem regardless.

> Bad code is actually fine. It happens. But I want to know why the code is bad, whether the reasons are defensible or not.

Agreed!

From the perspective of the organization that pays you to do it, it is? At best there may be another mission that it genuinely cares about, usually there’s only a profit motive (which is also fine). If you want to create software as an end in itself or enjoy the craft without compromise, it usually can’t be in the context of a job or a business

Our job is to produce the best possible outcomes given the constraints we’re faced with, and inform leadership so that they’re aware of the tradeoffs when they make their decisions. Sometimes those decisions are going to be bad, and obviously it’s justified to be frustrated then. Other times they are correct, even when it means compromises on the engineering side. That’s when we have to just suck it up (or go elsewhere)

I still think there’s room for enjoying the work of creating software even under imperfect conditions. Striving for perfection is for hobbies, or the very rare circumstance when it’s justified by the goals of the organization

I'm now spending my weekend thinking about a problem where a really urgent feature I wrote doesn't work because the query behind it is too heavy for the database (the query isn't anything special, but it's against a view that clearly isn't properly indexed), and the DB people are complaining I'm overloading the DB. But it's going to be shown to the regulator for some important regulatory rule for which noncompliance is costing us tens of millions per year. Next Tuesday. Which they told me last Tuesday.

How am I supposed to write good code in that kind of environment?