Ask HN: Does your team do code review? How? Why not?

That said, there were two major strategies that we used:

Strategy 1: Gatekeeper

The project lead heads up the code reviews. She is the gatekeeper that determines whether code is good enough. For minor bug fixes and small changes, one extra set of eyes is generally sufficient. For larger changes and new features, she often recruits one or more developers to assist with the code review. All code review takes place in Github, with face-to-face meetings if there are any nuanced discussions that need to happen.

The major upside to this is that the lead knows what the big picture is. She knows if Joe has worked on this feature and should be consulted or not. She knows that Sarah is very familiar with this technology and should be consulted. She knows that this feature can't go out until that feature is. She knows that this bugfix might affect Henry's feature. This means that she can properly coordinate releases throughout the team and make sure everyone's on track.

The major downside is that there's a single point of failure. If the project lead isn't thorough, bad shit can slip through. Doesn't happen often, in my experience, but enough that there should have been more failsafes.

Strategy 2: More Eyeballs

Nobody "heads up" code review. Each pull request requires two people to approve it. Any number of people can comment and review it, but the minute the second person says "Looks good to me" or "+1" or whatever, then the PR is allowed to be merged.

The major upside to this is that you get more eyeballs on the project. You'll have a couple of different perspectives, so there's a greater chance that everything has been thought of.

The major downsides to this are: no birds-eye view, choosing the reviewers, and coordinating fixes/features. A big hurdle to this is choosing the reviewers. If you have 6 people on the team, and 2 people need to approve it, who do you pick? How do you pick? Randomly? Round-robin? Imagine that you know that Joe is a lax reviewer and Bob is a strict reviewer, and since you're tired of working on this feature, you give it to Joe so that it will go out sooner with less hassle. Big problem.

Furthermore, imagine that Sarah pushes a PR to a feature that was previously built by Mike, but she selects Joe and Henry as reviewers. Even though Mike worked heavily on this feature in the past and is probably the expert on it, it is entirely possible with this system that the feature could make it into production without Mike even being aware of it.

----

Those are the two strategies I've worked with. It's probably clear which one I prefer. That said, Strategy 2 has a lot to recommend to it. If your team is small enough, it's probably a good idea. For larger teams, I recommend either Strategy 1 (gatekeeper) or mixing the two (gatekeeper + 1-2 other approvals).