Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Pair programming is seen as a helpful teaching strategy - in fact, compared to singleton work, almost a magic bullet:

  • better learner satisfaction
  • higher exam scores
  • for longer - later exams continue to show higher scores
  • better results in later work that relies on the pair learning

Are there pitfalls to the strategy? When is pair programming most efficient for learning and when is it best avoided?

share|improve this question
What do you mean by "for longer"? –  Michael Shaw Jan 25 '13 at 14:41
@MichaelShaw, that later exams on the subject continue to show good results - in other words, students don't forget. Or so I'm told. –  boisvert Jan 25 '13 at 14:52

3 Answers 3

Personally, I think it's a terrible approach to learning. What happens, often (not always), is that the more-experienced developer drives and the less-experienced developer watches, thinks they're taking it all in, tries to do it themselves later and fails.

And, stuck in that situation, it's very difficult to go back and say, "Yanno, I've forgotten all that already."

Different people learn in different ways, but I'm willing to bet that most programmers learn better if they're given information and room to fiddle and seek their own answers, but have someone to go to when at least it's clear what question they should be asking (if not the answer).

Pair-programming is best when done by two seniors, alternating the driving, discussing the work as they go along. There is very little training in pair-programming -- there is knowledge transfer, as pointed out in the comments, but of a different nature. It's just an extra pair of eyes and a brain that can focus on other things than typing.

share|improve this answer
There are a couple of anecdotal stories of pair programming facilitating knowledge transfer on the C2 wiki. However, in all cases that I've seen, it's between developers who have some amount of education and/or experience to draw on, not in instances where one is actually learning how to build software for the first time (such as in an academic environment). The learning that is happening is typically learning the problem domain, business environment, or the specifics of the system under development. –  Thomas Owens Jan 25 '13 at 14:51
"Pair-programming is best when done...", yes, if the measure is productivity. But if I seek a different output? –  boisvert Jan 25 '13 at 14:55
@ThomasOwens: Fair comment. I'll adjust that slightly. Reading it back, it wasn't exactly what I wanted to say. –  pdr Jan 25 '13 at 14:56
@boisvert: Actually, if the measure is quality, not productivity. If you seek a different result, look at a different technique. –  pdr Jan 25 '13 at 14:57

The primary goal of pair programming is to come with better or more innovative approaches than a single developer can imagine. When both developers are equally skilled, it works well. But when one of them is much less skilled than another, pair programming would be useless.

From the teaching perspective, it doesn't work neither. Instead of working as a pair (developer A writes code for a few minutes while developer B gives her feedback, then developer B writes code for a few minutes, etc.), the more skillful developer will write code all the time, or if the less skillful one will start to write, will criticize all the time.

What you may try instead is code review. Code review has a common point with pair programming: the fact that two developers can notice more things than one. The difference is that code review is especially helpful when the reviewer is more experienced or skillful than the original author, which also means that it may be helpful for learning purposes.

Pitfalls to the pair programming for learning purposes:

  • Difficulty for the student to actually write code.

  • Few people enjoy listening to critique while they're writing.

  • There is small room for learning new things.

  • The learning scope is limited by the code.

Pitfalls to the code review for learning purposes:

  • Few people enjoy receiving negative critique about their code. The difference with pair programming is that you're not receiving it as you write, and if the critique is severe, you can calm down and go back to code later.

  • The learning scope is still limited by the code.

share|improve this answer
I like the alternative. Also, the advice - pair people of equal skill - is something my colleagues and I can work with. –  boisvert Jan 25 '13 at 15:01

I question the basis | assumptions behind all of your bullet points - especially without any reference to back those claims up. The technique has been around for quite a while now, and if it was the magic bullet you perceive it to be then it would have a much broader acceptance.

So are there pitfalls to the strategy? Clearly so, otherwise more would have adopted it.

Granting the claims, when would it be most efficient for learning? When:

  • One person has more knowledge than the other
  • That same person has the ability to clearly explain what and why they are doing things
  • The other person has a desire to learn
  • The other person has a learning style that works with pair programming and not everyone does
  • The other person can get along with the first person and vice versa

That's a large number of dependencies for a population that tends to be introverted to begin with.

share|improve this answer
I left the claims without reference out of kindness to the reader... following up discussions that are themselves poor wouldn't have helped. As a colleague tells me "there is a lot of belief in education" –  boisvert Jan 25 '13 at 15:04
Hasn't it ceased to be pair-programming by that point and become ... training? –  pdr Jan 25 '13 at 15:04
For "a population that tends to be introverted" shouldn't education work to change that? Granted, I didn't make that point in my original question. –  boisvert Jan 25 '13 at 15:05
@boisvert: Introversion is a personality trait, not something anyone can change. –  Michael Shaw Jan 25 '13 at 15:11
@boisvert - In short, No. At length, no because introversion is not something that needs to be changed within someone, nor is it even an attribute that can be changed. Introversion is an innate characteristic which is neither good nor bad, it simply is. Some introverts may learn how to act extroverted in order to more fluidly move within society, but they are still introverts. –  GlenH7 Jan 25 '13 at 15:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.