> We (at least should) also do code reviews in order to make sure everyone understands the code. This is the most common reason I see cited for code reviews, b

> We (at least should) also do code reviews in order to make sure everyone understands the code. This is the most common reason I see cited for code reviews, but I'm not entirely sure if I buy it, at least not for a lot of teams. In most cases you are going to have one, maybe two other people looking at a given PR. The positive way of looking at this is that you've just doubled (in some cases tripled) the number of people who are familiar with the code. In reality though, this is still going to be a very small fraction of most engineering organizations. If you have a small team who wholly owns a small codebase then it could be meaningful, but a lot of the time you're still talking about a rounding error from zero people knowing the code- most people in the organization will still be touching the code in the future without any prior knowledge of it, and will have to start understanding it from zero. Even if you are dealing with a small enough code base, in a small enough team, that the reviewer is adding a substantial margin of familiarity with the codebase to the team, reviewing the code is only going to give an extremely shallow level of understanding. The reviewer isn't going to have all of the context that the original developer had. They won't know all of the things that weren't done or why, the tradeoffs that were made, requirements, business context, etc. Best case scenario, someone wrote that down in a well-known place (comments in the code near the feature, something relevant in a docs directory, hopefully not as an archived jira issue that will never be looked at again). The reviewer probably has their own work to do anyway, and once they approve the PR they'll flush most of what they had out of their short-term memory anyway. In a lot of ways, this is the same set of reasons that people aren't very likely to find bugs in a code review either. Someone without a lot of context on the problem isn't likely to find many business logic errors, or missed requirements. Since you were busy working on your feature, you probably don't know who else on what other teams might have been doing something relevant to your work, so you wouldn't know to get a review from people who might have something useful to contribute (and they wouldn't know to proactively review your code). One of the reason senior engineering roles often devolve into telling people to talk to one another is to try to address this kind of situation, but that only scales up to a small fraction of the overall code churn at organizations of any size. For what it's worth, I ask for PRs, and I review my co-workers code. I make comment when I see something that might be useful, and I graciously accept feedback and try to make sensible decisions about when to make changes and when to let the feedback go. I actively search for PRs that might touch sections of the code I've been working in or am very familiar with to try to optimize the quality of the feedback I can give. I'm not really convinced any of this actually helps deliver better code in the moment, but maybe it does some good as a way to help teach my co-workers about things (or to learn about things they can teach me), and anyway it's such an ingrained part of engineering culture that it doesn't seem worth the political capital you'd have to spend to try to change it, and even if you succeeded it would be a prime target for scapegoating if anything went wrong later. It does slow down the development process I think, but people need down time anyway. If waiting on a code review gets people an hour or two of downtime to check their email or read HN between tasks then maybe it's actually worth it for that. The burnout caused by superfluous process and the occasionally large pile-ons and people demanding poorly thought out changes, gatekeeping your ability to deliver business critical work is essentially a cost of doing business that we seem to have collectively accepted in software. I should also note that I also work on some open source projects, and in that setting PRs work much better. Not only does such code often need more review, but you also typically have a smaller group of people who know the whole codebase, and are much better central repositories of knowledge. The review process is also a much more effective way of doing collaborative decision making in an open source project IMHO.