I don't even have to know what your job is, and I can still say that with a pretty high level of confidence. Are you an engineer building bridges? You're solving a problem for people who need to get across that divide. Are you a cashier at the grocery store? You're solving a problem for people who need to pay for their groceries (and for people who need to take money from people for groceries, double whammy). And of course, are you a computer programmer? You're solving SOME, maybe not very well specified, problem for your users.
It really doesn't matter how far removed from people you are, you're still solving problems for people. You could be completely devoted to the inner most workings of the Windows kernel. You're actually worse off! You're solving problems for users who want to check their email, and programmers who want to write MS Word, and designers who want to make Windows look pretty, and marketers who want to sell Windows as the most stable ever, and finance people who want to show market growth, and the list just goes on and on and on...
Sometimes you are aware that you are solving problems for people, but maybe you don't really know what problem you're solving. Like the grocery store clerk who is really nice and friendly and makes all the customers happy going through the line. Maybe they think their job is to make you happy, but it's not. The problem you want them to solve is to figure out how much money you owe, and take it from you. And you want them to do it quickly. If they can do that AND make you happy, then they are a very good grocery clerk. If they only make you happy, then they just aren't very good.
A similar thing happens with programmers. I frequently get confused and think that my job is to make high quality software and write high quality code and do good high quality design work. But its not. My job is to solve some problem my client has. As long as I fix their problem, I've done my job. Maybe I could have fixed their problem better with beautiful code I'd be proud to hang on my wall at home. That would be a bonus. But all I'm supposed to do is solve their problem.
That is, unless I'm actually supposed to be developing a long life product, which will require all kinds of future enhancement and maintenance and re-configuring. In that case my job is to both solve the client's problem AND develop a strong software product. These are two competing goals.
And that's the thing about People Problems:
- They are never clear cut
- They tend to overlap
- They always involve trade-offs
The "real world" is all about People Problems. And People Problems inevitably lead to trade offs. And trade offs inevitably lead to disappointment. For example, if you choose to make the code super high quality, you wont be disappointed, but your boss will be because of how much it cost.
The trick is to understand that above all you are solving people's problems. Then understand that necessarily involves trade offs. Then try to take a big picture view when deciding on how to make those trade offs. Hopefully that will at least help you deal with the inevitable disappointment. At least you'll know you made the best decision you could for the specific People Problem you were faced with.
Of course, you'll probably be disappointed when you find out later that you didn't have all the facts straight and your decision was based on faulty information or just information that has since changed. But that's a whole different dimension of dealing with People Problems.