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.
I've also taken (by myself) a couple of MBTI tests and the Keirsey temperament sorter (from the book Please Understand Me II) and I was an INTJ. By now, I understand the test well enough to be able to get any particular type I want. (Psychological tests only work as long as you are not aware of what is being tested and how.) Based on what I have read from various sources and my own experience, I think that the P/J axis isn't the main differentiator between early/late adopters. The NJ people I know are quite open to trying out alternative approaches unless they can see why it wouldn't work. It is the S people who like to stay with the textbook approach (and I don't mean it would always be a bad idea ;). J people want to get things done. It didn't take me many days to convince my colleques to try using pair programming after learning about it. However, I agree that P people (particularly ENTP) are perhaps more willing to try the really wild ideas and are not concerned about wasting time on unproductive experiments.
> Based on what > I have read from various sources and my own experience, I > think that the P/J axis isn't the main differentiator > between early/late adopters. The NJ people I know are > quite open to trying out alternative approaches unless > they can see why it wouldn't work. It is the S people who > like to stay with the textbook approach (and I don't mean > it would always be a bad idea ;). J people want to get > things done. It didn't take me many days to convince my > colleques to try using pair programming after learning > about it. However, I agree that P people (particularly > ENTP) are perhaps more willing to try the really wild > ideas and are not concerned about wasting time on > unproductive experiments.
Yeah, I didn't mean to imply that they are generally late, but often with agile I have all of these conversations with some groups about how the work still gets done even if you don't see don't see the structure, the way that it will get done in advance. Maybe that's J, maybe it's not. I know it's not true of everyone who leans that way.
Well, I like to take things apart. I specifically try to find the weaknesses (rather than the merits) of an idea. Once I'm confident that the weaknesses aren't going to bite me later (contingency planning), and can't see better solutions, I just do it (even if it means drastic changes). I think that this is fairly typical INTJ behavior, but the MBTI doesn't, of course, tell everything.
i started doing this 'stuff' from the econometrics/statistics/OR perspective. this was not before Dr. Codd's paper, but before general availability of RDBMS. the divide that was true back then, that data trumped code and the other way round, is still out there, and getting worse: coders are bound and determined to roll back the clock to the days of COBOL/VSAM, where the system's code is the *only* way to access the system's data. we relational database types (an underrepsented class here at Artima) see this as folly.
now we talk of java and objects. amounts to the same thing. the RDBMS perspective says that the data must control its own destiny; irregardless of who or what accesses it.
this does, it seems to me, correlate with the P/J divide. in the following sense: the P view point is that no matter how much the code screws up the data, it's just bugs that will get fixed, stuff happens; the J view point (mine, generally, though not verified by MB) says that the data is the foundation and had best be solid from the git go or there'll be hell to pay. following that road will lead to less code in the system.
of course, not all software deals with enough data to see the divide. needless to say, such J types likely don't go near it.
I'm an INTP as well and I find that being a P has a number of downsides that have to be compensated for by some J on the team. For instance, I'm very poor at tracking dates, dependencies, and being organized in general. I have to pay very close attention to bug lists b/c I'll forget one and I often want to start the next project before the current one is finished. All of these things have to be compensated for in some way, either by me providing more discipline, or by some other team member keeping tabs on me. However, in return the team gets the benefits you describe: more creative thinking/brainstorming, strong teaching/mentoring skills, and someone who is always on the forefront of technology. To be successful, a team must be as varied as possible, but that is not enough. They must also be aware of their differences and understand how they should work together to compensate for each other's weaknesses.
I'm also curious, I've heard that INTP's do not write books very often (I imagined it was because we like to change projects so frequently). How difficult was it for you to finish the Legacy Code book?
> I'm an INTP as well and I find that being a P has a number > of downsides that have to be compensated for by some J on > the team. For instance, I'm very poor at tracking dates, > dependencies, and being organized in general. I have to > pay very close attention to bug lists b/c I'll forget one > and I often want to start the next project before the > current one is finished. All of these things have to be > compensated for in some way, either by me providing more > discipline, or by some other team member keeping tabs on > me. However, in return the team gets the benefits you > describe: more creative thinking/brainstorming, strong > teaching/mentoring skills, and someone who is always on > the forefront of technology. To be successful, a team > must be as varied as possible, but that is not enough. > They must also be aware of their differences and > d understand how they should work together to compensate > for each other's weaknesses.
> I'm also curious, I've heard that INTP's do not write > books very often (I imagined it was because we like to > change projects so frequently). How difficult was it for > you to finish the Legacy Code book?
It was pretty difficult, and I think that was part of it. The other issue was procrastination, which I think is related too. I usually have a large list of things I want to work on and the newer ones usually look more atractive.
I'm an INFJ. I've been doing XP and TDD for 4 years. I do a lot of mentoring in TDD. I sensed something in Michael's original post that implied that it would be harder to sell XP/TDD to a J than a P. I believe there are things in many of the XP practices that appeal to a J. Here are a few things about XP and Lean Development that I believe will appeal to a strong J personality:
1. The constant feedback of the short TDD cycle (red-green-refactor) appeals to a J because they feel they have "finished" something every 5 minutes. It's wonderful.
2. Short iterations. Same thing. Feedback is good. Accomplishment is good.
3. Refactoring: A J has a strong sense of doing the "right" thing. Experienced programmers figure out design rot pretty quickly and once a J experiences the real benefits of refactoring (increased speed and flexibility), they are hooked.
I could probably list most of the 12 practices and come up with a way that a J would love it. However, I'd like to take a look at a Lean Development principle, the idea of delaying decisions to the "last responsible moment." One might think that this is tailor-made for a P and negative to a J. I believe this changes with experience. Once a J realizes the folly of Big Design Up-Front, they become open to finalizing the design later in the process. In my role as an architect, I very much agree with the ideas from Martin Fowler's "Who Needs an Architect" paper where he describes trying to make "architectural" things (meaning hard to change) not-architectural (easier to change). Not being locked-in provides flexibility, the ability to roll with changes and this is more valuable than agreeing on some design you guessed at up front based on some requirements the poor customer was forced to guess at up front.
XP, Lean Development, and TDD in particular are great for a J. I think that the S/N divide might explain why IT managers (usually S's) have a difficult time with XP. Since software development really doesn't have any scientifically provable way to show productivity improvement (at least nothing agreed on) and the study of development and teams is social science at best, it's too easy for an S to just choose not to believe it.
The Cult of Personality: How Personality Tests Are Leading Us to Miseducate Our Children, Mismanage Our Companies, and Misunderstand Ourselves
From an Amazon review: Paul has thoroughly researched the origins and scientific quality of several tests that are commonly used to make serious decisions about people. As she says, they're used by parole boards, HR departments, counselors and more. You can be denied custody of your children on the basis of a flawed test. In science, flawed doesn't mean "better than nothing." It means "useless."
Her criticism of the MBTI is right on. Psychometric theory incorporates two ways to evaluate tests -- reliability and validity. Reliability means you'll get consistent results each time you take the test. Yet 47% of test-takers change types when they retake the MBTI. Validity means the test measures what it's supposed to measure, yet there are no objective ways to compare the sixteen types.
And while some test-takers and reviewers claim people get great insights from their test results, Paul demolishes this response. Over fifty years ago, a psychologist gave people a test. He then put together a combination of sentences taken from horoscopes and gave each test-taker the same "results." These people rated accuracy of these "results" an average 4.2 where 5 is highest -- and several scored the accuracy as a perfect 5!
Her dissection of other tests is even scarier. Asked to describe an inkblot, a logical response would be, "It's an inkblot." Interpretation of the Rorschach is problematic. The MMPI was never intended for widespread usage and once again, there's more ideology than science.
Paul explains the attraction of tests. We want quick, easy answer. Myers-Briggs is positive -- something for everyone. She urges us to be careful when we're asked to take tests that have consequences for our lives, and I think she's right. There's enormous risk that our test results will be misinterpreted and/or misused. That's her real message.
> "The Cult of Personality: How Personality Tests Are Leading > Us to Miseducate Our Children, Mismanage Our Companies, > and Misunderstand Ourselves"
Thanks for bringing that up. This is critically important as the bureaucratic desire to put people into neat little cubbyholes is both pervasive and insidious and the (detrimental) effects are often not only overlooked but used as arguments for *more* "tests".
Feedback is useful to everybody. Alas, we tend to create various kinds of barriers so that we don't have to perceive, acknowledge, or act on most feedback because that would get in the way of our pet neuroses.
[...] > XP, Lean Development, and TDD in particular are great for > a J. I think that the S/N divide might explain why IT > managers (usually S's) have a difficult time with XP. > Since software development really doesn't have any > y scientifically provable way to show productivity > improvement (at least nothing agreed on) and the study of > development and teams is social science at best, it's too > easy for an S to just choose not to believe it.
I think it's simpler than that. Given the (dis-)incentives, (poor) training, and general lack of excellent exemplars, the overwhelming majority of managers enthusiastically succumb to the Belief of Control. Regardless of what they talk about, their actions put proof to the fact that they believe that they can control things (people, processes, markets, etc.).
Like most beliefs, their Belief of Control is predicated on lots of erroneous (mis-)understanding of how things really work. Alas, there seems to be an roughly inverse relation between how close the belief is to reality and how strongly a person will fight to preserve their belief.
As a Cancerian born in the year of the ox on a Thursday (whose handwriting is nearly illegible and who never dots his 'i's), I naturally agree that these psychological assessments are a load of old er... nonsense ...dressed up in scientific clothing.
> Paul explains the attraction of tests. We want quick, easy > answer. Myers-Briggs is positive -- something for > everyone. > She urges us to be careful when we're asked to take tests > that have consequences for our lives, and I think she's > right. There's enormous risk that our test results will be > misinterpreted and/or misused. That's her real message.
For what it's worth, I agree. There is a danger in taking these things too seriously, especially when in cases where they can impact your life.
Flat View: This topic has 20 replies
on 2 pages