Pair programming should not be used to train inexperienced or less-skilled developers.

Studies and meta-studies that support pair programming on a general, conceptual level, almost invariably find that the gains in quality and productivity only outweigh the added cost when both programmers are at roughly the same skill level.

In fact, this has pretty much become a “rule” in academic settings. Universities which recommend the practice also state explicitly that students should find a partner with the same skill level. Not better, not worse – the same.

Note that “skill level” here is domain- and task-specific. Pairing a brilliant UI developer with a brilliant algorithm designer or database developer is no better than pairing a brilliant UI developer with a totally green UI developer.

The studies (corroborated by my own personal experience) show that inexperienced developers (in some area) learn faster when paired, and highly-skilled developers can catch serious misunderstandings and design problems much earlier, negating much of the time spent on debugging and rework.

However, there is a gradient of almost 10x the productivity for the least vs. most skilled developers. Pairing someone highly-skilled with someone very green is very much like pairing a driving instructor with a student. You don’t have real co-operation, you have a driver and a passenger, a master and an apprentice. If the apprentice “drives” then the master is too busy monitoring and correcting errors to get any work of his own done. On the other hand, if the master “drives” and the apprentice is told to watch and learn, the master is less productive due to the interruptions and the apprentice does not learn very effectively.

This is a no-win situation. If new developers need to be trained, then call a spade a spade and train them. Or apprentice them, have them “shadow” a more experienced developer for a while. But don’t call it “pair programming” and expect to get good results. Those only occur when both partners have similar skill sets.

_{Note: For those who can’t view the study, here is another one making similar claims:}

_{Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise.}

_{To quote the abstract:}

_{The observed benefits of pair programming in terms of correctness on the complex system apply mainly to juniors, whereas the reductions in duration to perform the tasks correctly on the simple system apply mainly to intermediates and seniors.}

_{Pairing a senior with a junior negates the time benefit that applies to seniors. There is still an improvement in correctness over what the junior would normally produce, but it is not proven to be better than what the senior would produce on his own.}

_{Keep in mind that this is just a single study, whereas the first study is an actual meta-analysis which incorporates several different studies. It is by far the best resource I’ve found. Anyone who is truly interested in learning about the actual research should consider getting an ACM membership, because that’s where all of these studies are published.}

Strongly disagree with this answer.

I have previously mentored junior developers and new joiners through pair programming. On a review, they found it very useful and they were up to speed much quicker than people who were left on their own.

When I was driving, they saw me use a range of short cuts within IDE which significantly improves my productivity. When they were driving I encouraged them to use the same short cuts – within days they were already more productive.

Unit testing was another area. Many junior developers had no exposure to unit testing. I was able to demonstrate them how we write test, what our naming conventions are and what a good unit test looks like. When I was ‘navigating’ I was able to advise ‘driver’ as they were writing tests.

I disagree with this answer.

I have found that pair programming, whether the same level or different to be very useful for many reasons.

I have definitely seen it used to train less experienced programmers (to directly answer the question).

I think that it works because:

• passing on program knowledge and what the various parts mean and do is often best done through period of pair programming.

• there’s nearly always differences in skill and experience levels between programmers due to experience, background, etc. So ‘at roughly the same level’ rarely applies in practice in my experience.

• good programmers know to both learn from others and also teach and pass on their own knowledge through pairing.

• good pairing often results in BOTH people spending tie at the keyboard. My favorite person to pair with and I used used to call these the ‘ach, I’m stuck (person 1)’ paired with ‘here, gimme the keyboard let me try, I’ve got an idea (or the energy to continue!).’

• even the best programmers need to learn the domain that they are working in and how it is represented by code and data and pair programming is often a great way to do that.

I use PP in my work in a similar way – with newcomers (not necessarily unexperienced pragrammers). Usually this is one week period. After this all the goals listed below are usually met.

Goals:

1. Period of familiarization of a newcomer with the code base will be significantly reduced. When you need a man to be involved in your project and to get a result in two weeks this works perfectly.
2. You as a manager will understand how a man thinks. This will help you to work out an approach to work with him.
3. Newcomer will have an introduction of a coding culture of the project.
4. Unexperienced guy will catch how an experienced one works during coding. This will help to understand where to improve.
5. Experienced guy will teach you a couple of nice how-to’s.

Pair programming is a skill in its self, and the benefits of pair programming can be quite widespread and varied, depending on when and how its used.

I’ve used it when managing a team of quite inexperienced programmers as an orientation tool when new programmers join the team. (We talk about what I am doing on the first task, as I am doing it, and then we talk about what they are doing on the second task when they are doing it, and on the third task we talk about their intended implementation and the review of their code. – goal: code orientation and setting expectations for their work.

I have also used it as a training technique, where someone is being introduced to a new technique. In this case, they would be introduced to the concept away from the keyboard and then a few hours or a couple of days later, we would pair program the design phase, and they would be the lead programmer doing the implementation, with me providing guidance where needed. – goal: introducing multi threaded code / async callbacks and producing something productive in a shortish period of time.

As with most things Agile, I feel the answer is “It Depends”.

Is the less experienced person attempting to learn a new language (or other base skills) or do they already have the requisite skills and just need to learn a new application? If they are attempting to learn a new language or skill, I would argue mentorship may be more appropriate. If you are on-boarding someone new to the team who has the skills, then paired would be the way I go.

I agree with the point regarding not pairing a master with a new green developer, however I disagree that they should be the same skill level. I think the key is pairing people who are close to the same skill level.

As far as frequency of use, I think your team members should be able to help you with that one. Perhaps there is a story that is particularly tricky that the developers will want to pair on, other times there may be a story that is pretty straight forward that someone wants to do on their own to have time to decompress.

One final thought, when pairing, try to have the least experience person on the keyboard. If the more experienced person drives, then there is a tendency for that person to write a whole bunch of code, with the explanation of “I will explain that in a minute, just hang on”. If the less experienced person is driving, then the conversation around what to do / how to move the code forward, tends to happen in a more timely manner.

Cheers!