Summary
How do differences in temperament affect your team?

I like to think that I'm a just a programmer, but in truth I spent a lot of time teaching people in groups and one on one. The fact that I teach programming means I do a lot of it, both with people and in prep to keep skills sharp, but I do it in an odd way. Most people sit down to solve a specific problem when they program. I start that way, but I actually spend more time working on a different problem: figuring out how to transfer skill and help people get better at programming. It's a weird feeling, because as you do it you know that you're working in a different problem space than the person you are pairing with. You look for alternatives, ways of highlighting a point, and the all the possible take-aways that every move brings. It's fun work, but it's incredibly intense. On an average day, I pair with four or five different people, and, if I'm visiting a new team, I don't have a lot of shared experience with them to fall back upon. We sit together and learn to speak each other's mental language and that can be both rewarding and taxing.

Several years ago, I took a personality test, the Myers-Briggs type indicator test. It's essentially a four axis sorting of your personality based on your responses to a set of questions. You get a rank along each of four scales: Introversion/Extroversion, Sensing/Intuitive, Thinking/Feeling, and Judging/Perceptive. Apparently, this sort of thing can change over your life but when I took it about six years, I ago I was an INTP: Introverted, Intuitive, Thinking Perceptive. At the time, I felt it matched me to a 't'. I tend to be reflective person and the description I read on the test just sort of matched, so I decided to do an internet search and I found a page about INTPs. It turns out that was an INTP convention a while ago, and the web showed picture after picture of people sitting slouched in chairs quietly looking at each other. I nearly fell to the ground laughing at that point, because I imagine that I look like that a lot of the time. In fact, I'm sure of it.

As I read more about the Myers-Briggs, it seemed like it explained more.. something that I've noticed when I interact with other programmers. It should come as no surprise that the personality profile for programmers is not the same as that of the population at large. In fact, I feel that when I arrive in an airport for a software conference, I can usually just "tell" whether another person I see walking by is there for the conference or not. We're a weird bunch. From what I've read, the personality types ISTJ, INTJ, ISTP, and INTP tend to be overrepresented among programmers and that seems to ring true to me, because I think that even before I took the test, I noticed what I now think of as the "P/J divide."

In theory, people who lean toward the P side and people who lean toward the J side see the world in different ways. One website summed up the differences like this. Perceptives "prefer a flexible, spontaneous way of life. They prefer to keep their options open. They seek to understand life rather than control it. Perceptive types are open to new experiences and they are usually very adaptable. They are usually very curious and very tolerant. They tend to postpone decisions." On the other hand, Judging types "prefer a planned, decisive, exacting and orderly way of life. They are able to come to decisions quickly. They prefer closure on events, relationships and ideas. Judging types value punctuality, persistence and completion of tasks. They are good at meeting deadlines. They dislike confusion, inefficiency, and aimlessness."

Although I think this all has to be taken with a grain of salt, I do notice that individual programmers do seem to lean toward P or J. I don't think it is as 'cut and dried' as the theory makes it out to be, but to me there's something to it. The tricky part for me as a person who leans toward the P side is talking without being misunderstood.

Let me give you an example. A very P way of approaching a problem is to start to think about it and bring up anything that could be related. If it's related, it could trigger another thought that could help along the way to solving the problem. A normal J response is to evaluate an idea in the context of what it means to the problem at hand. If an idea just doesn't fit, often someone leaning toward J will dismiss it and look at you like you are goofball for bringing it up. It's something I've worked on over the years, but there is a bit of a tug there. I notice it sometimes when I write. Although I wrote the coldly pragmatic 'Working Effectively with Legacy Code' there are times when I skip writing something because I feel that I would have to underline it and say "I'm writing this because I think it's something we can learn from." I feel like I have to do that because often I notice that people take the presentation of an idea as advocacy. If anything, I think I hold back too many ideas for that reason.

I think that, ideally, teams should have a good mix of P attitudes and J attitudes. Teams with too much P attitude tend to spend a lot of time in meetings that never resolve. Teams that lean toward J tend to bring things to closure too quickly and getting them to move toward agility can be tough because areas without definition are scary to them. Sadly, though, I notice that when there is a good mix, the divide can still be an issue. It seems to take a lot of understanding and patience to bridge the gap.

Talk Back!

Have an opinion? Readers have already posted 20 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Michael Feathers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Michael has been active in the XP community for the past five years, balancing his time between working with, training, and coaching various teams around the world. Prior to joining Object Mentor, Michael designed a proprietary programming language and wrote a compiler for it, he also designed a large multi-platform class library and a framework for instrumentation control. When he isn't engaged with a team, he spends most of this time investigating ways of altering design over time in codebases.