Programming personas

THERE is no other task quite like computer programming

THERE is no other task quite like computer programming. Programmers always work in isolation on their own particular task, even while part of a team. There is no part of programming that cannot be undertaken by one person alone, given sufficient time.

Furthermore, there is no part of programming that is improved by putting more people on the task - one programmer working alone will always work more efficiently and almost certainly produce a better result. It is time constraints and the sheer size of modern software projects that necessitate teams of programmers.

Individual isolation is necessary because of the levels of concentration involved, and this leads to the popular image of the programmer as a pale, uncommunicative shadow of a character who only emerges at night for essential sustenance.

Some programmers may fit this image, but this doesn't mean that such traits are essential. So what type of personality does make a good programmer?

READ MORE

Among the truly remarkable trends which have emerged from research into programming and programmers over the years is the enormous gulf between the small number of exceptional programmers and the rest. The productivity of top programmers is between five and 10 times higher than the average.

The research also shows that these programmers are continually reading and learning about programming and new developments. They do not wait to be taught how to do something but" will find out for themselves - and, in many cases, may be largely self taught. This desire for more knowledge appears to be a deciding factor.

THE task of programming is very diverse. The degree of complexity of even moderate sized projects can be enormous, yet the programmer must simultaneously work with minute details.

The task of visualising even a small sized program is beyond any mind, so programmers resort to dividing up the task into manageable chunks, or "modules". It is then possible to see the whole project as a collection of modules, and each module as a collection of more detailed units. In a large project there may be several layers of complexity.

This ability to break up a project into conceptual modules is one of the most important skills for a computer programmer. It has nothing to do with programming as such, yet without this ability the programmer will be unable to undertake anything other than trivial tasks.

Once again, studies have shown that this ability is one the divides the best programmers from the rest. Programmers who can handle complexity by dividing up the task into manageable modules are among the most productive.

TALK of software quality may appear to be an oxymoron - modern programs are notorious for their number of bugs. A recent survey slated the most popular programs in common use as being unacceptably unreliable, and drew comparisons with the reliability of cars.

This is a little unfair - even a relatively simple computer program is vastly more complex than a car - but the fact remains that the software industry has a reputation for poor quality.

There are two major issues in measuring software quality: how good the program is (its features and ease of use) and how well it works (in terms of speed and freedom from bugs). For the developer, dealing with bugs where much is expended to achieve quality.

One of the most obvious trends in surveys of software and associated bugs is that programs which have been broken down into small, modular components are much more reliable and bug free. The most productive programmers also produce software that is much more reliable and bug free than the average, further enhancing their productivity. In addition, good programmers will establish the cause of bugs much more quickly than their colleagues and will effect a cure - not just a "patch" or quick fix.

So what makes an ideal programmer? By far the most important trait is a demanding curiosity that drives the individual to continually learn more about what they are doing and to research new and improved programming techniques.

Sometimes this is defined as a sort of laziness, a laziness that constantly drives the programmer to seek out the most efficient way to do a particular task, to do it once and do it right.

Another essential - but often assumed - skill is the ability to visualise a project by breaking it down into modules. Drawing out a project on paper is one thing, understanding it and all the implications is another.

The least important trait is the one that many companies put the most store by experience. A poor programmer will always be a poor programmer, and one year's experience repeated five times is no good at all.