Procrastinating perfectionism

Originally posted to Shawn Hargreaves Blog on MSDN, Wednesday, November 10, 2010

I find it fascinating to watch how different programmers tackle problems in different ways. Some like to think things through until they fully understand the optimal solution, then code it up in one quick burst. Others prefer to get something up and running as fast as possible, then iterate to gradually improve their algorithms and implementation.

Both styles work, and both can reach the same end result in the same amount of time, but it can be tough to work with other people if you do not appreciate how their style is different to your own. Planners tend to worry that the iterators are rushing ahead too fast and churning out poor quality code, while iterators worry that the planners are just sitting there doing nothing at all!

Me, I'm an algorithm planner but an implementation iterator. I have a hard time writing code before I have grokked the problem and worked out a broad outline of how to solve it, so I often need several days pure thinking time when I start on a hard new problem area. But once I have the algorithm clear in my head, I like to quickly write code without worrying about sensible naming, class and method factoring, commenting, etc. I get it working and tested, then do a second pass to clean things up and make it readable and maintainable.

I have a bad habit of getting stuck in my code cleanup phase. Some amount of cleanup is obviously important, but I catch myself agonizing over the right name for an internal helper method, or going back and forth and back and forth again over insignificant formatting choices like whether a conditional should be on one line or split over two. The code already works fine, and these details do not significantly affect readability, so I'm just wasting time worrying about them.

Unfortunately, recognizing when I'm wasting time doesn't always help me to avoid doing so  :-)

Blog index   -   Back to my homepage