11–20 of 25 posts
Earlier quoted context omitted.
I'm confused, you're questioning the author's sincerity in expressing his own enjoyment of pair programming? I deeply enjoy pairing. I know quite a few folks that do as well.
Ok, fine then :) I admit I've never met anyone so genuinely enthusiastic about pair programming, so it sounds unusual to me.
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'v…
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 lar…
I'm curious how other things that are intrinsically non-pair activities fit in.
Great post. 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.
Great post. 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.
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.
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'v…
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.
An unrelated note to the author: Please contemplate adding an RSS/Atom feed so that your blog may be easily followed.
A problem with code review is that people treat is as proofreading a final project, so it isn't effective for collaboration before a solution is obvious and quick to code up. 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.