As a developer, I was sometimes frustrated how long it took to get my code reviewed. Our workflow at the time was to request a review from a specific developer or let the round robin assignment pick one.
What I noticed though, is that other devs are usually not immediately free to pick up your code review. Meetings, lunch, deep into work, it goes on. But since they're the one assigned to the review, your PR is just going to sit there until that person can take a look.
The switch up I introduced (and built this app for) is to instead have more of a "pull" philosophy with reviews. Instead of one person being the bottleneck, the PR is shared with the broader team and the first available dev can pick it up. We started doing this manually just in Slack, but it really worked well for us! PR review time was quickly halved and it soon caught on in the rest of the org. So I build a basic slack app that helped streamline this. Over the years, I've automated it more and more and added other features that helped speed up our review workflow. We now target an average time to first review of one hour and we're pretty good at achieving that most of the time.
Recently, I've put some effort into making it available for others to try too. I've had some people ask me about using this at their workplace so it's now publicly accessible for anyone to install. So I thought I'd share here too to see if others could find it helpful as well and have more ideas for it.
I totally agree, waiting a long time for PR reviews can be so frustrating! This used to be a pain at my company too, but we've been able to dramatically improve the review time. We target getting a review, on average, within one hour of posting a pull request. Most weeks we now achieve that (or get very close)!
I think it comes down to two main pieces: culture & tooling.
Culture:
- Reviews are part of the job. A solid senior developer isn't just writing code all day -- there are many aspects to the job and reviews are an important one
- Reviews shouldn’t be viewed negatively or as something we "have to do." They’re opportunities to learn, teach, collaborate, and improve as a team
- Make small, well scoped PRs. Do not try to roll a bunch of changes into one PR. It makes it harder to review, riskier to merge and harder to rollback.
- Reviews should be owned by the team. Often there doesn't have to be just one developer who can do a review. If a PR is waiting on a developer who has a morning full of meetings or is fixing a high priority bug, then another team member should pick up the review
- Prioritize code ready for review over code still being written. Code in review represents significant business effort (customer feedback, planning, design, development), but its value isn’t realized until it’s merged. Prioritizing reviews can help deliver that value faster
- It’s awesome as an author to get a quick review, so "treat others as you’d like to be treated."
- (Likely not feasible everywhere, but helpful for us) Skip reviews for trivial changes like copy updates, test fixes, or non-critical dependency upgrades
Tooling:
- Automate as much as possible. Linting, tests, and other automated checks can reduce manual review effort
- Make sure there's a process for everyone getting notifications quickly. Turned out some devs would use github notifications and only checked those like once a day, while others got real-time slack alerts (guess which group tends to complete reviews faster)
- Have a way to set & track your review time target as a team, try to make an automated way to keep the team accountable & aware of where they're at
Obviously some of these things aren't easy to change and take time. I'm fortunate enough to be a TL so I was able to influence my team and the engineering department more directly, but I think a respected developer can bring forward this kind of change too. To also address some of these points for our department, I built a Slack <> GitHub app to help our team move reviews faster. Feel free to try it if you're interested: https://pullpro.dev
I’ve been working on making it accessible outside our org and would love to hear any feedback if you give it a go!
Lumen5 | Senior Frontend Engineer | Vancouver, CAN or Remote | https://lumen5.com
Recognized as one of Canada’s fastest-growing companies, Lumen5 is an online video creation platform powered by machine learning and designed for businesses, brands, and creatives.
The product that we are building is filled with interesting complexity. That includes working in areas like natural language processing, computer vision, machine learning, web scaling (frontend, backend, infrastructure, and monitoring), video rendering, OOP architecture, and more. There's also lots of opportunity for creativity; after all, video is such a creative medium!
Lumen5 compensates engineers at the 90th percentile of comparable organizations. Engineers are also expected to perform at 90th percentile levels - so your teammates will be highly effective and highly proficient.
What I noticed though, is that other devs are usually not immediately free to pick up your code review. Meetings, lunch, deep into work, it goes on. But since they're the one assigned to the review, your PR is just going to sit there until that person can take a look.
The switch up I introduced (and built this app for) is to instead have more of a "pull" philosophy with reviews. Instead of one person being the bottleneck, the PR is shared with the broader team and the first available dev can pick it up. We started doing this manually just in Slack, but it really worked well for us! PR review time was quickly halved and it soon caught on in the rest of the org. So I build a basic slack app that helped streamline this. Over the years, I've automated it more and more and added other features that helped speed up our review workflow. We now target an average time to first review of one hour and we're pretty good at achieving that most of the time.
Recently, I've put some effort into making it available for others to try too. I've had some people ask me about using this at their workplace so it's now publicly accessible for anyone to install. So I thought I'd share here too to see if others could find it helpful as well and have more ideas for it.
I'd love to hear your thoughts!