Maybe, just maybe, you're mixing cause and effect.
If you treat developers like house painters, they will not give you more. They will build the spec that you give them, and hold their tongues when they know it's a bad user experience.
If you treat developers like co-creators, and hire explicitly, and you put them in the same room with customers, you get a group thinking about how to solve a problem that your users have. They may be able to deliver something quicker, or develop a better customer experience, or question assumptions that lead to a better product.
An empowered engineer will be able to ask, "but what about how this user uses the software? Will this work for them?" And they become great at that by getting experience doing this - it's a skill, not an inborn talent.
Precisely, I've worked at a couple of places where software developers were treated like assembly line workers who convert tickets into code, and on one occasion I was even told that it wasn't my job to ask questions designed to improve my big-picture understanding of the problem, use-cases, etc.
I feel like the "programmers only care about code" trope is perpetuated by people who aren't good at sharing knowledge, or who lack intimate understanding of their customers' needs themselves and have to resort to pointing fingers.
Some programmers are like that, certainly, but if most developers one comes across are like that then one might have to look inwards.
Tangent: There's a Star Trek clip I wish I could find online so I'd have it on-hand to show non-technical people. It's from the 90s, in an episode of Deep Space Nine.
Worf (in Security) is having trouble dealing with Engineering, and O'Brien gives him some advice, something along the lines of "Engineers like to solve problems. Instead of telling them what to do, tell them what you need and let them figure it out.". Then later when he tries it out, they come up with a solution he wouldn't have thought of.
If you treat developers like house painters, they will not give you more. They will build the spec that you give them, and hold their tongues when they know it's a bad user experience.
If you treat developers like co-creators, and hire explicitly, and you put them in the same room with customers, you get a group thinking about how to solve a problem that your users have. They may be able to deliver something quicker, or develop a better customer experience, or question assumptions that lead to a better product.
An empowered engineer will be able to ask, "but what about how this user uses the software? Will this work for them?" And they become great at that by getting experience doing this - it's a skill, not an inborn talent.