Conceit

A few years ago a software engineer told me that 'It is conceited to presume that you are ever facing a novel problem.' What he meant was that it is impossible to encounter a problem no one has ever seen before.

The job of a software developer is to solve problems. People give developers problems that they themselves don't know the answers to. That is very different from being given a new problem to solve.

For me when I'm presented with a problem at work, my brain plays a few tricks on me. There is a panic response. I am back on the Serengeti, a lion is crouched behind me, and it is time to run.

But then I try to use a problem solving framework. I remind myself that just because I do not know the answer does not mean that the problem is novel.

The easiest way to solve a problem is to look for prior art. Prior art is an example of how the same problem was solved in the past. Prior art takes many forms. It could be actual snippets of code, documentation, or even error messages.

When prior art is hard to find, it is easy to fall back into panic, but the smarter move is to reframe the problem. There are many ways to reframe.

Break the problem into smaller pieces. Take a big hard problem and turn it into a series of small easy problems. Hosting a dinner party is hard, but it is comprised of a series of smaller easier subtasks - decide on a guest list, pick a menu, get groceries, etc.

Restate the problem. In software development there is the widely known rubber duck metaphor, which is the idea that just speaking the problem will lead to new insights. The joke is that the person you speak to might as well be a lifeless rubber duck because it is the action of the speaker that reframes the problem into a more solvable shape. I prefer writing to the more typical shoulder tap scenario. When I write the problem in a way that I can share with a colleague, I almost always become unstuck.

Zoom out. This problem is stupid. You shouldn't even be worried about it. Pick a new problem that if solved would move you closer to the big goal.

With a reframed problem we can again look for precedent. Look at how others who encountered the same problem solved it in the past. Copy their solutions.