Average Programmer

Interesting, we haven't touched on this subject yet. One of the obvious tie-ins in my view is that XP and patterns are tools to turn the AverageProgrammer into a PrettyGoodProgrammerWithGreatHabits, given the appropriate study and practice.

Yet another one of EwDijkstra great insights:

[...] Finally the prejudices of management did not allow industrial programming to be viewed as difficult: in the first half of the century, in the first part of the centruy it has become a management goal to organize for the sake of stability of the industrial enterprise in such a fashion that it would be as independent as possible of the competence of individual employees, with the result that in the second half of the century the mere suggestion that individual programming could require brains was blasphemy. For a while, the "deskilling of the programmer" was a hot topic.

The prevailing attitude was reflected in the creation of two literary figures --admitedly of very poor literature, but nevertheless of great paralyzing power--, viz. "the average programmer" and "the casual user". Up to these days, academic research in programming methodology has been supposed to respect the severe intellectual limitations of these fictitious morons: consequently any proposal that required any further education of the programming person was out. [...] // From EWD 1298

The persisting question remains: how do we advance the education of the AverageProgrammer ?

(Feel free to refactor the stuff below to another page, but this appeared to be the most appropriate forum for it)

I suspect that there are two main tools that every programmer has, which determine how good or bad they are at it. These are the ability to create algorithms and code that can solve very hairy problems (I'll call this "wizardry"), and the ability to write code in the simplest way possible (I'll call this "habit"). Methodologies, brace styles, coding and documentation standards are all "habit".

The programmers that I have met (including myself) have more wizardry than habit. Wizardry is what you need for solo efforts, but habit is what you need to work in a team, or even to be able to pass your code off to somebody else.

The shops where I have worked have had a lot of wizardry and precious little habit. The result was unreadable, schizophrenic code. This was mostly but not entirely a deficit in the programmers' training; the problem with habit is that you need to support it at a level above the developers themselves.

How this relates to the above is that XP is habit. They allow teams of average programmers (those with average wizardry) to work together to great effect. This works great in low-wizardry projects (your basic business apps, where the hairiness is mostly self-inflicted rather than part of the problem space). In high-wizardry projects (kernels are the canonical example), XP will still allow appropriately wizardly developers to work well together. However, you can't just staff a wizardly project with "average programmers."

As an average programer, traped in the industrial machine that Dijkstra describes so well, I can only say that this issue brings to mind the best advice ever given to the "average investor" -- don't be average. Some will learn and some will not. In any case it is beyond our power to improve the industrial machine that is the root cause of software rot and, by extention, programmer rot as well.

Thanks for the site. Marc Grundfest

A ProgrammerStereotype