I'll say which side I'm on right away, so nobody wastes their time: mandatory code review makes teams that were already good better, and it slows down teams that use it as a substitute for trust. Most small teams are in the second group without knowing it. I started seeing this clearly in 2019, on a project with five of us. After a deploy broke the checkout for an entire Friday afternoon, someone decided that from Monday on, nothing would be merged into `main` without two approvals. Branch protection got configured on GitHub, the rule sat there shining, and we all felt that strange relief you get when you solve a people problem with a checkbox. The mistake, by the way, was of a kind no reviewer would have caught. A migration that ran fine in staging, where the table had 800 rows, and locked the production table for about 4.2 minutes. Nobody reads a migration looking for that. You read the syntax, you see the SQL is clean, you click Approve. That's the first hidden cost, and the one that irritates me most: review creates a feeling of safety that doesn't match real safety. The author relaxes because "someone will look at it." The reviewer approves because "the author knows what they did." Two people, each delegating attention to the other, and the net result is less total attention in the system than when one person was afraid of failing alone. I've seen 1,400-line pull requests get an "LGTM" in eleven minutes. It isn't laziness, it's math. Nobody can hold 1,400 lines in their head, everybody knows it, and the ritual still gets performed. Then there's latency. We rarely talk about it because it sounds like the complaint of an impatient person, but the wait for a review is probably the biggest invisible tax on a small team. I measured it once, in my own workflow, over six weeks, out of curiosity and stubbornness: the median time between opening the PR and getting a first response was around 7 hours, and that was on a team where everyone was online at the same time. What happens during those 7 hours? The author doesn't sit idle, of course not. They pick up another task. By the time the comment arrives, their head is somewhere else, they have to rebuild the context, and a comment that was a two-minute question turns into forty minutes of context switching. Multiply that by roughly three PRs a week per person and the cost stops being small. (A parenthesis that serves nobody: I remember a colleague who always answered every PR at 9:02, with an almost religious punctuality, and I ended up using him as a clock. If he hadn't answered yet, it wasn't nine yet. Anyway.) But I don't want to sound like someone who thinks review is useless, because I don't. What I think is that most of the value of review isn't where people think it is. Catching bugs is its least reliable benefit. The studies people cite, and honestly I no longer remember which was the original source, suggest that review catches a modest fraction of defects, and my experience matches that. What review does well is spread knowledge. When Rui opened the PR that touched the billing module and I, who had never been in there, was forced to read it, I found out the module existed, how it was organized and where the traps were. That was worth more than any comment I left. The problem is that this spreading function only works if the reviewer reads for real, and real reading only happens when there's time, interest and context. Mandatory kills two of those three. Because obligation changes the nature of the act. A requested review is a conversation: "look, I'm not sure about this part, take a look." An imposed review is bureaucracy with a collaborative face. And bureaucracy, as we all know, gets optimized. People learn to write small, harmless PRs so they pass quickly, to split risky changes into pieces that look trivial, to ask for review from the colleague they know approves without asking questions. Some people have a pet reviewer. I had one myself, and I'm not proud of it. There's a third-order effect that almost nobody mentions and that only shows up after a year or more. Teams with rigid mandatory review tend to stop doing big refactors. An honest refactor touches thirty files, and nobody wants to be the reviewer of thirty files or the author who'll spend three days answering comments about variable names. So it doesn't get done. Technical debt piles up, the system rots slowly, and the process that was supposed to protect the quality of the codebase ends up protecting it only from the more ambitious improvements. I've watched it happen. One service had a 2,300-line class that everyone knew should be split, and it survived intact for three years because the review of the split was going to be hell. Now, the contradiction I promised myself I wouldn't hide: despite all this, I wouldn't abolish mandatory review on a team of twenty. On a team of five, where everyone knows each other and covers for each other, probably yes. The difference is the scale of trust. With twenty people, some of whom you don't know, some who joined two weeks ago, review becomes an onboarding mechanism and a minimum control that justifies its cost. What I can't stand is the same rule copied from a company of a hundred engineers into a project of three, just because "that's how it's done." That's cargo cult. What works, in my experience, is far less glamorous than any playbook: PRs that are small, almost ridiculously small, under 200 lines when possible. Automated tests doing the boring work (formatting, linting, type-checking) so humans don't burn energy on commas. And one simple cultural norm: whoever opens the PR says explicitly where they have doubts. Half the quality of a review comes from the author saying "this part doesn't convince me." When the author hides the weak spot, the reviewer rarely finds it. And then there's the code that doesn't need anyone looking at it. A typo fix, a dependency update with green tests, a text change on a static page. Demanding two approvals for that is theater. I once waited two days for an approval on a comma in a README. Two days. I'll come back to something left hanging earlier, the Friday the checkout broke. For years I told that story as the reason we adopted mandatory review, and only recently did I notice that what would really have prevented the problem was a migration test against an anonymized copy of production data. We never did it. We made the two-approvals rule, which was easier to configure and gave the feeling of action. That's what stays with me: the process you adopt is often the one that fits in a checkbox, not the one that solves the problem. So, does it slow you down or make you better? It depends on whether you're using it to learn and share or to feel protected. In the first case it improves things. In the second it's just one more place where responsibility gets diluted until nobody has it.