What if every PR takes 2-3 days to review?

Pull requests are like bread. They go stale quickly.

Pull requests are like bread. They go stale quickly.

Yesterday I urged you to merge code changes as soon as they are safe, rather than waiting until the feature is complete.

Almost immediately I got a question in response:

What if every PR takes 2-3 days to get a review?

A good question, because it describes a common situation. So here are some suggestions:

  • Whenever slowdowns or other problems occur as a result of delayed integration, take the opportunity to draw attention to the problem, and better ways to work. Of course be polite, and as unannoying as possible. But many people have a learned blindness to the problems that delayed integration bring about. Change begins with education.
  • Work on making code review a priority. Except for emergencies, code review should be everyone’s highest priority, before writing new code.
  • Encourage the team to work in smaller batches. Going from 3-day reviews to multiple merges per day may not happen quickly. But if you can get from 3 days to 2, then later to 1, over time you’ll see meaningful improvements.
  • If you can’t convince the team, try to get a single ally. The two of you can ideally work to review each others code on a faster cadence than the others. Perhaps the others will see the benefits and follow suit in time.

I’ve helped a number of teams switch to trunk-based development, or even just smaller and more frequent pull requests. If you could use some additional help from a place of experience, reach out.

Share this