A few weeks ago we - a small group at Seeq, my employer - announced the pr-reminders bot open source project.

The pr-reminders bot is the bot that we have been using to send timely reminders to our teammates about pull requests awaiting review. We have found it to be helpful across multiple teams to keep the code flowing to production. And now you can set it up for your team. See the announcement and/or the repository for more details - including how to deploy it yourself and how to contribute.

In this next installment of my series on code review (the first article was about why we do code review in the first place), we’ll be looking at how to review code effectively. There are several practices that I think make code review effective. In this article I want to focus on one particular one that – if you’re not doing it already – will dramatically increase the effectiveness of your code review. Next time, we’ll go over some other practices to make code review more effective, but before we get to any of that let’s talk about how the lightweight peer review we use today came to be.

Code review – at least the type of code review I’m talking about in this blog series – is the process of asynchronously examining and commenting on someone else’s code before it is merged into the main branch of your source control repo. It is a common practice in software development, but why do we do it? Should we do it? What are the benefits of code review?