Pairing vs. Code Review: Comparing Developer Cultures
phinze.github.io
Pairing vs. Code Review: Comparing Developer Cultures
1–10 of 25 posts
Re: Pairing vs. Code Review: Comparing Developer Cultures
#2I don't see the two practices as antithetical: complex features with a lot of potential pitfalls take advantage from pair programming; code reviews are perfect for BAU tasks.
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.
Re: Pairing vs. Code Review: Comparing Developer Cultures
#3Great 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`)
Re: Pairing vs. Code Review: Comparing Developer Cultures
#4Great 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…
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.
Re: Pairing vs. Code Review: Comparing Developer Cultures
#5A 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
Re: Pairing vs. Code Review: Comparing Developer Cultures
#6I don't see the two practices as antithetical: complex features with a lot of potential pitfalls take advantage from pair programming; code reviews are perfect for BAU tasks. 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'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.
Re: Pairing vs. Code Review: Comparing Developer Cultures
#7I don't see the two practices as antithetical: complex features with a lot of potential pitfalls take advantage from pair programming; code reviews are perfect for BAU tasks. 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 worked with the author at last_job and can attest to the genuineness of his tone. Pairing is pretty fun when you like your coworkers.
Re: Pairing vs. Code Review: Comparing Developer Cultures
#8I don't see the two practices as antithetical: complex features with a lot of potential pitfalls take advantage from pair programming; code reviews are perfect for BAU tasks. 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'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.
Re: Pairing vs. Code Review: Comparing Developer Cultures
#9Great 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 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.
Re: Pairing vs. Code Review: Comparing Developer Cultures
#10Great 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.