We programmers often prefer to work in problems that we already know how to solve, and tend to avoid hard ones that don't have a straightforward solution. Sure we like to think that we love a challenge, but given the choice of something easy to solve and another that requires thinking more deeply, one will choose to work in the easy one -- regardless of which one is more important. We're biased to tools and techniques that we already know and are comfortable with, we favor solutions we don’t need to think much.

By hard problem, I don't mean just something you have never done before but you're reasonably confident that you can learn how to do it -- you know, solving a known problem in a different language/technology, these kinds of things that we like to do sometimes to avoid boredom. I'm talking about problems that you have no clue how to solve (or even if it’s solvable) and no idea if you can learn how to solve it. Problems you're afraid of even trying to tackle.

To be fair, this is just human nature, it's not a limitation of programmers only: most people in similar circumstances will act the same way. And many times this is okay, it's often not a big deal to do the thing requiring less energy, we even design products around this behavior of choosing the easy. It's only human that we will tend to do the easy instead of the hard, and many times it’s even the wisest thing to do.

Now, what if these hard problems are really the important ones? How do we decide if they’re really important? What can we do about this natural tendency of avoiding them? What can you do to make yourself more willing to at least attempt to solve them? I’ve been thinking about this lately, and I don’t really have a straight answer.

I suppose it has a bit to do with attitude, a feeling that it will be worth to give it a try even if you don’t succeed. I suspect the fear of failure is big for many programmers. Our own expectations for a possible solution are increasing by the minute, however our ability to learn doesn’t scale at the same proportion. So we conclude we’re not up to the challenge and give up without really trying, thus not building resilience while learning from failures, which would be precisely what would help when tackling a tough problem.

We’re eager to believe in the myth of the genius programmer, which helps to increase our insecurity. Most programmers have some personal heroes, and that’s not a bad thing, but it’s good to remind ourselves these heroes are just people, not that different from you and me. I bet they see themselves as just people working in hard problems. In some cases they might’ve been privileged with early access to technology or guidance from knowledgeable people, but I have the feeling that our heroes are mostly just people who are willing to give it a try and keep at it.

It’s nice to pay attention on what may be causing us to avoid difficult problems, and seek to understand which are the sources of anxiety, what are the risks and fears involved. Hopefully this will help us to see more clearly and make better decisions about what we should be working on. Because it’s easy to avoid important work if you’re rushing to do everything fast, fearing to fail or disappoint someone or just being too busy to spend time thinking.

Sure there will be times when we’ll be too underprepared for a problem. But maybe we should try it either way, perhaps in a safe environment. At the very minimum we’d learn a bit more about the problem and maybe grow a better understanding of what to learn before trying again. Who knows, this might end up being a good heuristic for increasing happiness.