How Long Does (Should) Code Review Take?
I recently ran polls across my social media accounts, asking people what their typical wait time for code review is.
(The polls can be found on Mastodon, LinkedIn, and X.)
I had a total of ten respondents, so fair warning that this is a very small sample size, and you can’t draw any general conclusions from it. Regardless, here they are…
The results
10 votes total
answer | votes |
---|---|
0-4 hours | 1 |
4-24 hours | 7 |
24 hours - 2 days | 2 |
3+ days | 0 |
The takeaways
In lieu of general conclusions, I think this could be a good opportunity to start a conversation with the different groups represented here.
Announcing the Core of Nudgsicle: pr-reminders
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.
Is Your Code Review Effective?
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.
Why Do Code Review at All?
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?