When so-called engineers stop spending half the development schedule choosing a framework and the other half trying to make their dev setup work on everyone’s personalized laptop they will have some credibility complaining about “arbitrary” business goals and requirements.
From experience, in their career, engineers not only need to excel technically, but are also forced to pick up everything from UX, methodological BS (from Scrum to Itil) to domain specific know-how in multiple fields or areas. Since many managers do not know what they're doing, senior engineers often times end up being de facto management consultants as well. If you are working in a business environment (as opposed to writing low-level drivers or whatever) it's almost impossible to not pick up on what's going on around you.
How many banking managers know how to code? How many engineers working in banking know at least something about the processes, compliance issues, how the org is structured, what the competitors are?
The stereotype of the autistic programmer who is only interested in shiny gadgets and tech needs to die.
As a freelancer I have to get to know the business my customers are in, I can’t just focus on purely technical things most of the time. Many times I have described my work to other programmers and heard how they want to be left alone to code. I take over legacy software and failed projects for a living. The two main reasons in my experience for software dev project failure are (a) developers did not bother to gather and understand requirements but rushed to start coding, and (b) poor communication with the customer and stakeholders. Those faults may come from arrogance or inexperience, or both.
Only an incredibly tiny slice of professional engineers are on HN, even smaller slice of that actually post anything. HN is not representative of anything.
You can find the attitude I described all over the place, not just HN.
When I get involved in a failed or failing project the developers almost always blame management, schedules, budgets, marketing priorities. They almost never reflect on the time they’ve wasted or how they don’t really understand the goals or users for the software they are responsible for.
I think the quoted statement tends to be a systematic issue on struggling projects that describes the decision makers, regardless of role.
I'm not sure how anybody can expect other outcomes than a few lucky successes and a lot of failures when understanding why you are building something seems to be undervalued by management, technical or other.