Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pairing vs. Code Review: Comparing Developer Cultures

phinze.github.io

Post reply on HN
Print view View original

21–25 of 25 posts

Re: Pairing vs. Code Review: Comparing Developer Cultures

#21

Post by ssgelm »

southpawgirl wrote: post #2

I 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 definitely genuinely enjoy pair programming as long as it's with the right person. In the end it's all about who you are working with.

Re: Pairing vs. Code Review: Comparing Developer Cultures

#22

Post by jdost »

Great read! Upon finishing, the two sides seem to be opposite solutions of a good problem (that is getting a non singular path to guarantee code quality). It seems that the best solution is a mixed approach. Using pairs to gain the benefits of knowledge sharing and sort of check ups (that is having a second pair of eyes to achieve the intermediate commit/review issue). But also using a large amount of solo coding with code reviews to ensure overall quality without missing out on the non-pairing types.

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).

Re: Pairing vs. Code Review: Comparing Developer Cultures

#24

Post by w_t_payne »

phinze wrote: post #13
w_t_payne wrote: post #10

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.

This is an interesting practice, thanks for sharing. I'm really curious about different sorts of hybrid approaches being used in the wild. 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.

The synchronous aspect is a problem, although not a huge one. The issue is mitigated to a certain extent by excluding non-customer facing research & testing components from the review requirement. Also, the architecture of the system is such that people tend to work very independently, with little-to-no overlap, so reviews can be postponed with little impact on velocity. As our team grows in size, we could also think about instituting a rotating code reviewer responsibility, with team members taking it in turns to act as the designated reviewer for the day.

Re: Pairing vs. Code Review: Comparing Developer Cultures

#25

Post by w_t_payne »

jeffdavis wrote: post #15
w_t_payne wrote: post #10

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.

Unfortunately the explanations aren't left as code comments, so they may be lost. 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.

Written documentation does have the advantage of being persistent, and supports an unlimited producer-to-consumer fan-out. However, documents have a pretty lousy bandwidth and knowledge retention rate compared to face-to-face communication. If you are working in a small team with low staff turnover, face-to-face beats written docs hands-down as a knowledge transfer mechanism. On the other hand, if your staff turnover is high, or if your team is huge, then you absolutely need to write everything down. I am working in a small team, with low turnover, so face-to-face works best for us in this particular instance. (We still document what we do pretty well, though, with both regular source commentary and tools like Doxygen, but as a matter of professional pride rather than necessity).
Post reply on HN