it's like blaming the assembly line worker for a badly designed car.
Software engineers don't solve problems, they implement solutions someone else thinks will solve a problem.
Software engineers don't solve problems, they implement solutions someone else thinks will solve a problem.
Really though, caring about what the problem is and trying to solve it means: 1) you work slower, 2) you ask a lot of questions, 3) you push back on things. Basically you're spending more mental effort trying to encapsulate what the problem is than the stakeholder.
Those things will often make people either hate you or think you're bad at your job.
Imagine studying about web design, accessibility and usability for many years. You feel that you have something to contribute to the design of any app.
Then the higher ups just hands you a spec and assigns you to a task to fix this bug/implement this feature without your input.
That's pretty damn demoralizing. It will just push you towards caring more about streamlining your own workflow to rather than care about the actual usability of the app.
Maybe that's the reason why there is so much interest in the in what workflow to use, what IDE/text editor to use, which languages to program in, etc.
(I'm aware that there's been some effort to extend the legal significance of the word "engineer" to the software industry, but I'm curious if that difference is actually in practice anywhere today)
Engineer invokes a sense of design, but so does programmer. When I started, there was no job where you just coded straight pseudocode specs. Business described the problem the way business does, and you had to convert that into a computer solution. Within that solution, different developers would own various parts of it.
I would say the entire process of having coders who design systems and coders that just write code is inherently broken. Businesses want to think of development as prod-ops, but it's more like book publishing. I'm of the mind that if a coder who designs a system in enough detail to write pseudocode, he should just write the application.
The better approach is have an architect/lead model subsystems and a general skeleton of the application, then have different teams implement the subsystems. Clearly defined interfaces on all inter-subsystem communications.