Skip to content

Comment on Why We Killed Off Code Reviews

Comments

So their main argument seems to be that pair programming somehow has less overhead than PRs? I personally don't see how that is possible. Or if it really is, how much less overhead can it be?

I like pair programming, but it's still only two people. Committing straight to master without anyone other than those two people seeing the code is crazy to me.

To me the point behind PR driven workflow is more so visibility than reviews. Just being able to see code and catch it before it's committed to master is the biggest gain.

[I'm at RealScout.] Our pairs rotate, and they work across different stories in the same epic. So more than two people (on our four person team) see the code that's being committed.

At this point, how does this not count as "code reviews"? You may not be using a PR based workflow, but it sure sounds like code reviews are in fact happening beyond simply "pair programming".

Not only is the blog title a little inaccurate, it's also clickbait.

Code reviews, traditionally, are a much more formal affair.

"Rotating pairs" means that you frequently change one half of the pair on a story or epic, to ensure constant diffusion of context about a codebase.

So for example:

Day 1: A & B work on a story.

Day 2: A rotates off. B & C work on the story and complete it. They pick up another story from the same track.

Day 3: B rotates off. C & A work on the new story.

At each point, you preserve and then share context.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.