preface

How do we deal with gigantic PRs? How do we make code reviews shorter? Why can’t we write effective code review comments? Is SSDaaRB (Single Senior Developer as a Reviewer Bottleneck) something we just have to accept? Are we doomed to debate with our colleagues over technical implementations? Will code reviews always be like this?

These questions (and plenty more) are the matters that I gravitated toward in my now 12-year career. I’ve worked on teams that had no code review process at all. I’ve worked on teams that had a process, but it was barely enforced. I’ve worked on teams that had a wonderful process. And I’ve worked on teams where the process made me want to pull my hair out because it was so tedious. As I gained knowledge in those roles, both in technologies and team processes, I couldn’t help but return to those questions. Looking back, I realized a big part of whether I enjoyed working with certain teams was whether our code review process was amicable and effective. Yes, you write code when you become a professional software developer, but you spend way more time reading and making sense of it. You also spend a lot of time reading code you didn’t write! This realization made me look at code reviews in a different light.