How long does it take you and your team to get a pull request reviewed, accepted, and merged? How long should it take?

In my experience, the turnaround time a pull request takes to get through code review ranged from minutes to days. I’ve even had PRs sit for weeks waiting for code review. There are a few fundamentals I’ve learned that can help you get your code reviewed quickly and improve your pull request turnaround time.

Start with clean code

Writing code that’s readable and easy to understand speeds up the code review turnaround time of your pull requests. Your reviewer and future contributors should be able to understand what your code is doing just by reading it. In addition to well-written docstrings (where applicable), make a conscious effort to ensure your variable and function names are self-descriptive and try to limit methods to performing only one function.

Readable code is helpful beyond the code review process. In most codebases, the majority of the time someone reads code is by you and your coworkers to debug and refactor long after it was added.

Have you ever started a review on what looked like a massive pull request to discover it included a bunch of files that should have been in the .gitignore? Keeping the .gitignore up-to-date is an easy, but often skipped way to make your pull requests easier to digest for your reviewer.

To get ideas of what to include, check out GitHub’s repo of .gitignore templates.

Just because your whole team knows that they don’t need to review the generated files or dependences, there’s no reason they should be tracked and submitted with pull requests. A quick update to a few lines can reduce bloat on every pull request for every contributor to the repo.

Limit the change size of your pull request

The most common culprit of lengthy code review turnaround times are pull requests with an immense set of changes – be it in actual lines of change or complexity. Pull requests created with the intention of introducing a few simple changes can suddenly grow out of proportion with several significant changes that are difficult to review.

Even when I’m watching for it in a pull request, I’ll end up combining a feature, a few code refactors, and a bug fix or two that could have easily been split up into several more manageable sized pull requests. Teams with strong code review cultures encourage these smaller, more tactical, pull requests instead of large changesets. Sometimes this requires additional work, but your team’s overall productivity (and sanity) will thank you.

However, tread carefully. This is an art that takes careful thought and practice. While it helps to break apart changes, excessively splintering your codebase into hard-to-follow fragments is no better.

While there is no number of perfect lines of code change for a pull request, I suggest thinking about how many lines and how much complexity you are including when you’re working on a branch. Consider the person reviewing the code and the language of the change.

Depending on the complexity of the code, and the situation, 300+ lines of code change might be large or small.

For new projects or startups, they tend to have substantial pull requests since getting a feature out is a higher priority than stability. Unfortunately, when this happens, and the project starts supporting paying customers, these teams end up spending much of their engineering time fixing bugs and refactoring code.

It’s far more expensive to fix bugs in production than it is to catch them during a stringent code review process backed by smaller pull requests.

Build a code review culture

An essential component to efficient code review comes from a team’s culture and its respect for code review and code quality. Building and maintaining this culture is no small undertaking.

You can’t build code review culture by commandments carved in stone (or a wiki) for all to follow. Small nudges and course corrections in the right direction at every stage of software development build culture. The importance of code review needs to be set by and demonstrated by the engineering manager and other leaders on the team.

Code review is a place for objective collaboration and encouragement, not judgment. It’s vital that your team’s sentiment towards code review is positive.

Developers should look forward to pull requests as an opportunity to learn, not dread them as an obligation to be vulnerable to an assault on their development skills. You can help this by making a habit of calling attention to well-written code in pull requests and if unproductive judgment sneaks its way in, make a point to address it quickly.

It takes consideration and time during development to achieve the type of maintainable codebase that comes from quality code reviews. To get quality feedback from code review, you should start with planning. Time for code review should be a consistent item of consideration for every sprint planning.

If you don’t account for code review time in planning, engineers tend to focus on shipping their features first and reviewing their peer’s code second. This lack of focus on other features causes a delay in their teammates getting the useful feedback they need to iterate on from code review and slows the whole team down.

While accounting for code review in sprint planning leaves less room for additional features, a cleaner codebase with fewer bugs pays dividends in future productivity. All feature release stakeholders, including non-technical product and project managers, should consider and support code review.