In practice, I've seen lots of situations where, for want of time and designers, engineers received vague instructions and were mostly left to their own devices.
Engineers were making significant contributions to the design process without noticing; and many of them were, as you might expect, not thoughtful. After all, the coder was being paid to code, right? Not their job.
You might argue that we could fix this by hiring more designers (you should anyway, but not for this reason). But without engineer understanding, you may wind up with a design team micro-managing a team of engineers.
To me, this appears to be a recapitulation of the 'architect-vs-tradesman' dichotomy seen in the building construction industry, with UX experts playing architect, and the engineers playing extremely-well-paid plumber.
Under these circumstances, no engineer wants to build anything unless it's been signed off in quadruplicate, complies with all extant regulations and guidelines, and is exactly like the last 10,000 ones like that we did. At this point, more or less, engineers and designers begin to resent one another.
It's a full-on zugzwang: The engineers begin to think of the designers as dictatorial and unrealistic dreamers who don't know enough about code, and the designers begin to think the engineers are callous boors who, yes, are hostile (or at least indifferent) to the expectable experience of the user. Which is what I take the OP was pointing to.
While other industries may be able to tolerate this kind of vibe, none of the habits of mind and culture that I just described are conducive to anything like a good UX outcome in software development.
Far better is to have engineers who are trained to make good empathic common-sense decisions. This is important for three reasons: First, it frees up design and PM cycles; second, it generates a culture where the engineer is respected as a conceptual contributor to the user's experience, and, thirdly -- and most importantly -- it creates a person who has both design and technical expertise, and can adjudicate tradeoffs between these two things without calling a meeting.
And this third point is important for some relatively deep socioeconomic reasons -- I disagree with Hayek about a lot of things, but he was right about the value of local knowledge. (https://en.wikipedia.org/wiki/Local_knowledge_problem)
An engineer who is in the code every day may well have a better sense of what is possible (and what the tradeoffs may be) than a designer who is not on the front line. That honey-mustard combination is lost entirely on teams where engineers are not also a little bit designers, and designers are not also a little bit engineers. Think of this strategem as a 'local knowledge reuptake inhibitor'.
Thus, the aim of my programme is to create a corps of engineers who, when they see something, say something. But in order to see like a designer, you need imaginative empathy. The heart is the eye.
