Pair Programming Is Done By Peers

From PairProgrammingDoubts:

Ideally, PairProgrammingIsDoneByPeers. Each knows something the other doesn't, each has characteristics that the other does not have, but they think of the other as an equal partner. When a very senior person pairs with a beginner, the senior person is tutoring the beginner. This can be good, but it is not a typical example of pair programming. -RalphJohnson

I thought this concept deserved more emphasis, so I started this page. -- RobHarwood

It's my understanding and from experience that you should mix programmers of difference experiences. This will spread information around. If you don't InvolveNewbies, they will perpetually remain uninvolved and dead weights. Further, this reduces your TruckNumber. Of course, you shouldn't match extremely expert people with extremely junior people. Consider how the Go teaching ladder works. http://senseis.xmp.net/?GoTeachingLadder. -- SunirShah

Yes, one rule of thumb I heard was to pair people at 1 level apart, and have the weaker partner do most of the driving. However, even if this isn't done, there is evidence to support that two people of equal levels will still learn from each other, presumably because each person has unique strengths and weaknesses (see LaurieWilliams' research).

The point is not that they are identical (or even very similar) in skill, but that they view each other as equals. This is to promote collaboration and reduce frustration.

TheCoach can be "a development partner" (ExtremeProgrammingExplainedEmbraceChange pg 74)

Can one member of the pair have "final authority" over disputes? My organization is flirting with some XP practices, and while I'm normally big fan of pairing, I turned down an offer to pair with our architect, because he gets to have final say on disputes, and frankly I've usually found it easier to present him with a fait accompli.

Pairs should be peers. I've had success with bringing in a third person whenever we needed a casting vote (happens a few times a week)

Conversely, in discussions with a friend who's company is doing very rigorous XP comments that when a pair have opposing opinions on how to proceed, it can be very difficult to break the deadlock.

This is often the case when people have incompatible ideas of the future direction of the code. "YouArentGonnaNeedIt" can help solve many of these conflicts. A good knowledge of refactoring and the insight that no design is final will also help. Your architect may have a problem with all of these things.

CategoryPairProgramming