[simonista]

Great post!

In the pairing paradigm (say that 5 times fast), how much of a typical day is spent actually pairing? How do you manage email or other company wide communication? What happens when a server crashes or another emergency comes up? Or when another pair has a question that you can answer? Or when one member of the pair is also responsible for a deploying something? Or one member has a meeting?

Disclaimer: I've mostly been exposed to the code review paradigm (I work with Paul at `current_job`)

[phinze]

In my experience, a day spent pairing, while generally a sort of intense experience, is also filled with little breaks. Your pair gets up to grab a drink; you check your email; somebody turns on a Katy Perry single and you spin around to join a team-wide argument about its merits; etc, etc. :)

While nearly 100% of your time is _dedicated_ to pairing, I'd say the percentage of time you both spend actively sitting at the computer working on a task is roughly equivalent to what you'd do as an individual. Which is to say, it varies. But it never really feels like you can't do side things; the vibe is very flexible and casual.

For deploys and emergencies, it's almost always a pair attacking the problem. Even if just one developer is doing most of the driving, the pair is still able to learn, catch typos, diagnose, etc.

Meetings can definitely end up splitting pairs, which becomes yet another incentive to try to minimize them.

[makmanalp]

Usually pairing seems to work great to get you through things that seem like they're a slog. So you don't have to pair through everything, just the hard and boring bits. It helps to timebox it, and say it's going to be (e.g.) an hour long session to prevent it from taking forever and help focus. Even if you're not done, chances are you'll have made good progress. So, schedulingwise, it's a bit like a meeting.

The largest benefit I see is that having someone with you is like having more than double the focus and vigilance, since you're both there to help each other out and you'll both tell each other when you're leading yourselves astray, which doesn't happen when programming individually.

Pair-design also works great.

I think it's harder to be as productive in code review (and I think they aren't mutually exclusive anyway) because people tend to focus more on nitpick changes like style issues, and miss the larger design stuff.

[simonista]

Sure, but my question was in the context of the OP definition of "pair programming culture" as "a team that does nearly 100% pairing ... The day-to-day experience of programming is that of a day-long conversation with your pair"

I'm curious how other things that are intrinsically non-pair activities fit in.

[JoshTriplett]

I've done pair programming extensively, both for personal projects and at work. Pair-programming sessions are not the time to process email; IMs/IRC are treated as interrupts (quickly check if an urgent response is needed and otherwise defer); meetings are something you schedule pair-programming sessions around; deployments are a great thing to do as a pair to reduce screwups.