Peer Code Review | Phase 1: Is the Pull Request Reviewable?

erinvh620
Mar 3
6 min read

Updated: Mar 4

Intended Audience: software developers

TL;DR When approaching a code review, determine whether the pull request is reviewable before diving into the actual code.

The Value Equation of Code Review

Like any process, code review should deliver more value than it costs. The effort spent on code reviews should yield clear benefits such as catching defects, saving time, reducing costs, maintaining or improving user satisfaction, and maintaining or improving developer experience. Each organization or project will have its own unique value equation for code review, and defining what that looks like is essential. If the costs outweigh the benefits, the process should be adjusted—or abandoned.

To that end, the first step in code review is ensuring we don’t waste time. Before diving into a pull request (PR), ask: Is it reviewable? This simple question takes seconds to answer, but skipping it can lead to massive inefficiencies—namely, developers slogging through unreasonably large PRs that should have been split up before the review began.

By making “Is it reviewable?” the first question we ask, we save time, improve the effectiveness of code review, and, critically, preserve developer morale. No one should be stuck reviewing an impossibly large PR that was never realistically a one-person job.

Assessing Reviewability

The first step in a code review is not to dive into the code but to determine whether the PR is reviewable.

For me, reviewability is primarily about size. (Sloppy code can also feel unreviewable, but ideally, your team uses a linter/formatter, so formatting issues shouldn’t make it to code review.) If a PR is too large, send it back to the author to break into smaller, more manageable PRs. This isn't about nitpicking—it’s about ensuring an effective review process.

The best proxy for PR size is the number of lines changed, which includes both additions and deletions. Most repository management tools (GitHub, GitLab, Bitbucket) display this number automatically, making it easy to assess reviewability at a glance.

Example: In the above screenshot, the PR size is 136 additions and two deletions, which equals 138 lines changed.

So, what qualifies as too large? A good rule of thumb is a maximum of 500 lines changed—but often, even smaller PRs can be challenging to review if the changes are complex. Four hundred lines or fewer is ideal. Five hundred is the absolute cutoff.

Before rejecting a large PR outright, check whether some changes, such as generated code or user-facing string translations, don’t require review. (Instead of reviewing the generated code itself, focus on the process that produced it. Since string translations typically don’t need developer review, they can often be skipped.) If excluding these brings the PR down to a reasonable size, it may still be reviewable.

Taking just a few minutes to determine whether a PR is reviewable prevents wasted time on unreasonably large PRs. Once a PR is broken down into smaller, more focused PRs, each can be reviewed efficiently and thoroughly.

If a PR isn’t reviewable, don’t pretend otherwise—send it back. Your time is best spent where it matters most: catching defects, improving code quality, and making meaningful contributions.

Sending a PR Back

Many developers don’t feel empowered to send a PR back and say, “This is too large. It needs to be broken into smaller PRs.” I want to change that. Pushing back on oversized PRs is one of the fastest ways to improve code quality, developer experience, and team efficiency.

Rejecting a PR doesn’t have to be awkward. It’s not a personal critique—it’s an objective, team-wide standard (arguably, an industry-wide one!). There’s no need to gather courage; it should be as routine as running tests before merging code.

The Problem With Large PRs

The bigger the PR, the more likely we are to experience review exhaustion—where a PR is so large that we start skimming instead of reading. The result?

We miss critical details.
Feedback becomes inconsistent.
Poor-quality code slips through.

If we want code reviews to catch issues, they need to be manageable. Catching problems in review is cheaper than fixing them in production, both in time and cost. Some mistakes, like a bad database schema change, can’t be truly fixed once they go live; they must be worked around instead.

By enforcing reviewable PR sizes, we catch more issues before shipping and reduce costly rework later.

Setting a Reviewability Standard

One way to remove subjectivity from deciding whether to send a PR back is for your team to agree on a lines-changed cutoff (e.g., 400-500 lines max). This makes it easier to enforce without feeling like you’re creating conflict. Some teams even build this rule into CI or linters, though I find that hard limits can sometimes be more frustrating than helpful.

That said, trust your instincts. If a PR feels overwhelming to review, send it back—regardless of the line count. A 300-line PR full of complex logic may be harder to review than a 600-line PR of simple renames.

How to Phrase a PR Rejection

If you’re unsure how to phrase it, here are some professional, direct ways to request a smaller PR:

“This PR is too large to review effectively. Could you split it into smaller, self-contained PRs?”
“This is a lot to review in one go—can we break it into multiple PRs for better focus?”
“To keep review quality high, let’s split this up into smaller parts.”

If breaking it into separate PRs isn’t feasible, ensure the commit structure allows for an independent review of each commit.

Takeaway

Many developers hesitate to send PRs back because they don’t want to create extra work for the PR author. However, the extra effort up front saves the entire team time. A well-structured PR gets faster, more useful feedback, leading to cleaner, more maintainable code.

Rejecting an oversized PR isn’t about being difficult. It’s about making code reviews efficient, effective, and worth everyone’s time.

If you’re unsure whether a 500-line max is the right rule for you, consider tracking your own review efficiency for 6-8 weeks. A simple spreadsheet with PR size, review duration, and the number of breaks you take can help you identify the LOC threshold where review fatigue sets in. Over time, this data can help you develop a personalized heuristic for reviewable PR sizes.

Exceptions: When Large PRs Are Unavoidable

While most large PRs should be split into smaller, independent changes, there are exceptions—cases where a PR can’t be meaningfully broken down. When this happens, the key is not to blindly accept the PR’s size but to structure it so that it remains reviewable despite the high line count.

Here are a few common situations where a large PR may be unavoidable:

Updating a widely used dependency: If a dependency is used pervasively, every affected method may need to be updated simultaneously.
Renaming a commonly used variable: A change like renaming user to loggedInUser might touch hundreds of files but remains easy to review if structured properly.
Removing a deprecated feature: When removing something like guest user functionality, the cleanup may need to happen in multiple phases.
Applying a new linter rule: Adding a formatting rule to your linter can change thousands of lines, but the change is often mechanical in nature.

Large PRs should still be structured for easy review, even in these cases. At a minimum:

Break the change into logical, self-contained commits.
Keep the PR focused—no unrelated refactoring or cleanups.
Allow multiple reviewers to divide the work if needed.

I’ll cover the above scenarios in detail in an upcoming post.

Conclusion: Reviewability is About Cognitive Load

At this point, we still haven’t looked at a single line of code. That’s intentional. This phase exists to prevent wasted effort and ensure we aren’t spending time reviewing PRs that are too large to review well. If a PR isn’t reviewable, we don’t pretend otherwise—we send it back so that it can be structured in a way that makes the review effective.

Spending just a few minutes on this step makes the entire review process more efficient. It allows us to focus on our efforts where they matter most: catching defects, improving code quality, and making meaningful contributions to the codebase.

At first glance, it might seem like PR size is just about line count—but actually, it’s about cognitive load. The more mental effort a PR requires to process, the harder it is to review effectively. Number of lines is a useful first proxy, but when a PR must be large, we reduce cognitive load in other ways:

Structuring the PR for easy review, commit by commit
Ensuring different parts of the PR can be reviewed independently by different people

Ultimately, code review isn’t just about finding bugs—it’s about making the process as frictionless as possible. This ties into a concept I’ve written about previously: setting up your reviewer for success. The goal is always to make code reviews easier, faster, and more effective—and that starts with ensuring the PR is reviewable.

Your Thoughts Matter

Did I miss anything important? I’d love to hear your thoughts! Feedback is incredibly valuable to me, and I promise—your ideas will always be credited, never taken. My goal isn’t personal gain; it’s to improve the developer experience for all of us. I hope these blog posts spark valuable discussions we can all learn from.

Leave a comment below, or if you’re shy, message me directly—I’d love to chat!