> Understanding how software creates value and what kind of software at any moment is valuable; and which parts of your job is tied to that process makes this much clearer.

This is a good point and something that is indeed requires a lot of care and thought and experience to tackle properly, but I think it strongly hinges on the assumption that software just does a thing, so to speak. Whereas I personally view software as something that does a thing but at the same time as something that is also a communication system and encoding of domain knowledge. So if the communication and encoding parts of the software are missing, and all you've got is it doing something, then in my view, the software is leaving value on the table over the long term. Poorly tested, understood, documented, and specified software will have waste products over time, siphoning value away. But it does so much more quietly, but in no less magnitude, than when software is not doing what it is supposed to be doing.

You are correct, but current geopolitical conditions and economic policy have created financial situations that basically enforce short sightedness on the side of corporations. If your employer is publicly traded or has institutional investors; they need to report quarterly earnings. Investors won't care about code health or the longevity of a product, they only care about sales/revenue.

It's a fundamental systemic issue that's why we see so many tech companies produce terrible products. But we (the programmers) have no ability to fix the shortsightedness of the American financial system.

Do you have any examples from your experience about making that distinction? Sometimes I struggle with the boundary between good maintainable code and meeting deadlines.

Writing bad quality software is often even more expensive.