Correlating personality to coding style

Back in high school, I was interested in pop psychology and read every issue of "Psychology today". Relating to that, I developed an interest in graphology. Graphology is studying people's handwriting to gauge their personality. Not studying what is written, but how the letters are formed. A fascinating topic, but there is a tendency to read more out of the analysis than there is really to it. To this day, I always like to observe the shape of people's writings, and especially their doodles.

We don't get to observe handwriting much anymore. Maybe a signature here and there.

A fundamental assumption of graphology is that a person's personality permeates things like handwriting. And if it permeates handwriting, then it's not unreasonable to assume that it affects other aspects of behaviour, especially in creative endeavours.

And this brings me to the topic of this little write-up about personality types and programming styles. It should be possible to tell something about a person's coding style based on their personality and vice versa.

Unlike graphology, I'm more interested in predicting how somebody will code based on knowing the person, rather than vice versa. Getting a sense of somebody's personality is much easier than analyzing their code. And when you recruit and manage software developers, being able to predict how they will code is really useful.

To this effect, I have some rules of thumb that I go by:

People who are frugal like to conserve resources - in real life, a resource they tend to conserve is money and goods. As a software developer, they try to conserve computing resource - code space, memory space, and cycles. So if you want somebody to program on small embedded systems, or code that runs fast, it helps to find somebody who is cheap.

Ambition can be a dangerous and counterproductive aspect of a software developer. Ambitious people have grand intentions. When they decide to take up a craft in real life, they will buy all the tools they might need, even before its clear that they will actually use all of these tools. On the computer, these people like to establish "expandable" "generic" and "reusable" frameworks for solving future problems. This might be all fine and good if you are at the start of a huge project. But often, just one problem needs to be solved, and the grandiose framework for solving everything is overkill. They justify the extra complexity saying their code is more "reusable" for the future. But quite often, it's so complicated it never gets used for its original purpose. And even if it does get used, the excessive complexity discourages reuse by anyone else.

Meticulous people take a long time to do things exactly and precisely. They do this for code as well. They will typically spend a larger fraction of time in the early design and coding stages than most people. But these people tend to write fewer bugs, so in terms of finished and debugged code, people like that are often more productive. However, people like this have a hard time with problems that can only be approximated, or where the best solution only becomes apparent by writing something and trying it out. They aren't good at creating a "quick hack" to try something out.

Strong willed, stubborn people are good early in a project where the architecture has not yet been set in stone. People like that are very anal about having some sort of coherent plan - typically their plan. Being perfectionists and type A personality is really helpful in getting a good architecture set down. However, such people are of course difficult to work with. Such people are also weak late in a project, especially when there is an architecture that is acknowledged to be sub optimal, but one is resigned to the fact that a redesign would perturb the system too much. In that phase of a project, stubborn people are hard to engage. They spend too much of their time getting annoyed at why the system has not been done the way it "should have been", and never quite become comfortable making incremental patches to legacy systems.

Conversely, people who are very flexible can be a liability early in a project. Such people will tolerate inelegance even early in a system. They will program around problems that are fixable rather than suggesting the system be changed. But they come into their own late in the project.

Short attention span
This is the type of person who is very enthusiastic about trying new things and exploring new approaches. They are fun to have around, and will take an interest in anything. These people will readily dive into a new project. But before it's done, they'll dive into the next thing. The downside is that such people aren't good at doing the long slog that it often takes to finish a substantial project. A disproportionate number of projects is started by people who don't finish what they started. Because people who finish projects take much longer before they are ready to start a new one.
- - - - - - - - - - - - - - - - -

An aside
I was going to call this essay "codeology", but a google search showed that that term was already taken, and well defined. It has nothing to do with writing code. However, the term "programmology" still seemed malleable to being defined by me. Hence the choice of title.

To my rants page

My technical hacks