I'm trying to figure out how much time our senior developers should realistically spend on code reviews. It feels like they're spending about half their time just reviewing pull requests, and it's causing a lot of frustration. The seniors feel like they aren't doing any actual coding, juniors are often left waiting days for feedback, and leadership is questioning why everything takes so long. We have 8 seniors and around 20 mid and junior engineers, and the seniors are tagged on almost every review since they know the systems best. I know code review is crucial and seniors need to be involved, but is it reasonable for them to spend 20 hours a week on reviews? Or should it be more like 10 hours? I'm also curious about strategies to reduce the review time without sacrificing quality since we've tried limiting seniors to certain areas and ended up with more knowledge silos.
5 Answers
As developers climb the seniority ladder, it's natural for their coding time to decrease. Think of juniors as your coding partners. Instead of having just a couple of hands coding for you, you now potentially have several, so utilize that!
One way to cut down on the review time is by incorporating pair programming and enhancing your automatic test coverage. If your team has a lot of tech debt and fewer tests, that’ll lead to more lengthy reviews. It really varies based on the context, so rather than aiming for a specific number of hours, focus on improving the overall process.
You should really analyze why reviews are dragging on. A lot of that can stem from the process itself. Just keep asking the question: why are reviews taking so long? Identifying that might help you implement effective changes.
Just approve PRs without overthinking sometimes! I do it all the time. We haven't had any major issues, but it does tend to create an overload of PRs to manage later. I get that the quality might fluctuate, but sometimes you just need to keep moving.
You need to look at the testing process instead of just the reviews. Automate tests to catch issues before they hit the review stage. Encourage devs to submit smaller updates too, because massive changes tend to slow everything down. Also, make sure seniors aren’t reviewing every little change—maybe adjust who reviews based on the stage of the process. And if the ratio of seniors to juniors is off, consider adding more seniors to the team!
Exactly! It’s all about understanding the root cause.