Should Senior Developers Pair Program?

I am a proponent of pairing (not just for programming). Anytime I introduce it to a new team I get a number of objections. The most prominent is that pairing slows me down (because I am so awesome and everyone else sucks so bad).

The logic goes something like, if I am good (and fast) and you are good (and fast) we could be just as fast alone as we are together. Since we are both good do we really need to pair? or I am good (and fast) but you are bad (and slow) so pairing with you means we will never get anything done because you are slowing me down too much. Maybe I am good (and fast) but you are okay (and not fast or slow) then maybe we should pair because we can be fast but I can make you better.

The problem here is that there is a belief that pairing is about going faster. It isn’t (at least not in the short term). It is about achieving something greater together than we could alone. A great African proverb goes something like “If you want to go fast, go alone, if you want to go far, go together“. Pairing is about improving together.

So I might slow you down. It means I am learning and by default you are teaching. Together we are both improving. If we think of it as a marathon instead of sprint we can see that together we can get much farther by slowing down to speed up.

Definitions of Pairing Partners: (Dreyfuss Model)

Novice (Advanced Beginner)
Has little domain and/or technical understanding. This is your classic n00b, junior developer or intern.

Competent (Proficient)
Has some domain and/or technical understanding. This is your standard developer.

Expert
Has deep understanding of the domain and/or technical aspects of the system. This is your senior developer.

Here is my theory on combinations of pairing:

Novice and Novice
In this match up the production will be very slow, but the learning will be tremendously high. This is because the pair is totally reliant on each other for discovery because they have no other choice and no existing knowledge.
Learning: High Production: Low

Novice and Competent
Production will be moderate as the competent programmer will often not try to explain too much and will work at close to a normal pace for themselves bringing the novice up to their speed. The learning will be fairly high because neither has all the answers and are dependent on each other.
Learning: High Production: Medium

Novice and Expert
Production will be low as the expert is often a poor teacher and goes into too much detail explain concepts too difficult for the novice. The novice likely will ask a lot of questions and be confused. However production will still be greater than two novices. The novice will likely learn a lot, but will be drinking from a fire hose while the expert will learn new things by teaching. Overall yielding a medium learning level.
Learning: Medium Production: Medium

Competent and Competent
Production will go at a good pace as the both participants are at the same level allowing for a cadence to develop. Learning will be good for both as their shared level will allow for maximum trust.
Learning: Medium Production: Medium

Competent and Expert
Production will be high in most cases as the expert will not have to explain things in detail. Learning will be medium as the competent participant is often reluctant ask questions and the expert tends to lean towards auto pilot mode.
Learning: High Production: Medium

Expert and Expert
Production will be high as the energy level will be strong and the cadence rhythmic. Learning will be low as neither participant will likely ask a lot of questions or seek new understanding.
Learning: Low Production: High

So why bother pairing if production is “High” in a majority of pairings? Because we are not worried about this iteration/sprint we are worried about 100 iteration/sprints from now. Below you can see the difference in production over time between teams that do promiscuous pairing of multiple types versus teams that do no pairing at all.

Together (Pairing)

 

Alone (Not Pairing)

 

 

 

 

 

 

 

 

Does your team want to go fast or do they want to go far?

Comments are closed.