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

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.