Where Pair Programming Fails for Me

Where Pair Programming Fails for Me
tersesystems.com

First, pair programming has to be between near-equals, or it just doesn't work. If one person knows a lot more than the other, most of the time is spent in training.

Second, if the other person just starts typing, it isn't really pair programming. It's what we call 'peer programming' where you peer over someone's shoulder and they do all the work.

'Peer programming' happens a lot with mis-matched skill levels.

I didn't read the rest, but I assume it's all as much a bastardization of Pair Programming as the first bit.

PP didn't fail you. Your coworkers weren't using it.

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.

(emphasis mine). What an incredibly familiar description. Does anyone else ever feel this way? This is why in situations where I'm trying to describe a solution I end up just grabbing the keyboard, doing it myself, and letting the code talk for itself.

For me, pair programming comes easily when describing a solution that can be simply defined and understood. Doesn't matter how difficult the problem itself is. Pair programming becomes more difficult once you have to interrupt your coding to facilitate the process. As an introvert, this comes incredibly unnaturally to me.