Well, my first paired programming experiements date back 3.5 years now.  I'm going to be blogging on a whole bunch of related stuff soon as far as tweaks to pair programming that I've personally found beneficial.  But before I get to that, I wanted to reprint a portion of an article that I wrote for the abuzz newsletter 1.5 years ago.  I found that everything I said back then has continued to hold true, and so here is is. The original title of the article was "Paired Programming Obstacles".

Purpose
The purpose of pair programming is to produce better solutions with better designs and code. This does not mean that someone looks over your shoulder and points out syntax errors (the compiler will usually do this for you). Instead make sure that the problem is clearly understood (in the same way), the coding approach makes sense, and that the code can be easily be understood by someone else looking at it later.

Distractions
While it may seem like pair programming would cause many distractions - well actually it does! However, distractions happen every day (email, web surfing, etc...). A distraction is anything that is more compelling than the work to be performed. The goal of the pair should be to really make the work as interesting to each other as possible thereby making it more compelling than all of the other would-be distractions surrounding us. Yes! Work CAN be interesting, compelling, interactive, and FUN!

Conversations, Controversies, and Arguments
Pair programming will fail without conversation. If both people are not very good at starting conversations you might be in trouble. Fortunately, the work to be done is usually sufficient to get things rolling. If not, remember that 95% of all conversations start by someone asking a question. Controversies are part (in my opinion the most interesting part) of pair development. However, remember that the goal is to produce the best code possible, not to be right. If someone is just trying to be right, then that is an argument, which should be avoided as they are unproductive. Usually a third party can be brought in to bring things back under control.

Skill Levels
A programming pair should always be at similar skill levels. When working with a much more experienced programmer you will tend to sit back, be quiet, and enjoy the ride. When working with a much less experienced programmer you will tend to push forward without getting your partner's input. Both of these tendencies are really the same problem from different perspectives - Ego. In the first case, you don't want to feel dumb by asking basic questions. In the second case, you don't think your partner could possibly help you. In both cases neither programmer is going to get much out of the experience, and the code won't be much better than if the experienced programmer did it themselves. Humility and better pair matching is the way to combat these natural tendencies.

Now What?
No grand conclusions from me this month. My hope is that someone out there will learn something from reading this - or disagree and teach me something. After all, that's the most rewarding part of pair programming from a participant's point of view - you can't help but learn.