Member-only story
10 Popular Code Review Practices That Are Actually Toxic
If your reviews feel slow and painful, a few of these are probably the reason
Code reviews are supposed to make our code better. A lot of the time, they just make it slower.
Most of the bad code I’ve seen in production was reviewed. Some of it was reviewed by me.
The reviewers weren’t lazy. We were doing what the team told us to do. Two approvals, a careful pass on style, every comment resolved before merge.
Non-medium members click here to read for free.
Those rules feel safe. Some of them just make reviews drag, and the real bugs get through anyway.
To be fair, none of these are bad ideas everywhere. They go wrong when they turn into a rule for every single PR, no matter how risky it is.
Here are 10 I keep running into.
1. Stop Requiring Two Approvals on Every PR
Two approvals sound safer than one. I believed that for a long time.
Then I watched a payments bug go out with two approvals on it. When we asked the reviewers about it later, they both said the same thing. They thought the other one had looked at the…
