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.` 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.}

_{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.}

_{Anyone who is truly interested in learning about the actual research, as opposed to anecdotes and rhetoric, should consider getting an ACM membership, because that's where all of these studies are published.}

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.}

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.

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.` 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.}

_{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.}

_{Anyone who is truly interested in learning about the actual research, as opposed to anecdotes and rhetoric, should consider getting an ACM membership, because that's where all of these studies are published.}