Comment by mjherrma

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!