Paul Graham's recent article Hackers and Painters, along with a thread (read mini-flame war) over on ll1 discussing static versus dynamic typing and XP, got me to thinking about the different views of programming and the different styles of programming. This is closely related to the Code Commando article, but with a few twists and maybe more sympathies for those who are not the ``Commandos''.

Paul Graham compared creating art with creating programs and closely correlated the creation of something beautiful with the art of programming. While i believe that he's onto something, it strikes me that he may be missing half of the picture. To see why lets jump to the domain of the metaphor: drawers.

Almost everybody in our society is well aware of sketchers, whose are works are prominently displayed in offices, homes, restaurants--we even collect this work and dedicated buildings to the viewing of it. This is not the only type of drawings that are created though. In fact, a second type of drawer exists, but rarely gains any public attention, although on average their salary is much higher and consistent then that of sketchers. These often forgotten souls are that of drafters. And while they are much less often thought about, they are no less important to our society. Seeing that there are two types of drawers, to me, enlightens the various debates on language designs, programming styles, etc. Suddenly it can be seen that there really are multiple correct thought bodies; the problem is that they are looking at different situations. In the same way that sketchers and drafters have need of different approaches and tools, the different types of hackers need their different approaches and tools.

The following is a table showing some of the key differences between sketchers and drafters as i see it:

Having looked at these differences between sketchers and drafters, lets return to hackers. As far as i know there are no clear terms used to distinguish between types of programmers, since most people don't distinguish between them (which is why i'm writing this). To be arbitrary i'm going to call the groups the artistic programmers and the clerical programmers.

Artistic programmers program not because of a salary, although it certainly doesn't hurt, but because there is a certain beauty in programming, in indulging in the art of creation. The more interesting and unusual the creation, the more desire to step up to the challenge of not only revolutionizing, but doing so with their expressive personal touches to give rise to a masterpiece. A tedious job will frustrate an artistic programmer, and he will expend more energy finding ways around finishing correctly then he would have plugging through the tediousness. At times he may subconsciously block out the tediousness and cut corners to get around it.

Artistic programmers have no more use for static typing and other arbitrary restrictions then a sketcher has use for a compass, a protractor, or a stencil; imposing such on him will make him feel confined, almost to the point of being claustrophobic. In creating a masterpiece, he longs to allow it to be admired and appreciated for what it is. The artistic programmer is less interested in the specifics of what he is programming, in the specifics of telling the computer what to do in a step by step list, he is more interested in expressing the solution to the problem he is solving, he will there for be more inclined to use a much higher level language such as a functional language.

Artistic programmers often prefer to work alone. Programming in a team can frustrate them greatly as often they know exactly how a problem should be solved, but can not easily express this with other programmers. An artistic programmer feels strong ownership to his code, and has the inner personal needs for attribution. He will not take kindly to others mucking around in his masterpiece, even if he hasn't polished off all the rough edges.

Clerical programmers are often much less apt at solving tricky problems, and will not know what to do with the freedom given by things such as dynamic typing. If given too much freedom they will likely end up using it inappropriately and be found having created a mess and coded a project into a corner. On the other hand, they can take a tedious but well structured task and happily plug away at it. They often have no need to have their code admired, in fact they may prefer it remain unseen.

Clerical programmers should work closely with other clerical programmers. In fact, they will often enjoy the company and dynamics of team programming.

In short clerical programmers are great for large tedious and exacting projects, projects that are not inventing new types of wheels. They are well suited for the database logic somewhere deep within the back recesses of a company, or creating an endless number of simple and routine web systems--taking large but programmatically simple requirements and working tirelessly at implementing them.

These two types of programmers is exactly why we see such division among languages and styles. An artistic programmer has no need for the philosophy set out for them by XP, while they may not personally disagree with all or even most of XP's tenants, it is foreign to their more abstract dynamic way of creation. Lisp may be a powerful weapon in the hands of an artistic programmer, but it may give too much freedom in the hands of a clerical programmer, that is if they ever figure out how to begin using it. The manager for a team of clerical programmers may prefer to use a languages like Java where it can be certain that the parts that the individual programmers are creating fit together exactly, and that no programmer is ``abusing'' his knowledge of the code-base.

Overall we need to learn more about these two types of programmers work and work best. By correctly utilizing them we will have all the more efficient society, and all the more happy of workers. Conscious effort should go into decisions being made about which code to allow artistic freedom on, and which code is tedious enough to keep away from the artistic type programmers.

And, as nice as the DeCSS code was, we need more public exhibitions and admiration for good beautiful code.

Thanks to Nic Ivy and schvin for feedback and suggestions on this article