Is Pair Programming also used to train less experienced developers and bring them up to speed?

Also, how often is it used e.g. all the time i.e. the two developers will work together at one screen permanently or perhaps one day per week? I have read an Agile book, which talks about this concept but it does not mention frequency of use.

When we think of pair programming in the agile sense, there's more to it than just two people at the keyboard and it has little to do with the task complexity. I guess there could be some programming tasks that are so trivial having two sets of eyes is counter-productive, but who does that kind of stuff?
–
JeffOSep 9 '13 at 13:17

6 Answers
6

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.

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:

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.

+1: I've also found this to be true in practice. I would also add that on straightforward or trivial implementations pairing has provided little to no benefits.
–
dietbuddhaSep 9 '13 at 2:53

11

I am under the impression this is getting just play of words - when you bring two devs in front of one screen, call it either "pair programming" when they are both equally skilled, and call it "training" if they are not. Both cases seem to bring benefits.
–
Doc BrownSep 9 '13 at 5:34

5

Not meaning to be pedantic, but how is it a no-win situation if "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."
–
Bernardo PiresSep 9 '13 at 8:56

4

I disagree with this answer substantially. Pair programming when done in a cooperative style is very effective in creating a common culture in a team
–
PtolemySep 9 '13 at 13:59

2

@aaronaught, you say based on research, how did they measure the skill of the participants at pair programming as part of the research? and then did they adjust results to eliminate the skew that may be caused by people with different skill levels of pair programming.
–
PtolemySep 10 '13 at 8:29

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 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'm pretty sure that the interview is where you are supposed to figure out how someone thinks and introduce them to the culture.
–
AaronaughtSep 11 '13 at 0:37

1

@Aaronaught there is difference between a two hours interview and one week cooperation, isn't it?
–
RigaSep 11 '13 at 22:32

And there's a difference between one week of buddying up and 6 months of working on the same team. Point is, you should have a pretty good idea of how a person codes and approaches problems before you even hire them in the first place.
–
AaronaughtSep 11 '13 at 23:56

3

@Aaronaught I guess you are arguing for the sake of arguing. As you have stated period of time makes sense. What is the problem then? If you are the guy who knows everything about a person after the interview then wow, you are super cool guy I never met. My experience can't be alienated from me. Interview gives you understanding whether the guy will manage to get things done. Other things is a long story and it is a good idea to start with pair programming. Your "true" understanding can't override this fact.
–
RigaSep 12 '13 at 0:15

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.

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.