Doers and Thinkers

It is possible to divide groups of people in a great number of ways.  Left-handers and Right-handers, women and men, so forth and so on.  Sometimes two groups are mutually exclusive and adequate to cover all of a population base, sometimes (even in the above categories) they are not.  I am about to discuss two groups of programmers – but I would fully expect that there are programmers out there who don’t fit either category as precisely as I will describe them.

Category 1, which I shall call “the doers”, includes the majority of programmers I have seen and have read about.  Their personal coding style can be bluntly referred to as a “trial-and-error style approach”.  That actually sounds far too much like a harsh criticism.  The majority of these programmers are not clueless monkeys prodding away at a keyboard.  They have a reasonable degree of knowing what to do, but the detail is lacking.  As they code, details come into focus, nuances are dealt with and problems are overcome.  The beauty of this style of coding is that it is easier to deal with when writing.  There is no need for a detailed analysis of all aspects of the code, which in turn makes it easier to concentrate on a specific part of the code.

Category 2 I shall call “the thinkers”.  They represent a much smaller group of programmers.  Their approach is more of intense thought followed by intense typing – with rarely a backspace key pressed.  I would suspect that this group would have a far better ratio of keys-pressed to source-code output.  These are the true geniuses in the field, but based on my experience, they make up no more than one or two percent. 

In reality, even the “doers” utilise and require a high degree of concentration to perform their task.  The biggest difference tends to be that the first version of working code the “thinkers” write will be neat and orderly, whereas some degree of refactoring will be required for the “doers” to turn in work of a similar quality.

As mentioned in my opening paragraph, I do believe that there are times when you will not neatly pigeonhole developers into only one of the two categories.  Depending on the task at hand a thinker may act as a doer or vice-a-versa.

Personally, I place myself in the “doers” group.  I used to feel convinced that the “thinkers” was where I wanted to be as a programmer.  Indeed, I recommend thinking about problems as opposed to blindly trying anything that springs to mind.  These days however, I am more forgiving of my own ability or lack thereof.

The computing industry seems to be coming aware that most programmers are not “thinker” programmers.  Many agile and XP style approaches to programming rely on this.  Concepts such as pair-programming and test-driven-development tend to favour “doers”.  For example, the fact that a “thinker” will visualise the code in their head for a long time prior to writing it down, makes it hard for them to participate in pair-programming environments.

The real danger is that thinkers will not be given a working environment that suits their needs.  One size does not fit all.  As the majority of the industry is made up of “doers”, it is important that methodologies are followed that allows them to produce output that a “thinker” would be proud of.  Essentially, that boils down to allowing time for refactoring.  The code is not done the moment it “works”.  Newer methodologies accept this and build it into the process of writing software.  But that is a story for another time.