Any of these people can solve problems in programming, and they often all do. It's naive to assume your entire team is motivated by the same thing as you. Furthermore, if you're building a team, you want diversity of motivation because it leads to diversity of viewpoints. Programmers who are motivated by people drive us to make usable software and not just to "solve the problem." Programmers who are motivated by quality challenge us to improve test coverage and keep our documentation clean.
If you look at the composition of a diverse engineering team, you might notice that many of them are motivated to solve problems for different reasons.
Programming isn't done in a vacuum, and our job isn't just to crap out solutions to hard problems. We don't work in a vacuum. Our solutions have to be robust, and they have to actually help people. Having a diversity of viewpoints on your team can help you ensure those boxes are checked.
I've often seen situations where developers are told, "solve this problem" without being told the context or even success criteria. They then spend inordinate amounts of time iterating without clearly knowing when it's "good enough" to stop and release.
It's why people complain about the issues that technical debt brings about.
Depends on the problem being solved. Debugging platform or OS problems are a minefield of frustration.
Some problems presented to developers are also very far afield from their strengths and interests, like UI and UX, and so also might be of little real interest despite being important problems.
For example, finding a corner case bug in a library you rely on is generally unpleasant. Sure, part of problem solving may involve either fixing it, working around it, or choosing another library. Before choosing an option, it makes sense to weigh the costs and benefits.
To make a long story short, if enough things pile up at the same time, it can feels unsatisfying because less new user-facing benefit is being created.
One solution, if it works for you, is to take a balanced view of productivity means; namely, a blend of short- and long-term value.
I think you need to be able to enjoy problem solving though even if sometimes mid-process you feel awful.
I agree, but it's because the reward is so great. I would imagine it's a different feeling if I was fixing someone else's (say offshore team) bugs all day.