How your personality affects the way you code

How do software developers relate to people? We coders are not typically renowned for our ability to empathize or understand regular humans. Sometimes it seems like we might be on a different wavelength to everyone else.

So, are coders are a fairly distinctive group, psychologically? Are they as different as the stereotype implies? There isn’t as much data on this as there could be. While there have been plenty of studies, they have mostly used MBTI (the Myers-Briggs Type Indicator), which is bit dated and questionable. Even so, if we set aside the lack of newer and more valid psychometrics, there are some strikingly consistent patterns.

Let’s take a short trip through the personality styles of programmers and coders, and see how that might impact both their team dynamics and their job of coding.

A short overview of MBTI

Since most of the data I’ll be looking at today uses MBTI, let’s do a quick recap. MBTI (the Myers-Briggs Type Inventory) was based on Jung’s ideas, with some tweaks, and uses four basic distinctions:

• Extraversion (E) versus introversion (I)

• Sensing (S) versus intuition (N)

• Thinking (T) versus feeling (F)

• Judging (J) versus perceiving (P)

With a fairly brief psychometric, people can get a score on each, and usually get a type combining the letters, e.g., ESTJ. As these are scores, some people are on boundaries, others may be firmly one side or the other.

It is worth remembering, with MBTI, this all dates back to 1940s, where it was originally intended to help women find an appropriate role during wartime, when the men were all off fighting Nazis. It’s not exactly modern, and things have come a long way since in psychometrics, but it’s been around and in use a long time, so there is a large amount of data to work with.

A second point is: MBTI, like most psychometrics, measures a preference rather than an ability. Just because someone prefers sensing over intuition doesn’t mean they aren’t highly competent at intuitive perception, just that it isn’t their first natural instinct. People can, and do, learn strategies to adapt to different circumstances.

Coders are different to the general population

There are a fair number of studies using MBTI to map out employee preferences in the software industry, but one of the more complete studies, by Capretz, shows a few types are substantially more common among developers compared to the general population:

• ISTJ : 24% of coders, 12% of the general population, e.g.: Sean Connery

• ESTJ : 15% of coders, 9% of the general population, e.g.: Michelle Obama

• ESTP : 8% of coders, 4% of the general population, e.g.: Donald Trump

• ISTP : 8% of coders, 5% of the general population, e.g.: Vladimir Putin

• INTP : 8% of coders, 3% of the general population, e.g.: Tina Fey

• ENTP : 7% of coders, 3% of the general population, e.g.: Tom Hanks

• INTJ : 7% of coders, 2% of the general population, e.g.: Arnold Schwarzenegger

This isn’t the only study, although most of the others used way too small a sample size to be useful, or were using biased samples. The patterns were similar, but I’m not going to use them as a source of evidence.

I’ve missed out the types which are much rarer in developers than everyone else, but they’re also telling. I’d recommend that you go and read the original article for more on the data.

Looking at these, there is a common theme. In all cases, the ‘T’ factor (a preference for thinking over feeling) does predominate in software developers. There are other differences too, but let’s go through the issues one at a time.

1. As a group, software developers are no more introverted than anyone else

There is still the myth over introversion. It’s everywhere in the literature. For example.

“As a matter of fact the software field is dominated by introverts, who typically have difficulty in communicating with the user.” (Capretz, 2003).

I have no idea why Capretz makes this comment, since he reports some very nice data which confirms that introversion is only about 10% more common among developers. This is a tiny effect. Thinking is 100% more common, and intuition about 25% more common. By any stretch, the effect of introversion is very marginal by comparison.

Secondly, and crucially, extraversion and introversion in the MBTI are not the same as the everyday usage, but have a specific meaning dating back to Carl Jung. (I’m using the spelling “extraversion” to emphasize the difference from everyday social “extroversion”.) It’s much more, what motivates you most? The world of action, people, and things? (that’s extraversion), or the world of ideas and reflection (that’s introversion). MBTI introverts prefer fewer, deeper, and more involved interactions with people, where extraverts prefer shorter and more frequent interaction. For getting to know users quickly, extraversion can be an advantage, but introverts are perfectly good at deep social interaction.

So please, let’s get away from this abject nonsense that coders are stereotypically anti-social introverts, for two reasons. First, it’s not true, and second, introversion does not mean what you might think it does.

2. There are big differences in decision making strategies

Developers are about twice as likely to be a -T- (thinking, rather than feeling), compared to everyone else. This means that software developers tend to be more logical, and less affected by the ‘feels’ of a situation, when they come to make a decision. And this is by far the most pronounced difference between developers and the general population.

A typical software developer likes there to be a logical consistency behind a decision. It might not matter much what that consistency is, so long as it’s there. By contrast, other people prefer the ‘feel’ of the situation, using empathy and imagining what it is like more from other people’s point of view. In other words, there is a difference between coders and others, in how they tend to justify a decision.

Here’s a nice new example. Docker just announced a change in its release version numbers, to be: “YY.MM”, for the year and month. So, the March 2017 version is “17.03”. This is a radical change from the normal convention, which is like: “1.8.0”, and where “2.0.0” is a big change, “1.9.0” is a modest change, and “1.8.1” is too small a change to worry about.

The year/month versioning is logical. It has clear and simple rules. The rules about whether a new version should be “1.9.0” or “2.0.0” are a matter of judgement, and it’s pretty clear the Docker community hadn’t got its collective head around that yet. So a need for clear and simple rules creates a pressure for “YY.MM”. Everyone outside that community will suffer, because the difference between “17.05” and “17.06” could be trivial or it could be huge, but that’s not really their problem.

So on the whole, a developer is more biased to making decisions that fit with their world-view, compared to identifying with the situation at hand. So yes, developers are (based on the MBTI, which is flawed, remember) less likely to use other people’s feelings as part of their decision-making process.

3. Coders prefer intuition

The second difference is that, on the whole, some coders tend to be a little more influenced by intuition than the rest of the population. The difference is only about 25% more, measured by MBTI. However, intuitives are a small group within the general population, so even though there’s more of them in software development, even there, intuitives are still a minority.

Again, ‘intuition’ here is a technical term, about how you make sense of new information. Sensors are the CSIs, the detectives  —  they like to work from evidence and facts, things they can experience directly. Intuitives uses hunches, always looking for an underlying pattern. These two ways of gather information make a huge difference in debugging, for example. Sensors will prefer logging and collecting evidence. Intuitives will jump through hypotheses, using what they see as a tool to choose between them.

When coders thinking styles go wrong: convention over configuration

These two preferences — for intuitive patterns behind evidence, and for logic and rules in decision-making — tend to shape the way software developers approach their projects and their collaborations.

Let’s look at “convention over configuration” as an example. This is an approach used by some software frameworks (Ruby on Rails is probably the best-known example) where it attempts to ‘do the sensible thing’, so that a developer can focus on the bits that depart from that convention.

The good part of convention over configuration is that emphasizes people are part of the system. There is a culture, and it matters.

The bad part is that, until you understand the culture, it’s something of a mystery. Because there’s nothing visible representing the culture, learning the culture is hard.

Imagine that you are a developer confronted with an entirely new framework that you need to use. Fundamentally, people learn a new system by making predictions about how something will work, and then getting it wrong. These expectation failures are central to learning. When things “just work” we don’t actually learn anything.

Instead, developers will try to use hypotheses (the preference for intuition) and want to base decisions on rules (the preference for thinking) to learn the framework. But if you design a system with convention over configuration, you’re creating a system that — for a developer — is going to behave in ways that sometimes work, sometimes not, maybe in ways that are surprising, unpredictable, and implicit. This makes it hard for a new developer to see the patterns.

Developers are not users. On the whole, you want to minimize the need for a user to learn a system, where you want to make it as easy as possible for a developer to learn one. These two demands: minimizing learning versus easing learning, lead to very different design decisions.

The pain comes when an intuitive sets out building a convention over configuration framework.

After all, they will understand it just fine. But when they expect someone else — someone who doesn’t yet know the hidden rules  —  there will be tears before bedtime.

Reflections: thinking-styles and coders

I’m not going to suggest that all coders go out and do an MBTI. It’s not actually very good. In fact, I’d not recommend using MBTI for anything these days. Instead, go out, get a decent psychometric (IPIP NEO is a good free one) and think about how you differ from everyone else. Your talents are yours, not other people’s, so don’t assume others find the same things easy that you do.

If someone wants to work with us doing a more modern psychometric and analysis of the impact of coders’ distinctive cognitive styles  —  especially if they have funding  —  we’d love to talk more.

But even with all these caveats, the MBTI results are fairly clear and consistent that there are thinking-style differences between us developers and normal people, and these thinking-style differences have a significant impact on our code. Code isn’t just written for machines, it is the product of a culture and a community. Therefore, the way we think: whether we prefer rules over data when it comes to decision-making, or whether we prefer intuition over evidence, this matters.

What doesn’t matter, of course, is whether we’re an introvert or not. Please can we just put that particular part of the tereotype away and forget about it?

---