I recently read a great article about procrastination. While the common viewpoint is that procrastination is a waste of time, it can also be a source of creativity. It reminds me of the classic advice when banging your head against a problem: take a break. Step away. Breathe.

A year ago I started taking this advice a little further. If I am stuck with a problem, I put it off for at least a day. I started trying this because of an experience I had almost a decade ago. I had spent a few days on this one feature that wasn’t really that complex. Most of the time was spent banging my head on a couple of bugs I had introduced. Instead of putting in long hours like I was used to, I went home instead. The next day I had an epiphany, put all the code I had written aside, and rewrote everything in a couple of hours.

Putting off work doesn’t only help when I’m stuck on a problem. It often also helps when I have a solution to a problem, but I hate it. An example was when I was working on file versions for Maleega. I wanted to group versions of the same attachment together in an email thread:

When I first started, I went down the programming rabbit hole of building out a tree structure. How do I store a version of a version of a version? How would I display such a thing? What edge cases do I need to prepare for and what tests would have to be built? None of these things are impossible, they’re just a bit of effort.

Stopped work. Played with my dogs. Read a book. Went to sleep.

Next day I realized that all my struggles were for building an inferior product. If I only do one level of grouping, it is both an easier model for users to understand AND significantly easier to write the code for. There’s absolutely no good reason for a multiple levels of versions to exist. Procrastinating gave me the time to come up with a better solution rather than spend significantly more time working on a terrible one.

There was also the time I was refactoring the user system for Maleega to clean up some technical debt from my original prototype. I was significantly changing what a user actually was in my system and that required a bunch of new database tables. A migration started to look like this:

The problem is that user ids are referenced in dozens of other tables that would need to be updated. An improper migration, while unlikely, had the risk of displaying one person’s data for another person. That’s completely unacceptable in an email product. So this would have resulted in a huge amount of time spent building automated tests and running manual tests.

I put off working on this for a couple of days. Eventually I came up with a stupidly simple solution. Why not just preserve the original user ids?

This requires overcoming some programmer OCD about the data being “messy”, but it significantly cut down on development time and product risk. No other tables needed to be updated because all the user ids were the same. Procrastinating 2 days saved me weeks of work and it was a safer solution.

Procrastinating doesn’t work all the time. Sometimes I don’t get better ideas and I’m stuck implementing the unpleasant solution I was trying to avoid. In these cases, there is the risk of letting procrastination become destructive. Putting things off until a better idea comes along doesn’t work if the better idea never comes. I’ve also fallen into this trap a number of times.

The most effective way for me to ensure procrastination is constructive is to always come back to the problem on a daily basis. This does not mean procrastinating a day, looking at a problem for 5 minutes the next day, and then procrastinating another day right away. It means putting a reasonable effort into actually trying to come up with a better solution. Running through why the initial solution works and why I hate it. Brainstorming some other ideas, even if they get ruled out right away. Serious thought needs to be put in before continuing to procrastinate can be justified.

Of course procrastination is hard to justify at any time. What are you going to do the rest of the day after all?

Well just because you’re procrastinating on one thing doesn’t mean there aren’t other things you could be doing. There are always bugs to fix, tests to write, technical debt to clean up, or other lower priority features. The important thing is to make sure those other things are more straightforward than the problem you are procrastinating on. Splitting focus like this is only doable if only one thing actually requires heavy thinking.

This probably gets in the way of most development processes. Sprint planning doesn’t really take into account procrastination. But there are ways to fit it in. Maybe a story isn’t pointed or put into a sprint until the plan for a solution is actually ready. Or maybe you plan for 2-3 days of procrastination in until you bite the bullet. There are always other stories to work on. Or maybe you put breaks in between sprints to actually have a decent amount of time to plan the next one.

What’s important to realize is that there’s a certain amount of creativity needed to create better technical solutions. Creativity can’t be forced. I’ve rarely had a great idea by forcing myself to sit down for an extended period of time. They often just come on their own. Procrastination provides that needed time.