Intended Audience: software developers
TL;DR Early code reviews, when used thoughtfully and aided with clear communication, save time and improve team morale.
We’ve all heard the advice to “get an early code review”—feedback on our code before it’s fully polished—but how many of us actually do this? I never used to. I didn’t want to waste my time (and the reviewer’s) getting feedback on things I already knew needed fixing.
A few years back, though, something happened that changed my perspective. I’d long been in the habit of frequently pushing my code up to the remote repository, just in case something happened to my laptop. One day, a few months into a new job, a colleague approached me. He’d noticed my PR (pull request) that was open but not ready for review. He saw I was following a particular pattern. He explained that the team had since switched to a new approach, but I’d been following an “old” file that hadn’t been updated yet. His feedback saved me a ton of time and saved my eventual reviewer from the headache of telling me to re-do the whole PR.
That moment showed me the value of early feedback.
In this post, I’ll share tips on effectively giving and receiving early reviews and answer one key question: How can we take advantage of early code reviews without wasting anyone’s time?
Benefits of Early Code Review
Design issues are caught earlier
Early feedback helps catch software design (or “architecture”) flaws before investing too much time, saving the team time and effort.
Misunderstandings are caught earlier
When I worked at Trainline, our team had to implement a feature for French users. One developer misinterpreted this as users located in France rather than frequent French rail users. An early review could have clarified this sooner, saving time and effort.
Difficult feedback is easier to give and receive
When someone catches my PR heading in the wrong direction early, it’s easier for us to course-correct. The reviewer doesn’t feel guilty about suggesting a fresh start, and I find it easier to hear that feedback. This approach keeps frustration low and helps me avoid the “sunk cost fallacy.”
Overall, early code reviews don’t just improve individual PRs; they improve the developer experience. Catching issues early prevents frustrating situations—like reworking a PR from scratch after significant effort or navigating challenging feedback. It’s a win-win for both individual productivity and team morale.
When to Ask for an Early Code Review
Early code reviews are a powerful tool, but they’re not meant for every PR. Overusing them can drain resources and slow the team down. Here’s when I find early code review most effective:
When starting a new job: Early feedback helps me align with the team’s style, standards, and expectations.
When unsure about my approach: If I’m testing a new approach (e.g., my first time following VIPER architecture) or exploring a solution I’m not entirely confident in, early review saves time by catching issues before they become embedded in the PR.
When I need pairing but no one is available: An early code review can give me a fresh perspective and fill the gap that pairing typically covers.
When time is of the essence: Paradoxically, sometimes “going slow to go fast” is essential. Slowing down for early feedback means fewer surprises and roadblocks later.
Pitfalls of Early Code Review
Early code reviews offer big benefits but also bring unique challenges. Being aware of these helps me navigate the process more effectively.
Distinguishing Between In-Progress and Finalized Code
One of the main challenges in early reviews is a lack of clarity around the code’s status. The reviewer might not know which parts are a work-in-progress versus which parts are relatively finalised. As a result, the reviewer might give feedback on issues I’m already aware of or assume that unfinished code is ready for review.
Author’s Role
To keep things clear, I’ve found that explicitly marking which parts of my code are still in progress helps reviewers focus on the areas where I need feedback.
Code Comments
When implementing something “quick and dirty,” I add comments like “quick and dirty implementation - will fix later”. My in-progress code often includes reminders like:
“Choose a better name later”
“Move to viewmodel file”
“Add unit tests”
“Find a better place for this method”
Even if I don’t plan to ask for an early review, these notes are reminders for myself. But when I need early feedback, these in-line comments let reviewers know exactly what’s a placeholder versus what’s ready for a closer look.
General Notes
When a more general aspect of the code is unfinished (like adding user analytics or UI string translations), I flag it in the PR description. A ready-for-review checklist can also clarify the code’s status, though I prefer in-line comments so that information isn’t missed.
Good Habits
While handing off messy work is tempting, I avoid it whenever possible. For example, I always ensure my code is formatted correctly to keep it readable (ideally, whatever codebase I’m in has a formatter). If I’m unsure of a name, I’ll opt for an overly descriptive one rather than abbreviations or acronyms. This benefits me later, but it also makes the review process smoother.
I’ve found that these habits have benefits even when I’m not planning on asking for an early review. Explicit comments keep me organised and ensure my code is ready for feedback if needed.
Reviewer’s Role
As an early reviewer, start with the PR description. Check any ready-for-review checklist the author might have included, noting what’s been checked off.
If the code is chaotic and the author hasn’t clarified which parts are in progress, it’s best to ask. Reach out to confirm which areas they already plan to refine. You might even share this post with them as a reminder about marking in-progress areas!
In cases where communicating with the author isn’t possible, choose your review approach based on what will save the most time. You can either:
Go in-depth on all issues (even minor ones) or,
Focus on high-level concerns, knowing the code will be reviewed later.
Whichever approach you choose, convey that (and your reasoning) to the PR author.
Finally, this early stage is ideal for suggesting that large PRs be broken into smaller, manageable pieces if needed. Early feedback is a great way to help keep things concise and prevent unwieldy PRs.
Misalignment on Desired Feedback
Sometimes, I’m looking for input on specific aspects of a PR—like UI architecture, error-handling strategy, or a particular method implementation—but if I don’t communicate this, the reviewer might not know where to focus. Misalignment of feedback expectations can lead to frustration and wasted time. When requesting an early review, I try to be explicit about what feedback I’m seeking, whether it’s on a specific technical problem, a general code quality pass, or just an overview of the structure so far.
Author’s Role
To get the most out of early feedback, clearly state what areas you want input on. Think of it this way: if you don’t request early feedback on every PR, ask yourself why you’re asking for it this time. The answer will help clarify what context to give your reviewer. For example:
“Could you check the architecture here? I’d like to ensure I’m structuring it consistently with the rest of the app.”
“I’m looking for feedback on the error handling in this module.”
“Could you review the UI tests to see if I’m covering edge cases correctly?”
Reviewer’s Role
As the reviewer, confirming the author’s expectations at the outset is helpful. Ask questions like, “What kind of feedback are you looking for here?” If they rarely request early feedback, you could ask, “Is there something specific you want me to check on this one?” Clarifying these expectations upfront will help you focus on areas that matter most to the author, making the review process more productive for everyone.
Early Code Review Isn’t Always the Solution
The most common complaint I hear about early code reviews is, “I wanted feedback on my overall solution, but the reviewer was only looking at minor issues like formatting.” Of course, communicating before the review can address this issue. But, before jumping into an early review, it’s worth pausing to ask: “What am I looking for feedback on?” If you’re seeking input on the overall solution, high-level architecture, or general logic flow, here are a few options that might be a better alternative to code review:
1. Solution Outline: If you’re seeking feedback on your overall solution, a short design doc or description of the solution might get you more targeted input than code. This doesn’t have to be extensive—sometimes, a single paragraph is enough.
2. Architecture or Implementation Plan: For input on architecture, try sharing a high-level plan like a flow diagram or a list of interfaces you intend to create. List the main components and their roles before coding. This structure serves as a quick reference for feedback and ensures you’re not missing anything fundamental.
3. Object Graphs or Pseudocode: Sometimes sketching out an object graph, pseudocode, or just the interfaces and class structure is a great way to gain early insight without the overhead of actual code review.
After this reflection, if you’re primarily interested in feedback on code rather than ideas or plans, go ahead with an early code review. A few minutes spent clarifying what you need can help you choose the best way forward.
Making Early Code Reviews Work For Everyone
Early code reviews can make a real difference—not only in catching design issues and misunderstandings early but also in keeping code quality high and improving team morale. For me, the key to making early feedback effective is clarity and communication. Being upfront about the PR’s status and what kind of feedback I’m looking for saves time and effort.
What about you? Do you request early code reviews? If not, what’s holding you back? If you do, have they been helpful? Let’s keep the conversation going!
Comments