Back in high school, I was interested in pop psychology. I'd read the new issue of "Psychology today" as soon as it came out. One of the things relating to that that caught my interest was graphology. Graphology is the study of handwriting in an effort to gleam something about the author's personality, not by the words that are written, but by the style and shape of the writing on the paper. A fascinating topic, but perhaps a bit abused in that there is a tendency to read more out of the analysis than there is really to it. Still, fascinating. And to this day, I always like to observe the shape of people's writings, and especially their doodles.
Of course, in this day and age, we don't get to observe handwriting much anymore. Maybe a signature on a resume, but even these are submitted electronically, so scratch that.
But a fundamental assumption of graphology is that a person's personality permeates things like handwriting. And if it permeates handwriting, then its logical to theorize that personality would also be reflected in other aspects of behaviour, and especially in creative endeavours.
And this brings me to the topic of this little write-up. The fundamental assumption I'm making is that a person's personality type and programming style are very much linked. And that 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 flies, so it never gets used for its original purpose. And even if it does get used for its original purpose, 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 can run into difficulty in problems that can only be approximated, where the best solution only becomes apparent by writing something and trying it out. Such people are poor at creating a "quick hack" to try out an approach.
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 suboptimal, 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.
- - - - - - - - - - - - - - - - -
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