> Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we get something out of it.

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