In my experience, it is important to pair programmers of differing skill levels, but pairing an expert with the lowest intern to work on a very difficult problem can be a disaster. I’ve been the expert in a situation like that and it did not work. The intern and I spent all of our time just figuring out how to talk to each other because there was such a disparity in our experience. It would have been much better to have worked with a mid-level developer who, although they may have not been familiar with the particular problem domain, had enough experience to that they could be brought up to speed fairly quickly. I guess it depends on the definition of “intern” within a particular team.

One additional point that I would like to make is that the increased focus and productivity of pairing can be physically exhausting at first. When my partner and I started pairing, it took several weeks before we could go home at the end of the day without feeling like we had been “put through the wringer”.

Pair programming is like magic in more ways than one. It dramatically improves programmer productivity and reduces bug count, and yet it does so through a technique that’s completely counter-intuitive. You can’t help but think that there’s some t…

Mike – “being chained next to someone all day long”
mipsy – “You can’t really critique them.” (Trying to work on level footing with a boss – Awkward!)
Chocolim – “But if someone sit next to me and question everything i do or interrupt my thiniking, i will to punch him/her in the face” (Strong emotion…)

Pair programming is nothing more than working together to solve a problem.
When you think of it like this, it’s obvious that it will fail miserably in a couple circumstances.
- When two people can’t work together
- When there’s no real problem to solve (simple work)

It’s obvious that it will have some advantages:
- Working together can build trust and respect
- Two heads are better than one on difficult problems.

@Michael: I like your story, but I’m not sure it applies to me. I love arguing, and I love being proved wrong. I dislike having to justify every little decision and coming in behind schedule because of it. I find that my code and productivity is much worse when working too closely with others on the same problem. There’s such thing as too much feedback.

I speak from experience (in jobs, in education, in life) that when you pair a smart person with a dumb person the dumb person does not get much better and the smart person does a LOT worse. Of course, it’s entirely possible (if unlikely) that a pair consists of two people of roughly equivalent skill. In this case, I suspect they do better than they otherwise would. But enough better to justify double the cost? Not in any case that I’ve ever seen.

Now I should also say that I’m a huge believer in mentoring. I once put my best guy next to someone who was on the verge of being fired. After about 3 months she was the second best member of the team. But I have no illusions that I paid for this by having my best guy operating at much less than 100% during that time. It was a worthwhile trade, but not something I’d be sticking with longer term if possible.

But back to the original point. Assume I’m a programmer and not a manager. I really do want to know why I would be interested in something like this. I’m quite skilled and can walk out the door and into another job in a day. So tell me something besides “fewer interruptions” (which is huge, but can be bought much cheaper).