4 ms·

Number 2 through 10 I agree with you. Number 1's presence on the list strikes me as evidence that there exist legions of people in this line of work who simply

Number 2 through 10 I agree with you. Number 1's presence on the list strikes me as evidence that there exist legions of people in this line of work who simply do not belong here. "Being stuck in problem solving" IMHO is a veritable source of professional happiness, not a detraction from it, among the best developers I know.

meheleventyone 9y ago
I don't think being stuck is a source of professional happiness but getting through it and out the other side. It's great to look back in hindsight at how much a situation sucked and how you pulled through. This applies to all sorts of things. I think you need to be able to enjoy problem solving though even if sometimes mid-process you feel awful.
jschwartzi 9y ago
Look, people are motivated by different things. Some people are motivated by unanswered questions. Some people are motivated by doing a good job. Some people are motivated by the impact they have on others' lives. 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.
Clubber 9y ago
>"Being stuck in problem solving" IMHO is a veritable source of professional happiness 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.
arjie 9y ago
I suspect they mean interrupt bug fixing. If you spend all your time on interrupt tasks it's possible you'll eventually get bored. It's why people complain about the issues that technical debt brings about.
QuantumGravy 9y ago
The paper clarifies that this means being unable to reach a solution, as in, you can't figure it out. You've hit a brick wall. Perhaps your intellect is insufficient or maybe there is no solution, but you're definitely not smart enough to know the difference. That's what's instilling unhappiness.
naasking 9y ago
> "Being stuck in problem solving" IMHO is a veritable source of professional happiness, not a detraction from it, among the best developers I know. 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.
- dj-wonk 9y ago
  My read on the quote is the problem comes from the "being stuck" part, not the "problem solving" part. 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.
afpx 9y ago
I see #1 more about people developing against ill-defined visions, problem statements, or requirements. 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.
SketchySeaBeast 9y ago
I love #1, I just find that it never comes without #2. Problem solving is great, problem solving on deadline is much less relaxing.
s73ver 9y ago
I think it depends on what we define as "problem solving". If we're talking about the problems that come with actually doing what you mean to do, sure. If we're talking about working around the problems with your software stack that don't actually relate to the end goal, then I'd have to say no.
ryandrake 9y ago
That struck me as odd, too. A software developer complaining about being "stuck in problem solving" is like a taxi driver complaining about being stuck driving a car.
daxfohl 9y ago
Depends. If you're stuck figuring out why your from-scratch Haskell app is returning incorrect results, sure. If you're stuck figuring out why the 50K line globals-everywhere VB6-SharePoint connector DLL you inherited is randomly disconnecting, when it's only a tiny but necessary thing holding you up from the meat of your project, and you need to jump through weeks of political/bureaucratic hoops to access the code, that's something else.

meheleventyone 9y ago

I don't think being stuck is a source of professional happiness but getting through it and out the other side. It's great to look back in hindsight at how much a situation sucked and how you pulled through. This applies to all sorts of things. I think you need to be able to enjoy problem solving though even if sometimes mid-process you feel awful.

jschwartzi 9y ago

Look, people are motivated by different things. Some people are motivated by unanswered questions. Some people are motivated by doing a good job. Some people are motivated by the impact they have on others' lives. 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.

Clubber 9y ago

>"Being stuck in problem solving" IMHO is a veritable source of professional happiness 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.

arjie 9y ago

I suspect they mean interrupt bug fixing. If you spend all your time on interrupt tasks it's possible you'll eventually get bored. It's why people complain about the issues that technical debt brings about.

QuantumGravy 9y ago

The paper clarifies that this means being unable to reach a solution, as in, you can't figure it out. You've hit a brick wall. Perhaps your intellect is insufficient or maybe there is no solution, but you're definitely not smart enough to know the difference. That's what's instilling unhappiness.

naasking 9y ago

> "Being stuck in problem solving" IMHO is a veritable source of professional happiness, not a detraction from it, among the best developers I know. 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.

dj-wonk 9y ago
My read on the quote is the problem comes from the "being stuck" part, not the "problem solving" part. 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.

afpx 9y ago

I see #1 more about people developing against ill-defined visions, problem statements, or requirements. 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.

SketchySeaBeast 9y ago

I love #1, I just find that it never comes without #2. Problem solving is great, problem solving on deadline is much less relaxing.

s73ver 9y ago

I think it depends on what we define as "problem solving". If we're talking about the problems that come with actually doing what you mean to do, sure. If we're talking about working around the problems with your software stack that don't actually relate to the end goal, then I'd have to say no.

ryandrake 9y ago

That struck me as odd, too. A software developer complaining about being "stuck in problem solving" is like a taxi driver complaining about being stuck driving a car.

daxfohl 9y ago

Depends. If you're stuck figuring out why your from-scratch Haskell app is returning incorrect results, sure. If you're stuck figuring out why the 50K line globals-everywhere VB6-SharePoint connector DLL you inherited is randomly disconnecting, when it's only a tiny but necessary thing holding you up from the meat of your project, and you need to jump through weeks of political/bureaucratic hoops to access the code, that's something else.