pair programming and teaching

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.

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.

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.