How do programmers differ, and why should you care? Steven Clarke from Microsoft’s usability labs has identified and demonstrated at least three different programmer styles, which has been reported in quite a few places, hence programmers do indeed differ. The types Clarke found are:

THE SYSTEMATIC DEVELOPER: Writes code defensively. Does everything he or she can to protect code from unstable and untrustworthy processes running in parallel with their code. Develops a deep understanding of a technology before using it. Prides himself or herself on building elegant solutions.
THE PRAGMATIC DEVELOPER: Writes code methodically. Develops sufficient understanding of a technology to enable competent use of it. Prides himself or herself on building robust applications.
THE OPPORTUNISTIC DEVELOPER: Writes code in an exploratory fashion. Develops a sufficient understanding of a technology to understand how it can solve a business problem. Prides himself/herself on solving business problems.

Now why should you care?

Almost every mention I’ve seen of this online – or of any other personality type categorization system – is usually followed by a “which type are you?”. This misses the point utterly and completely. Psychological research like this first becomes really valueable when you stop thinking about yourself and start asking how this can help you understand other people. If you design API’s and base your design on what makes most sense to your own coding style, you will create something that two thirds of your audience will find difficult to use. Even if you don’t like or agree with their style.

Granted, that makes the assumption that programmers are always equally distributed among styles, which is a pretty wild assumption. The point is that other people are more likely to think differently than similarly to you.

That is also a good thing to keep in mind when formatting code for readability: if your coding style differs from standard Perl Tidy or your company’s coding standard, keep in mind that you are not formatting for yourself, but a colleague, maintainer or anonymous CPAN downloader. They are more likely to understand a common standard than your standard.  It sounds obvious, don’t it? I don’t think many (any) programmers think like this even so.

Now, Clarke, in an article to Dr. Dobbs Journal, has an example of a cognitive mapping of programmer types and API traits which is quite illustrative.  In Figure 1, thick blue lines shows the expectations of a particular programmer type, while the dark lines shows the score of a particular API. As you can see in this case, the match is bad. Now the good thing is that Clarke’s research gives you a framework to discuss how and why.

That’s important because programming style isn’t related to experience level or educational background. An programmer with an opportunistic style will not necessarily grow into a systematic programmer with more experience, neither will a systematic programmer become more pragmatic with age. Or perhaps they will – but you can’t assume that.

Finally, the dimensions which Clarke suggests APIs can be understood on at a cognitive level:

• Abstraction level. The minimum and maximum levels of abstraction exposed by the API, and the minimum and maximum levels usable by a targeted developer.

• Learning style. The learning requirements posed by the API, and the learning styles available to a targeted developer.

• Working framework. The size of the conceptual chunk (developer working set) needed to work effectively.

• Work-step unit. How much of a programming task must/can be completed in a single step.

• Progressive evaluation. To what extent partially completed code can be executed to obtain feedback on code behavior.

• Premature commitment. The amount of decisions that developers have to make when writing code for a given scenario and the consequences of those decisions.

• Penetrability. How the API facilitates exploration, analysis, and understanding of its components, and how targeted de- velopers go about retrieving what is needed.

• API elaboration. The extent to which the API must be adapted to meet the needs of targeted developers.

• API viscosity. The barriers to change inherent in the API, and how much effort a targeted developer needs to expend to make a change.

• Consistency. How much of the rest of an API can be inferred once part of it is learned.

• Role expressiveness. How apparent the relationship is between each component exposed by an API and the program as a whole.

• Domain correspondence. How clearly the API components map to the domain and any special tricks that the developer needs to be aware of to accomplish some functionality.

Steven Clarke seems to have discontinued his blog, but his scientific work is chronicled at Scentific Commons.

(Found, among other places, assertTrue() ).