Over the last couple of years, I’ve done a lot of pair programming. Pair programming inside my team, at customer sites, in coding dojos and in my open source projects.
Pair programming is really a great and effective experience when performed by an pair of developers knowing how to pair program.
Unfortunately, you cannot just put two developers in front of a single computer and expect them to perform perfectly from the start. Pair programming has to be learned. Both developers need to learn the difference between being the driver (the one holding the keyboard) and the navigator. See here for details.
During my pair programming sessions I encountered some recurrent stereotypes, which I list in this post.
The Dictator is a navigator who tells the driver what he has to type: “And now go to the end of the line and write a closing parenthesis and now…”. Instead of navigating by challenging the current solution and looking where to go next, the dictator gets caught in the programming details.
Actually, the Dictator wishes he had the keyboard. Therefore, when you encounter a dictator simply pass him the keyboard and switch to the navigator role.
The Spell Checker
The Spell Checker sits beside you and reacts to every typo you make by immediately correcting you. Of course, the spell checker has therefore not enough time to really navigate.
Make a deal with the Spell Checker that he gets you a coffee (or anything else you’d like) whenever he corrects you.
The Slasher is a navigator that criticises everything you write. While critique is good, he does it in a way without building upon what you already have built.
Like free jazz musicians build up a tune together by reusing what the other band members have played, good pair programmers use what is already there to go on.
Try switching roles and be a role-model navigator. Maybe the Slasher turns into an Ignorant though (see below).
The Silent is a navigator who says nothing; or almost nothing. He just sits there and looks how you are working.
Challenge the Silent with questions about what he thinks about your solution, or which test to write next.
The Bored tends to distract you from work instead of providing you with information helping you focus on problem solving.
Just send him away, it’s better to code alone than with a Bored.
The Secretive just types some code without telling what he is about to do. The navigator has to figure out what’s going on by himself. There is no discussion between the driver and the navigator about the route to go, which solution to follow or which design to choose.
As a navigator ask the Secretive what his plans are or what is the idea.
The Ignorant simply ignores all advice of the navigator. Mostly because he thinks that his ideas or his programming skills are superior compared to those of the navigator.
When confronted with an Ignorant, simply stop pairing and rise the topic in the next retrospective. Ignorants are normally bad navigators, too. They probably turn into Dictators or Slashers.
The Overwhelmed is simply not used to pair program and therefore very nervous and out of control.
Make sure that you are the best navigator you can be. Be extra cautious with critique and mainly support the Overwhelmed.
Unfortunately, most developers start with this stereotype. Therefore, don’t force pair programming to much on them and either let them be navigators first or only put navigators beside them who have enough social skills to handle the situation.
The Jumper is a driver who likes to make wild jumps in the source code so that it’s impossible for the navigator to follow his steps.
Slow the Jumper down by asking questions about his plans and make sure you know more short-cuts than him.
The Tool-Unfamiliar does not know any shortcuts of the developer environment and is therefore simply a dead slow programmer.
Switch roles and show the Tool-Unfamiliar some of your tricks. Printing a cheat sheet with short-cuts helps a lot, too.
I’m sure there are other stereo-types. Let me know by writing a comment below!
[…] Inhalt / Infos der Präsentation von Urs Enzler […]
[…] planetgeek.ch 编译：伯乐在线 – […]
Don’t forget about “The Mule”. These developers appear near adoption of TDD, and got pulled into the practice, against their will. Mules are stubborn and will not budge if you pull their rope while facing them. Often, gentle guidance from beside them, beginning at their pace forms a good relationship that evolves into TDD, sometimes without the Mule realizing it. This situation requires patience, but pays big by retaining developers already familiar with the company and products.