Confessions of a programmer: I hate code review (2010)

Last year I was on a big project in a senior role and doing and receiving lots of code reviews. There's a whole etiquette around these things that you have to appreciate. First off, I got lots of feedback that was valuable.

My view with code reviews is that they should be timely and appropriate in scope. Reviewers should have some time to review but not forever. I tend to do them early in the morning or before I leave but I'm not likely to interrupt my workflow for them; unless I'm asked to do so. Real time is not a reasonable expectation. But days delay is also not reasonable. The smaller the pull request, the less time is acceptable. The bigger the change, the longer you allow for reviews.

Also, the bigger the PR, the higher the workload for reviewers. Keep your PRs small and create lots of them instead of dumping lots of big changes in one PR.

It also helps to classify review comments as blocking or not blocking. A valid outcome can be to file a follow up ticket for another change. Yes, it would be nice to refactor this bit of code but given that it was a two line code change that got the job done, maybe right now that is good enough. My view is that if CI tests pass and the code is better than before it was changed in some meaningful way, it should always be OK to merge.

Finally, sometimes there's an asymmetric relation with the reviewer and reviewee in terms of seniority. You can use this as a didactic tool to educate juniors. But it is also an opportunity to point out they did well; which I'd argue is just as important. Likewise, you have to place comments from juniors in context as well. They might feel a little intimidated commenting on your code and if they mean well, it's important to give them feedback on their comments. IMHO it is important that people speak up and feel safe to do so. A simple "You are right, I will fix this. Thanks for pointing that out." makes them feel good.

1) Automatic code formatters/linters before the code gets to review. When everybody knows there's a formatter, reviewers can spend less time looking for formatting issues. Generally, people are more inclined to take a quick look at the code then too, because they know their focusing on "just" the logic, which helps with getting a review sooner.

2) Smaller sets of changes up for review. Yes, this might mean more code reviews overall and more process, but it's way easier to catch a bug in a 3) (this one might be controversial) Early code reviews where appropriate. If you're making a change that's more likely to be totally rejected, get it into code review as soon as the basic structure and logic is in place and ask somebody to review it as quickly as possible. This is before tests are ready and every todo is completed or whatever else. The review should be quick and dirty, but at least that way you know if you should be proceeding with your current path at all or change course. Again, this means more time spent reviewing, but it's a lot better than getting a review after a week saying what you just wrote has already been done, or it totally misses goal, or it has some critical issue, or whatever. This helps a lot with what to do while you're waiting for feedback too. If you've got this type of code review up then you can keep working on the details while you're waiting on feedback. If your code review doesn't fall into this category, you're probably relatively safe to start working on the next thing, because at most you'll need to make some small changes to what you're working on, not throw it out altogether.

4) Making sure code review is considered a priority on the team. That includes the team lead prioritizing code reviews and encouraging others to prioritize code reviews. If the code doesn't get reviewed, it doesn't get shipped, so it's ultimately more important than writing new code.