Your accountability is to ship code to customers. You aren’t finished with that bug fix as soon as you publish your PR. You are the one who is accountable to ensure the code gets merged, that it passes any deployment gates, and any other step that might exist until the customer is using it. It may be that you have a great team culture where all PRs get reviewed and merged promptly. If that’s true, I’d love to talk and learn from you. In my experience it often takes work to make sure someone reviews your PR. This might mean reminding people, up to and including booking time on their calendar.
You’ve got to be tenacious and realize that a PR waiting for approval in GitHub or AzDO isn’t delivering any value to anyone.
I said above that getting your PR reviewed might require booking time on someone’s calendar. If this happens to you, embrace it! Since asynchronous code reviews have gotten popular, I’ve noticed that reviews often fall into one of two categories: they are either fairly trivial, and done with only the context shown by the tool, or they are extremely expensive as the reviewer spends time to pull down the branch, build it, explore dependencies, possibly debug the code and so on. But I’ve got a secret – the person that submitted the PR probably already has the code locally. They can probably debug in seconds instead of minutes. Also, you can very quickly ask questions like “Hey, did you consider this case, what happens?” instead of either trying that case yourself, or posting the question and then not being able to finish the review until you get an answer.
Don’t underestimate how much the preparation of the PR author, and the high bandwidth communication available can reduce the burden of performing reviews.
I don’t know about other companies, but at Microsoft part of our performance management system asks people to consider how they contribute to others’ success. Often we feel like we’re too busy with our own work to be able to do time consuming PRs, but I’ve got a secret for you. Doing PRs is a very real way that you contribute to other people’s success. They literally can’t ship their code without a review, and if you are an expert you can also use the time to help them learn about the codebase. Even if you’re not an expert in that part of the codebase, there may be things that you have been burned by that you watch out for in code reviews, and discussing that can help them avoid repeating your mistakes.
Finally, one issue that I’ve seen on teams is that reviews are always blocked on “the experts”. Sometimes that’s the right thing, but sometimes it just slows things down, and acts as a gatekeeping function. A principle that I like to consider is to think about consequences and reversibility. Many non-experts don’t feel comfortable signing off on PRs because they are worried they are going to miss a bug. I’ve got a secret for them: I’ve been ‘the expert’ on a lot of teams, and still missed plenty of bugs during code reviews. However, we tend to have multiple safeguards in place like additional pre-deployment gates, safe deployment to smaller regions, previews, A/B testing, etc. Code reviews are just one part of a defense in depth strategy around bug prevention and detection, and it’s expected that some bugs will get through. That’s usually ok, and it will be caught by a later stage. Even in the worst case, where it isn’t, it’s typically not difficult to reverse, git has a handy “revert” command for just such occasions.
Now, there are exceptions to this, where you really do want to have experts sign off on a review because the consequences could be severe. Security fixes that must be rapidly deployed are one example here. I’m sure you can think of others. So, I’m not saying anyone should be able to sign off on any PR any time, but I do think in many teams there is an overabundance of caution that ultimately ends up slowing down the team’s productivity. Oh, and on this topic – consider doing synchronous group reviews for cases like this. That way others can learn what the expert is looking for and can get better at doing their own reviews and one day become the expert.