[mpc]

It's totally separate from the topic of efficiency gains or code reviews, but the idea of 100% pairing would take most of the enjoyment out of programming for me. Working in isolation (for the most part) to solve a hard problem and drive it to completion is incredibly satisfying. A lot of that goes away when you're working side by side.

You're never in "the zone" if you're pair programming.

[nickbauman]

I've been pair programming off and on since the beginning of the century. You can get in the zone with a pair (if you're doing it right), but less often. I get a huge charge out of the highfive at the end of a task. And often I'm learning something new or was made to think about something from a different perspective. That could be the whole point of life itself. It's enormously satisfying.

But pair programming evens out the peaks (programming in the zone) and valleys (spinning your wheels) though so you have something close to a sustainable pace. The productivity and life of the entire team is much more important than the productivity of an individual on the team. Sometimes I spend an entire day helping someone else accomplish something instead of what I want to do. Sometimes it's the reverse. People come and go. The mission is larger and longer.

[chrisconley]

Yeah, it definitely isn't for everyone. I also love getting into the zone too, but also enjoy pairing.

The most rewarding part of pairing for me is probably the learning/teaching dynamic.

[lomnakkus]

> The most rewarding part of pairing for me is probably the learning/teaching dynamic.

That can also happen during code review. Granted, it's asynchronous, but that might be seen as a boon by some -- especially if there's a language barrier.

You have to do code review right, i.e. a) no judgement of the person, b) no friggin' code review in-person meetings(!), and c) must be automated via some system (e.g. Gerrit), and d) the reviewer must also be willing to yield on non-critical issues (such as minor formatting, naming, etc.). Ultimately you also need a team technical lead to make the call in case of unresolvable disputes. (If the lead's code is being reviewed then it behooves them to reason convincingly for their own position, concede when shown wrong and try to remain as impartial as possible. IME as a team lead, admitting when you're wrong is an incredible way to build trust.)

[vosper]

Yeah, me too. I've done effective pair programming but my most enjoyable programming experiences are when I'm isolated (ideally at home) and focusing solely on the problem. Being in a pair prevents me from getting getting into that flow state.

Having said that, pairing is great for solving production problems. I remember one time right in the middle of a critical revenue period when we were having severe performance issues that appeared to be tied to our caching layer. This had been going on for about a week, with individual team members working on it, and we hadn't figured it out. Finally, it was the day of the company holiday party, but a handful of us were so uncomfortable with the state of the system that we coudln't enjoy the party, so we grabbed some beers and headed back to the office. In the space of 3-4 hours working (loudly) together in the empty office we'd hacked together a fix that got the system back on its feet until we could figure out the real solution. Someone would have got there individually, but the amount of work that little group got done in such a short period of time is one of my favourite programming memories.

[jacques_chester]

> You're never in "the zone" if you're pair programming.

I have ADHD-I, so I am acutely sensitive to the fact that my attention can easily wander.

I am more in the zone, more often, with a pair, than working by myself.