Each programmer has their own way of thinking. Some of us churn out countless lines of code per day by concentrating on what they are trying to achieve rather than how exactly they are doing it. Others, often regarded as slower thinkers, tend to ponder over details of implementation and produce fewer lines of code resulting in apparently lower performance than that of their hasty colleagues. Obviously a programmer's efficiency is adequately measured by the amount of code they produce in a given unit of time. Or is it?

Sometimes I find myself feeling guilty for staring at the IDE and thinking, apparently wasting precious work time that I'm being paid for. None of my superiors have ever scolded me for that, but a subconscious guilt is always there, prompting me to write that code as it comes to mind and never think twice or look back. Having seen lots of open-source code I can safely assume most GPL developers tend to do just that. Hardly structured, vastly copied-and-pasted code lacking any sensible architecture at all - that's what you're likely to get on SourceForge or wherever you prefer going for open-source inspiration. Now before you get all excited and start telling me about a gift horse's mouth, allow me to remind you that this was just an example to illustrate a common truth: poorly thought out code sucks. To name a few reasons why:

  • Low reusability. Code monolith is what you're likely to get unless you deliberately think what goes where in the code and how it's going to be (re)used later. Unless you make a habit of deliberately thinking about reusing code it will seldom be fit for any purpose outside its immediate intended environment.

  • Excessive complexity. Unstructured code tends to get complex. It is not unknown for such code to overwhelm its own authors let alone any support programmers unfortunate enough to be assigned to fix/update that code! Excessive code complexity creates new bugs and prevents the old ones from being fixed or even identified.

  • Bad example. Thinking less often means coding more (and I do mean literally coding rather than programming). This sets a very wrong example for teammates if a manager were to praise such a coder for superior productivity.

  • Domino effect. When assigned to support junk code, even careful and thoughtful programmers often subconsciously seek overly simplistic (i.e. wrong) ways to fix/update the code in order to get rid of it ASAP. The "this code is so screwed up, why bother thinking, let's just patch it up a bit" attitude creates a chain reaction whereby code evolves from bad to worse.

Writing the initial code is just 20% of the job, and I'm being optimistic here. The other 80% is supporting and reusing that code hopefully for years to come. By speeding up the initial 20% coders often neglect the other 80% and make someone's (or their own) job much harder at later stages of the code's life cycle. Which brings me to a conclusion: writing hasty code is utterly counterproductive. As a matter of fact, thinking about the grand scheme of things is one of the most productive things a programmer can do. Maybe that'll make me feel less guilty next time I stare at the screen, doing "nothing".