Pair Programming Questions Coaches Get

How do we to deal with personalities?  With empathy, and possibly repetition, to build familiarity and trust. 

How do we deal with widely varied skill levels? Use a pairing ladder to ensure varied pairing and to promote cross-training/skill-distribution. The link details when Pivotal Labs tried it out and does a good job of ...

• Spelling out how a pairing ladder works.
• Identifying conditions under which it does not work well .
• What their team’s benefits and struggles were.

The pairing ladder is helpful to get a team used to pairing and to ensure lots of diverse pairing. At some point it will become unnecessary as the team establishes recurring norms. At that point, you might use the pairing ladder only to introduce a new team member (i.e. facilitating them pairing with everyone).

How do we avoid a strong personality from taking over the pair? With Strong style pairing, created by Llewellyn Falco. This style of pairing is a direct counter-measure for a disfunction experienced at some point by many when they were a novice, and is used with Mob Programming.

Scenario: Novice and expert are pairing. Expert becomes impatient saying something like “Here, let me show you.”, bangs away rapid-fire at the keyboard for 5 minutes without saying a word, then says “Like that!”. The novice learned absolutely nothing, except maybe they don’t want to pair with that person anymore.

What do we do when a pair has an equally valid but completely different design idea?   Timebox trying out both and make a decision from a much more informed position. If you’re doing TDD, your safety net is built-in. This is a common solution when doing mob programming and is sometimes referred to as “debate in code”.  

When should we not be pairing?  Here are a few cases:

• Common cases like correcting typos, or more generally, when the extra brain power or second set of eyes is just not adding value. 
• When the code you’re writing is something you plan to throw away, i.e. a spike (your objective is to learn something, not to deliver something).

Caution: Resist being pressured into “ship-it”. The you that learned something new from the spike will write better code than the you that went in search of an answer.

How to deal with an absentee pair (either working remotely, away in meeting, or simply not paying attention) You and your team may benefit from using Mob Programming instead of pair programming if this becomes a recurring pattern. That is because in mob programming the concentration required to work well as a mob is more distributed, is less stressful as a result, than when working directly with one other person as in pair programming (at least for most people).

How are we supposed to do pairing?  The best answer is “It depends” on the reason you are pairing. This can often be reduced to the relative skill level of each member of the pair: 

• Expert-with-expert – Your aim in this situation is likely tackling a hairy problem that frankly no one has tackled before where each member of the pair brings a particular perspective to the party. Such a problem may yield even better to mob programming. Another good reason for expert-to-expert is for two experts, ping-pong pairing tends to just be the most fun. 
• Expert-with-novice – First, recall that “expert” and “novice” are always contextual. Let’s say Joe have been programming in Ruby on Rails for years using Vim. Jane has been programming for a couple of years in Java and is a master of the key shortcuts in Eclipse. Who’s “senior”? It depends ... In general, the expert should stay in the role of navigator (hands-off keyboard) while the relative novice should be hands-on keyboard. This maximizes the senses the novice has engaged while learning something new, and the fact that the idea is being communicated, creating space for question/conversation, enhances learning.
• Expert-with-novice (extreme version) – If quick learning is the primary goal, then “ball-and-board” is preferred: the expert has control of the mouse. The novice has the keyboard. This makes it possible for the expert to literally point where they are referring to, but what gets done there is done by the novice. Expert is not allowed to use right-button clicks either: to facilitate the novice learning about linters and the suggestions the IDE is making, both can have a mouse and the pair has the develop the discipline to make it work. This is a short-duration special-case version of strong-style pairing (see above). It is especially powerful for learning a new IDE where the layout and learning where-to-look or where to type may be very different than what the novice is used to.
• Novice-with-novice – This is generally not a productive pairing and producing excessive flailing.

Hope this helps. It's the sort of questions I get a lot.