My take on this is that the developers are costly. A working hour of single developer costs a lot of money. The organization will always try to get the maximum out of that one hour. Spending more money so that the developers are 'better' is not efficient. They just need to be good enough.
That's the magic phrase that really does the heavy lifting here.
Companies and leadership have to define what "good enough" is for them, and in almost every case that comes down to profit and prestige (or power if you take it a step further).
As you said, developers are costly. When a company just wants profit it usually makes sense to hire someone just skilled enough to make the product shippable.
I think this is often the reasoning of management, however, what they don't see is that developer skill often follows a power law and the flow state is a multiplier on top of that. The cost of a midday check-in is not the cost of how much you pay that developer per hour because developers work output per time is nonlinear.
I believe the flow state is why it's so easy to believe the idea of the 10x engineer, we've all experienced the feeling of flying through code without barriers, and we have all felt the below average days where you may be tired and just can't quite load all that complexity into your head to get any real work done. So we believe that there are people out there who are so skilled that they exist in this flow state all the time.
Yes, developers should work on themselves to rely less on a state of flow to be high performers, but even so there will always a benefit to being "in the zone".
You’ve contradicted yourself. Which is it? Will companies try to get the maximum out of each hour of developer time, or do they just need to be good enough?
Perhaps what they meant is that companies will try to get the maximum in terms of development speed, while settling for good enough in terms of quality. And that's why we have so much crap software.
But they so consistently get terrible development speed and crap software. I’ve never been less productive than when I worked in a team that did big-A Agile.
