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`)
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.
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.
I'm curious how other things that are intrinsically non-pair activities fit in.
I am a bit suspicious of the ecstatic tone that the author has while writing about pair programming: I am not sure I ever met someone who deeply enjoys it; at best it's seen as good practice, or a necessary evil.
I deeply enjoy pairing. I know quite a few folks that do as well.
We use Gerrit code review, with side-by-side reviews. I.e. the developer pushes to Gerrit, then sits down with the reviewer and walks him through the code. 99% of the bugs are found by the original developer -- after he is forced to explain what he did (and why) to a colleague. I think that this gets you at least some of the benefits of both approaches.
I'd be curious to hear how the day-to-day schedule ends up working out between developers, since the review process is synchronous in this case.
One ting nice about code review is that the code must stand on its own to pass. That means that it's likely to be understandable a year from now.
We need more informal/preliminary ways to code-review work in progress
One thing the article didn't mention is that code review works across companies and is ideal for open source work.
Has anyone ever tried a balanced approach like this? Such as spending 2-3 days each week pairing on a part of a project to help with knowledge sharing, best practices, or possible bad paths, and then the rest solo coding with some final code reviews?
Also, what is the best form of code review? Is it having a single developer be assigned to perform a code review for each pull request or for it to have some gestation period for crowd comments to come in, or even some voting quota/discussion until a simple consensus is reached? There seems to be some room for a variety of time/quality trade offs (in theory, more eyes == higher quality, more time).
