Programmology
Correlating personality to coding style
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:
Frugality
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
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
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.
Stubborn
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.
- - - - - - - - - - - - - - - - -
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
|