How to know if you’re a coding optimist or pessimist

Posted by Jeremy Miller on March 16, 2010

Let’s say you’re a developer — and you probably are if you’re reading this.  How do you know if you have a generally sunny, optimistic set of mind or a gloomy, pessimistic attitude?  It’s very simple.  You know how you constantly look at 6 month old code and see a better way to rewrite the code?  An optimist rewrites that code and says “damn, the new code is so much cleaner!”  The pessimist rewrites the old code and says “damn, that old code sure was a mess.”

And if you never find any thing wrong with your 6 month old code?  You sir are either severely lacking in retrospection and/or you might very well be unconsciously incompetent.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.awgtek.com awgie

    People are still writing code?

  • Ryan

    You have TIME to look at 6 month old code???

  • JL

    Even if you you re-write it and admire the elegance of the new code, when you see it again in 6 months it will have aged and be ugly yet again. Vicious little cycle.

  • DC

    If you don’t look at old code and think of how much better you could have written it then I say you have learnt nothing in the months since you wrote that code.

  • Pablo

    Rewriting code for the only intention of “better look” introduces the factor of buggy code, i mean, you have to re test it and probably re fix it. If you need to add more functionality you must put in the balance two things quality vs stability. Refactoring the whole code affects the first one in a good way and the second one in the bad way in most cases.

  • Darren Kopp

    my code is not my child. f*** all the code i have written.

  • Sedalb

    Re: Filip Hammerstad. Easy answer to your question:
    LAZY, and the reason why software is so buggy. You break refactoring into two catagories. In my opinion the two come hand in hand. Instead of constantly putting a scrap of cardboard over the broken windows take the time to fix it. Not only will it keep warmer it keeps everybody else from breaking more windows.

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller

    @jens,

    It amused me to write this, and you sir, need to learn the law of two feet.

  • Dan Martin

    Haha I’m with Matt on this one.

  • http://www.mattblodgett.com/ Matt Blodgett

    I look at my old code and think, “This code sucks,” and I rewrite it. When I’m done with the rewrite, I look at the code and think, “This code is better, but it still sucks.”

  • jens

    This is so 2010-look-at-my-random-crappy-blog
    A worthless post in which some random jokel shouts out his amazing revolutionary new fantastic and oh-so clever idea.
    And the new revolutionary new fantastic clever idea is the boyscout rule of leaving the campground prettier than when you found it…

    STFU

  • Thomas Eyde

    When I see something wrong in my 6 months old code, I think this is probably not the last time I wander around here and think “WTF”? And since I have already been interrupted and lost some time thinking about it, the best thing would be to invest a few minutes to make things clearer.

    Who knows, maybe I learn something too, so after the next 6 months, my code will look better?

  • Filip Hammerstad

    What are you if you look at 6 month old code and decide it’s not perfect but its working as intended, then move on to write some code with new functionality?

    Whats the priority of refactoring existing functionality vs adding new functionality?

    I’m not trying to be sarcastic, I just want to know other people’s opinion on business value vs “the perfect code”.

    Further I feel it necessary to split refactoring for “perfect code” into two different cases:

    1. Refactoring for user/external stability.
    2. Refactoring for neater code or using a new (more appriopriate/popular) pattern/technology.

    In my opinion case 1 is much more important than 2 for business value, while 2 is often something developers focus on. I’m not saying case 2 does not have some business value as well though. Just not as much as 1 in most cases.

  • http://schotime.net Adam

    Amen Josh

  • http://joshsmithonwpf.wordpress.com Josh Smith

    When a realist finishes refactoring that 6 month old code, he drinks some beer.

    Josh