Procrastinating perfectionism

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  🙂

Comments (10)

  1. Robin Debreuil says:

    I think you need to consider how much worse your code would be if you weren't the type that really cared/agonized about the little details : ).

  2. Vicente cartas says:

    Just let StyleCop decide those things for you! 😀

  3. Ryan says:

    There are those of us in between as well. I think through most of the major points of something knowing that I will have to rewrite or rework once "something we didn't think about" pops up. So I will spend a litte bit of time thinking to get the right direction and then iterate as needed to flesh out the fine details.

  4. Oren Kurtz says:

    At least you eventually complete what you're working on, I have a nasty habit of iterating indefinitely. 🙂

  5. Philippe Da Silva says:

    I'm a design and OOP addict: can't figure out why but when I see a class that is more than 1000 lines, it disturbs me and I have to go back to design.

    And god knows how game programming and OOP do not tend to like each other :p

    But I'm following a cure and I hope to get my never finished game released soon… Unless… :p

  6. Jeff says:

    I've always felt clean code is correct code… sure it may work when it is sloppy, but if you ever have to go back and fix it, or read it (like 6 months later) the cleaner it is, the more you will thank yourself later.

  7. Muttley says:

    Oh dear, that sounds all too familiar…  🙂

  8. Rim says:

    Real programmers don't document. If it was hard to write, it should be hard to understand.

    (Yes that's offtopic sarcasm, I just love that quote 🙂

  9. zavolokas says:

    I'm happy to read that 🙂 I'm not the only one who thinks a lot about class names.

  10. Starnick says:

    Boy that describes me. As for agonizing over class names sometimes I agonize too much and get bogged down (often going back and forth). Usually I find it's better just to move on and forget about it for a little bit because always the next day I wonder why I spent all that time standing still when I could've been running with some other code longer. I'm pretty sure it has to do with being too attached, especially after you invest all that time in perfecting it.

Skip to main content