Procrastinating Paradigms

Programming is sometimes a mind boggling and perplexing thing.  If you know what you want to do, and how to do it, then it is a breeze and you can whip out a thousand lines a day, write an entire app over the weekend.  If you don’t know what you want to do or how to exactly do it then it can drag on for weeks and months.  I’m like this a lot.  Sometimes it just seems like I’m a whirlwind, my fingers flying off the keyboard in hypersonic rhythm. Other times, I just stare at the blank page, uncertain what to write. 

Usually, I’m sort of a cowboy when it comes to writing code.  I’ll jump right in without all the facts and just start punching away.  Some people would think this imprudent, being the types to agonize over every detail before committing anything to disk.   I don’t care so much.  I’ll even write down garbage lines that I know are invalid.  I’ll solve something temporarily in a way I’d consider a hack, knowing that I’ll be back to fix it later.  I am thinking about the problem, working toward the best solution, its just that I think by writing code.  I need to see bits and pieces of the idea take shape in front of me.  Only then do I gain perspective.  I’m generally comfortable working this way, because I’m also comfortable in throwing it all away and starting over.  This is not a very common trait for programmers.  It’s more like building sand castles than building bridges.

Yet, sometimes the problem in front of me is so different, so complicated I don’t even know where to start.  I hesitate at even starting to write code, even though I know this usually helps me think through the problem.  Usually after a few false starts something will click and I’ll see an adequate solution and then I’m off to the races.  But then, I usually had some glimmer of understanding to begin with.  When I don’t even have that, then I don’t even bother.  I actually don’t even try to think about it.  My best plan of attack is to put it completely out of my mind.

You might think that’s a really bizarre approach, not to even think of it at all.  You might think I was procrastinating, goofing off.  Heck, when I find myself in this predicament I might switch to working on something else, though usually this isn’t the right thing either.  The best thing is to change my environment completely.  Do something else.  Shut down the computer and walk away.

You see, the way I figure it, my background processors are still busy think through the problem.  At least the portion of my brain that does all the pattern matching and what not, that puts odd things together and interjects with aha moments from time to time.   Eventually, that part of my brain will filter out the nonsense and give way to making some sense out of the madness.  It’s not that the solution will suddenly become clear, but some part of it will, enough to send me back to the keyboard. 


Comments (7)

  1. Scott D. says:

    I work the same way. I am glad to hear I’m not the only one!

  2. Rob Chartier says:

    Same here. I have had many nights where I’ve tried to sleep only to discover the solution and get up for a few more hours to throw it (or some core pieces) together.

    I’ve even gotten up a second and a third time to implement a few more features, or to completely rewrite a section of code.

    The motivation is there and sometimes overwealming, just the ideas take thier time to present themselves.

  3. It’s amazing how much more productive you can be one day than another. I worked a whole weekend recently and go more done than a normal month.

  4. I completely agree with you. When I do the first set of screens for a user I never, ever try to get things perfect the first time. 80% is good enough. If something just doesn’t feel right I work on something else until tomorrow.

  5. Tony, yes, and then you can take it to 100% in little tweaks after you know you’re on the right track.

  6. Tim Scarfe says:

    Thanks for the words Matt.

    I am exactly the same in many ways, here are a few conjectures:

    1) I like to meticulously figure something out in principle before I write any code

    2) I realise that as soon as I start to write code I will see things I couldn’t possibly have seen coming.

    3) Being a bit of an architect type, I need to start writing the implementation as soon as I figure out the principle solution because I need anything to limit myself from over architecting

    4) If I don’t understand the principle solution to every facet of a solution, productivity takes a massive hit.

    I think programmers have two states that can’t inter-exist; percolation (analysis/design) and coding (development). Whether or not we are actually productive in development mode, we will always think we are because lines of code are being written. Percolation mode scares me because it’s a fucking black hole man on a big project I always wonder if I will really figure it out this time (as you have said in a later post).

    Keep up the great posts Matt, a loyal reader here.

  7. Tim Scarfe says:

    "I like to meticulously figure something out in principle before I write any code[…]"

    Something I meant to get across in relation to my first point was that I think the real challenge is figuring out enough principle strategies for you to start the implementation without any major re-architecting in that development phase.

    Don’t know about you but I hate re-writing or to a far lesser extent; re-architecting code. I feel like I am going backwards and I always kick myself if I realise that my role as a business analyst has failed me in extracting the correct business requirements in the first place. i.e. damage limitation; chain reaction effect because of failure in the analysis and/or design stages, hacks inevitable.