Bugfixes as Therapy

June 18, 2013 holman

We have an obsession with shipping.

This obsession typically centers around new. What new feature did you build this week? What new approach can our customers take? What’s the new thing we should be excited about?

I love this. It’s addictive. Shipping begets shipping. It’s all about what you’re going to ship next.

Until you’re just not in the mood.

Spinning your wheels

It usually starts slowly. Frustration from blowing a day on an approach that ultimately won’t work. The desire to build a new feature but realizing you have to overhaul an underlying system first. Or sometimes you just go through a funk.

It’s not quite professional burnout, but a feeling of frustration surrounding what to do next. Sometimes — even in problem spaces that are fun and exciting — you find yourself spinning your wheels, ultimately going nowhere.

I hit this recently after finishing up a few projects. I spent a good week or so stressing out over what to ship next that I hit this weird paralysis where I found myself spinning my wheels.


I needed some kind of foothold, and my repository’s issues were that foothold. I decided to focus and spend a few weeks exclusively on fixing bugs.

Bugs are a great break from product work. You don’t have to be as creative: here’s the bug, and you’ll know when your job is done when you can’t reproduce the bug anymore. Hell, you can even write the failing test first.

It’s also very concrete improvement. When you’re spinning your wheels, you’re by definition not going anywhere. But if you’ve closed a few bugs, you can very clearly see improvement: I’ve fixed bugs! Something that was broken is now fixed and in production! The users are happier! It drives motivation.

Maybe I’m just weird, but I find fixing bugs to be therapeutic.

Issues as project management

Ironically enough, I was focusing on bugs because I didn’t have enough focus for a specific project, but I found that changed quickly. After a week or so of fixing bugs and sifting through piles of issues, I started seeing trends. It became clear which aspects of the codebase were neglected, which aspects were bug-prone, and which just needed an overhaul. I ended up taking on a couple new projects for the next few months, and it entirely changed my perspective on what I can do to contribute.

Most people know what needs to be done. Good product design comes from within… Ford’s faster horse and all that. But sometimes it’s helpful to take time out and dive into problems in order to find solutions.