working on the wrong problem

Working with code is an extraordinarily satisfying experience. Not in the minute-to-minute. At that scale, it can be infuriating. The code won’t compile. It trips on an unexpected bug. So on and so forth. However, when things do work, I’m rewarded with a flood of endorphins. This is a big factor in why I love what I do. It’s like I get to sit at a slot machine all day and get constant hits of endorphins without gambling or risking my financial future.

The endorphins are a response to solving problems and solving problems feels good. Solving problems is not, however, always the best outcome. Not because it’s better to have unsolved problems, but because sometimes the problem is the wrong problem to be working on. In those cases, I’ll still get the reward, but I didn’t accomplish anything — or at least I didn’t get closer to the ultimate goal of software that delivers value.

In the course of a long day, it’s likely that the wrong problems will rear their heads, call out and demand to be solved. Whether working on a personal project, and certainly in a professional setting, it’s important to resist their call, to ignore them as much as possible, and when that fails, to have a practice in place to step back and evaluate the approach with some regularity.

These strategies can be a simple as writing down a plan in advance and referring back to it, using a Pomodoro timer to limit the amount of time you’ll allow yourself to burn on a problem, and, my favorite, talking to friends and colleagues about the approach.

Solving problems feels good. Solving the right problems feels great.