> First, pair programming has to be between near-equals, or it just doesn't work.

That depends on what you think the goal of pair programming is.

> If one person knows a lot more than the other, most of the time is spent in training.

Which is part of the intended effect of pair programming. It forces everyone to share their knowledge with everyone else both about programming, and about the code base. This brings new people up to speed quicker, allows the more experience to better share their knowledge, and protects the company from having too much knowledge locked up in one individual.

I agree.

To the GP's point though, they still weren't doing effective pairing for the 'training' or 'coaching' scenario. The pairing was contentious and out of balance. The coach didn't do any coaching.

> ...if I paused too long, or seemed to be typing the wrong thing -- my pair had another keyboard, and he would type over me to try to “finish the sentence” rather than talk to me.

In this case, a coach should engage the driver. Ask about what he's thinking and nudge him in the correct direction if needed. Coaching is a lot like driving school. The coach uses his brakes (keyboard) very seldom. If the coach is using his brakes very often, it is as likely as not that the coach is the problem (too scared, poor instruction, etc) and not the driver.

There are simple tricks. I usually put my keyboard behind the monitor. I've also turned my keyboard around so that I'm looking at the keys upside down. Those both take physical effort to get the keyboard in position to type. Another strategy that I've heard is oven mitts (I really want to try this one!) :)

Edit: Also, another strike against his coach (though this is more programming related..)

> To me, this was “refactor mercilessly” and “once and only once.” But to my partner, this was a violation of “do the simplest thing that could possibly work.”

I'd agree with the OP here. Simplest thing is how you get tests to pass. DRYness is a property of code quality. They are orthogonal. Refactor mercilessly when you have green tests in order to keep quality high. Do the simplest thing when you have a red test in order to deliver features.

> Simplest thing is how you get tests to pass. DRYness is a property of code quality. They are orthogonal. Refactor mercilessly when you have green tests in order to keep quality high.

And once tests are passing, you should be able to convince your partner the code isn't dry simply by pointing out duplication, preferably 3 or 4 instances of it so you have enough examples to generalize a solution. You don't need tests to convince him something needs done.

In this case, though, the pair was limited to the abilities of the weaker member.

As it should be; a weaker member is like a failed raid drive rebuilding until it's up to speed with the team. You expect things to go slower until he's up to speed. If speed is necessary, the senior programmer can always drive and let the other guy watch and ask questions, or explain as he goes along.

But, in this case, the weaker member was the senior--seniority in the company, anyway--and kept the stronger member from getting anything done.

This seems like a common excuse I see to criticisms of pair programming. If this technique is so fragile, perhaps its just better to admit up front that it is delicate and easy to get wrong, and only works in particular situations with particular people.

"If it failed then, there's no reason to think we can't make it fail now." -- Colin Benson, in the IMPP working group, circa 2000