Without code review, my flow is: a) do the work b) test it locally until i'm happy with it c) check it in d) changelog the change e) push the change f) check logs g) if it works, great; if it doesn't work, consider rolling back, or rolling forward -- either way, go back to a for the code changes to fix the fix
With code review, it becomes: a) do the work b) test it locally until i'm happy with it c) push it to the code review tool d) wait a while to see if anybody sees it e) ping somebody, because everyone else is doing work, or eating lunch or whatever f) wait for them to actually review it g) if they approved it great; if i have to address things, that's great too, but I have to go back to step a h) check it in i) changelog the change j) push the change k) check logs l) if it works, great; if it doesn't work, consider rolling back, or rolling forward
I hate waiting around, and I hate interrupting people, and I hate switching tasks. I want to do my work, and get it pushed out there. Mandatory review for every change means I have to wait around or interrupt people. While I'm waiting, I need to be doing something else productive, but I also need to be watching for a notification that my code was reviewed so I can go push it and see if it works (or address any comments), and switch tasks again. Meanwhile, I have to be prepared to be interrupted to review other people's changes, or I'm blocking them from getting their work finished.
In a world where pushing takes a long time, reviewing everything is more acceptable. When you're pushing to an app store, it's not really possible to have multiple releases in a single day or fast feedback loops, so it makes sense to get more eyes on every change.
Once an author completes a patch, the next stage is to ask for a review. This is not considered an interruption or an annoyance, but a part of the role of being a software engineer on our team (on both sides of the equation.) If the fix is a small fix, then this exchange and an ACK from the reviewer can take less than 5 minutes via slack and a github PR. Modulo things which are extremely urgent, it's normal for an author to bake in an expected ~24 hours turnaround on small/moderately sized patches out of a courtesy for the reviewer. In general, we consider making changes to the application to be a team effort, and as such, having a "buddy" on every change you make isn't an interruption or an annoyance, it is an important part of being a member of the team and working together.
Working within this approach, it's important to break work into digestible PRs (to make it easier to review quickly) and to pipeline other tasks. If code review acts as a lock on your entire body of work, and you literally have nothing to do while a single patch is in-flight, it probably means something else needs to be addressed, not the code review process. At the very least, while your code is being reviewed, most likely there are other bits of other team members' code for you to review anyway :)
For example, if you need to push code to have enough confidence in it to surface it for review, that is a problem to fix. If you have no other tasks to work on while your code is being reviewed by a peer, that is a problem to be fixed. If your teammates consider it an interruption and an annoyance when you ask for peer review, or you are annoyed by having to wait for them to give you honest and thoughtful feedback, that is a problem to be fixed.
I can empathize with the idea that having to pipeline and multitask your work may not be something you are used to, but if you accept the premise that code review is a necessary step in the software development process, this is the norm not the exception. Also code review is just one of many reasons why in practice it's pretty much certain, in my experience, that pipelining work will result in more throughput as a software engineer. (Other examples include similar things which require time to 'bake', like running A/B tests, rolling out software upgrades, and so on. If I had to stop working on everything until a single A/B test converged, I'd have most of the week off :)) Also, pipelining work does not necessarily mean you are rapidly jumping from task to task, which is damaging to creative work, but it means you expend concerted effort in chunks of a few hours at a time and keep moving concrete pieces of work through the pipeline.
Ok, so here's the trade-off. You can do all these things, if you're willing to pipeline your tasks, and pay the context switching costs. It's much simpler to not pipeline when possible, and not context switch.
I do have plenty of things to do, I just prefer to finish one, when possible, before I start another. I don't like keeping track of several different pending patches, and I really don't like having to do the tedious merging that happens when multiple things are in flight around the same places at the same time.
By all means, run your team with 100% reviews; but please accept that not reviewing everything is a valid option for other teams. Just like some people will run screaming from an interview when they hear there are no code reviews, some will run screaming when they hear everything is reviewed.
The sort of people the most eager to do code reviews are developers with "every detail my way or the highway" unable to convince others they are right if they dont have ability to block commit. That and insecure people covering fear by aggressiveness. When I was in team with bad code reviews, review of a small patch could end in hours long arguments over variable name. Which of the two synonyms is better?
The thing is, code reviewing is supervisory function as any other. It is very easy to screw it up and especially people on the spectrum are likely to screw it up despite being good programmers when working alone. The usual "if you disagree with reviewer you have huge ego and cant take criticism" paradigma people push when talking about code reviews makes things only worst.
Of course code reviews can be done in good way too, but many of them are not and people have bad experiences with that.
In other words, if your team is full of people like the above, any software engineering practices are going to come with a huge "YMMV" sign, code reviews being just one of them.
The only category of changes that I'm willing to accept that may not benefit from code review are small, trivial, low risk changes. (If you think large patches would not benefit from a review process, that's a deeper question but it something if feel 100% to be the case.) But, lucky for us, it turns out that small, trivial, low risk changes are also extremely fast to review. (Like, less than 5 minutes often.) And, haha, sometimes these 'trivial' changes turn out to be not so trivial once a second set of eyes lands on it!
The idea that "developers can take responsibility for their changes" is a tautology: if engineers knew up front that a review was unnecessary, then they would know what to expect in the review. But by definition, the point of review is to catch issues and get feedback that are inaccessible to the author. Therefore, it's impossible for an engineer to self-assess if a change requires review: it would mean they could predict the outcome of a review as well.
The amount of time a review takes wrt to velocity is a self-regulating function, in my experience. If you are dragged on by a review, it probably means the code warranted review. If the review is rapid, then the review was probably less necessary. But it was fast to do anyway, so doesn't meaningfully impact velocity.
Situations like critical bugs and fixes actually are even more important to review, even if they are small patches, because in a incident response situation people are more likely to cut corners, skip steps, or make mistakes due to stress.
So what exactly is the point of skipping code review, given that regardless of patch size, there are clear benefits? The benefits are large enough that I consider the burden of proof to be on those who suggest code review be an optional step for deploying changes.
The one exception I will raise are externally enforced deadlines, where review is not possible in time due to mitigating factors affecting the reviewer. (For example, the reviewer is a domain expert but is out sick, and the software has a necessary delivery date.) But even in these cases, the review should happen in-full post-deployment, and it should be acknowledged that this is a risk-laden move. And often these are showing secondary flaws in the process (why do we have only one domain expert who could review this? why didn't we have more time allocated for review? etc)
In practice, I think a lot of aversion to reviews originate from the frustration of thinking you are finished with a piece of work but having those expectations have to shift after review raises criticism. Everyone wants to ship, especially when they themselves have checked the box that 'it works and I made it as correct as I know how to do.' Addressing reviewer feedback is fundamentally one where you have to draw upon the higher goal of improving code quality and improving your own skills, and like most things that cause real improvements, it can hurt. Honestly, I don't think anyone is free of guilt of feeling this way at one time or another.
Beyond that, other fundamental problems can lead to an aversion to code review, such as reviewers missing the forest for the trees, causing reviews to devolve into pedantry, reviewees misjudging the value of others' feedback, mistrust between team members wrt their feedback being valuable, external pressures due to misaligned expectations about delivery, etc. Counterintuitively, strong aversion to code review, an engineering task, can sometimes stem from all kinds of messy, complex problems with team dynamics. So keep in mind that if people are continually complaining about code reviews, this might be telling you something much deeper going on!
I think in general a solid code review from a peer you trust is one of these things that generally speaking, hurts in the way pushing yourself in exercise does. I personally feel it fosters a kind of skill growth you cannot get otherwise, except perhaps through deliberate practice. In other words, no pain, no gain.