Maybe I can provide some insight, since I'm seeing a lot of "I've never tried pairing but I bet it sucks" kind of comments: I've been pairing for about two yea

Maybe I can provide some insight, since I'm seeing a lot of "I've never tried pairing but I bet it sucks" kind of comments: I've been pairing for about two years now with a broad array of partners-- I came to work for a startup whose policy is "all pairing, all the time" for any code that goes into production. I was pretty leery of the practice initially. What I've discovered is that pairing is just like anything else: it depends completely on the people involved. There is no faster way to get bootstrapped on a new technology or codebase. Period. This is not a junior dev/inexperienced coder argument; finding all the holes and tweaks in a new library or package takes time regardless of how good you are-- if you're pairing with someone who knows the new tech (in my case, it was RSpec) you're getting constant guidance, tips, and corrections. Pairing can help stop you from putting stupidity in the code. Many, many times I've been called out for trying to take a shortcut, skipping or forgetting a test, or just making a dumb mistake. It's a little appalling how many brain-dead dumb mistakes programmers make (Yes, that includes you. It doubly includes you if your first reaction was "I hardly ever make mistakes!"). Code quality is worlds better. Programmers tend to pick the first solution they like and implement it; pairing forces you to justify that decision. Focus is much, much higher. When solo progging (for side work or personal projects) I've noticed I tend to defocus when I hit a hard problem I need to think about. This is the danger zone where I may click over to my email or twitter feed "for just a second" while I'm chewing on a problem. You back out of dead-ends a lot faster. Getting stuck looking up some arbitrary or incomprehensible behavior in a library is far less frequent and painful when you've got two people working on it (one of whom may already know how/why something is happening). There are a number of other benefits that you can find in any discussion of pairing, the above are the big benefits that stand out to me. That said, there are a couple people pairing will not work for: Mr. "This will never work." Self-fulfilling prophecy, enough said. Complete incompetents: these are rarer that you might think, but you just can't drag someone along in a pairing situation. Before long they'll be surfing fark.com while you do the work. Bulldozers: Some folks just pick a "solution" and will implement, fight for, and force that solution at all costs, no matter how bad it is. The Lazy: Fights tend to crop up when one person wants to do something the right way, and the pair partner's argument is basically "But that's a lot of work!" This is where you usually see disagreements crop up about "over-engineering" vs. "sloppy code." In short, pair programming can be a wonderful practice that produces super-high-quality code in a fraction of the time. It takes dedication and effort from both partners. I think a lot of programmers fear it because they worry they'll be outed or labeled as incompetents or slugs-- it pays to remember, though that the point of pairing is not to engage in a mutual junk-kicking, but to finish work, improve the code, and improve both programmers all at the same time.