> 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
> From the perspective of the organization that pays you to do it, it is?
I agree. I'm just saying that if you limit yourself to explanations from that perspective, you will miss some of the explanations and be unable to describe real-world phenomena.
> 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
Sure, but that's an extreme position. Maximizing the "ship features that make money" end of the balance doesn't end well in the long term. Maximimizing "all code must be perfect" also doesn't end well. There is very much a place for an appropriate amount of craftsmanship, and businesses do better and even make more money in the long run if that isn't choked out. ("Appropriate" varies widely by situation.)
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