Misko says that the productivity hit of pair programming in minimal because most programmers program only 10-25% of the time; the rest is spent reading email, going to meetings, and the like. Huh? I thought we flattened the management hierarchy and instituted agile programming to get rid of that nonsense.

He gives an extended example where pair programming enabled a new hire to configure his work environment in a half day (plus Misko's half day). I have found that a well documented setup procedure enables a new hire to set up his environment in half a day without involving a senior programmer. The second example of walking the new programmer through his first bug fix seems quite reasonable, but that is not pair programming in the large.

The comments seemed to be divided into two groups: those who were doing pair programming and loved it and those who were skeptical but were not pair programming. I admit I am in the second group. I would be interested in the experience of HNers.

That probably wouldn't work for me. I learn better by reading (good documentation; failing that, code) than by listening. Conversation can be erroneous, but code (even bad code) never lies. I think optimal learning methods differ from person to person.

But code isn't setting you up, human-written documentation (or, in the case of the article, humans) are.

There is a huge benefit of personal bootstrap over a well documented procedure: it's personal, a first step to build a good relationship and a great team.

"Even when you are coding, you spend a lot of time testing what you have just coded, and realizing what you have just done does not work."

This is not my case. Over years I developed a habit to write correct code at (almost) first attempt. Am I qualified for pair programming?

I think the article side steps the value in learning something well by doing it yourself (in the case of the new hire). I appreciate the confidence gained by pair programming and hand holding. But oftentimes even though they were able to be productive with a senior team member, that does not translate to having confidence or being productive when alone. Depending on how the pair worked together, the new team member could have blindly nodded their head. They'll still need to take the additional time to relearn or do it again themselves. In that case, I'd rather pair program to get them ramped up, work on something by themselves, then come back later to review what they've done without side stepping the value in self learning and exploration, which enables them to take ownership of the idea/methodology. Perhaps they'll even have a new approach which is healthy for the team at large.

When pairing, my recommended approach is to switch who is driving for every new test or method being written (sometimes called 'ping-ponging'). I can attest that, done correctly, this is extremely valuable when learning an unfamiliar technology. As a newb, you get to watch how the experienced developer does it, then it's turned right around and you have to do it yourself.

You can tear through some code pretty damn fast, and it is an awesome way to learn.

Thats a great article! I'm lucky enough to learned programming long years ago in a similar environment. Since then I've tried that in different companies but working culture or ego stopped these efforts at most of the time. After longs years I've found my perfect pair again just to loose him soon after as he moved to the other part of the world.

What is your experience with pair programming?

I spent two full days with my (soon to be) girlfriend writing Scheme for a college assignment using two keyboards and mice on a big desk.

It was awesome and not only because of the sparks.

Her ideas worked, but were complex. I typed faster, but my solutions were incomplete.

So we attacked the problem from two sides and it had to surrender.

The code that emerged was beautiful, clean and bug free.

I'm still trying to get her to code with me again :)