I have mixed feelings about code reviews.
On one hand, they can help with spotting mistakes and improving design. Another perspective can improve code, I totally get that.
On another hand, code reviews are disruptive roadblocks in my (and everybody else’s) workflow.
Here’s a common scenario:
I make a change to solve a problem (let’s call it A), create a pull request, wait for the build pipeline to succeed, and ask for a review.
Then I have to wait for the review, so I switch context to do some other task (let’s call it B).
The reviewer probably wasn’t just sitting there doing nothing; they also get disrupted by the review and need to switch context from whatever they were doing. Not great.
While I just focused on the problem B, I got pinged by the reviewer that he approved A. But something else just got merged into master and I have to rebase and solve some conflicts. So I need to switch completely from B back to A. Again, not great.
I solve the conflicts, wait for the pipeline, switch back to B while the pipeline runs, then ping the reviewer, then work on B again while waiting for the review, then I get pinged, and finally I merge A. Ooff.
So now I can switch for good to the task B. I realize that I have to rebase after A got merged, and have some more conflicts to solve. Finally, I create a pull request… and the whole cycle repeats.
Of course, often there are more roadblocks: some major changes are requested by the reviewer; then the reviewer is not accessible, so you need to chase somebody else, and they have their own opinions about what you should change; the flaky pipeline makes you re-trigger it half the time, adding more context switching.
It’s horrible. From what I see in most teams, people get used to this kind of flow and no longer realize how disruptive it is.
But I can’t. I just can’t stop imagining how much more could be done with more efficient process.
What are the alternatives?