Peer Code Review | I’ve Submitted My Code For Review, Now What?

Intended Audience: software developers, software development team leads

TL;DR After I submit a PR for review, it remains my top priority until it's fully integrated into the codebase. I stay responsive to feedback, prepared to make changes, and I follow through on any related responsibilities—whether merging the PR, deploying it, or monitoring for issues post-release.

It’s 3 PM. You’ve just wrapped up a PR (pull request) that’s taken the better part of three days. With a rush of adrenaline, you drop the PR’s URL into your team’s Slack channel. Your fingers tap out a quick message: Ready for review. Satisfaction swells as you hit send.

You stand up, stretching your legs after hours of deep focus. The kitchen beckons, and you take a short walk to make yourself a cup of tea. The kettle hums in the background as your thoughts turn to the horizon—the next task, the next problem to solve. You’ve been on a streak lately, hitting milestones with regularity, and you’re eager to keep the momentum going.

Mug in hand, you settle back at your desk. You open JIRA and scan the sprint board. A fresh, untouched ticket stands out; without hesitation, you assign it to yourself. The promise of a new challenge excites you, and you begin to study the ticket’s details, ready to dive in.

What’s wrong with this picture?

Developers Feel Done Prematurely

Many of us developers feel done with a PR once we submit it for review, eagerly shifting our focus to a new task. However, from my experience, this mindset is often unproductive. Submitting a PR for review is usually just the midpoint of the process. We'll likely need to address reviewer feedback, participate in discussions, and make code changes. Depending on our team's workflow, we might also be responsible for guiding the PR through the merging, deployment, or release process. And once the code is in production, we could also find ourselves monitoring bugs, crashes, and logs generated by that PR.

Why?

Several factors contribute to feeling done with a PR when we submit it for review. Here are a few reasons it’s so easy to feel done prematurely:

We Feel a Sense of Achievement

It's natural to feel a sense of achievement at this stage, especially after pouring our blood, sweat, and tears into a PR over several days. We’ve tackled complex problems, refined our code, and brought it to a point where it's ready for review. That’s a real accomplishment! But, while we’ve cleared a significant hurdle, it’s important not to mistake this milestone for the finish line. Submitting a PR for review is not the end of the task.

We've Given the Task Our All

We've given the PR our utmost effort, striving for perfection before passing it off for review. We've scoured the code for every possible improvement and come up empty-handed. At this point, there's nothing more we can do—and, more significantly, nothing more we want to do. We're mentally drained from the intense focus and effort, and the desire to be done with the task grows stronger every minute. But exhaustion, though natural, doesn’t mean the task is complete.

Getting Here Took Longer Than Expected

When the coding phase drags on longer than expected, it’s natural to feel eager to move on. Even before we started coding, there may have been extensive team discussions and planning sessions around this task. The task becomes monotonous, and after posting it for review, there’s a strong temptation to dive into a fresh task immediately. Emotional fatigue from a prolonged focus on the same code drives this desire to escape follow-up work. By now, we’re emotionally drained and ready to leave the PR behind. But again, emotional exhaustion doesn’t mean the PR is genuinely complete.

Automated Notifications Create Distance

Depending on your team's workflow and tooling, you might not need to actively monitor a PR after submitting it for review. Automated notifications can alert us when feedback arrives, allowing us to focus on a new task in the meantime. However, while convenient, this setup can foster a sense of detachment from the PR. With our attention fully absorbed by a new task, it’s easy for the PR under review to slip to the back of our mind. This distance can delay our responses, slow the review process, and create unnecessary bottlenecks. While it’s natural to shift our focus, there are strategies to stay engaged with the review process, which we’ll explore.

We Mistake Exhaustive Effort For Flawless Output

After putting significant effort into a PR, it’s easy to believe there’s no room for improvement and expect an immediate stamp of approval. This mindset is incredibly tempting with small or boilerplate PRs, where the changes might seem straightforward. However, assuming no follow-up will be needed can create a false sense of completion. Even well-thought-out PRs benefit from external perspectives, so it’s essential to remain open to feedback and stay engaged with the process.

We Use Imprecise Language

In daily standups, it’s common to hear developers say, “Yesterday, I finished ABC-556, and today I’m starting ABC-590,” when what they actually mean is, “Yesterday, I posted ABC-556 for review,” or “ABC-556 is waiting for review.” This imprecise language can unintentionally reinforce a false sense of completion. Referring to a PR as “finished” when submitted for review can make developers feel their work is done, even though follow-up is still needed. Encouraging precise communication clarifies the status of a PR and keeps developers engaged with the ongoing review process.

Team Members Role Model the "Done Mindset"

It’s easy to fall into the trap of feeling done with a PR as soon as it’s submitted for review, especially when we see teammates demonstrating this mindset. Colleagues might immediately shift their focus to new tasks after hitting “Ready for Review”, subtly signalling that their part of the process is complete. This behaviour can influence us, making it feel acceptable to mentally check out after submission—when, in reality, the PR still demands attention and follow-up.

The Hidden Costs of Prematurely Feeling Done

Feeling done with a PR once it's submitted for review isn't only a mindset; it leads to behaviour that directly affects a team's dynamics and productivity. And these behaviours have real consequences. Let's explore how a premature “done mindset" can ripple through your team and impact the workflow.

Team Conflict

I once worked with a team of iOS developers that included two remote contractors who, while skilled, neglected their PRs after submitting them for review. As the PR was no longer their top priority, their responses to feedback were slow, and they were often reluctant to make further code changes.

They often paired on tasks. By the time one of their PRs was finally approved, another of theirs was already in the queue. Guided by my principle that “work done is more valuable than work started,” I found myself reviewing their code without a chance to contribute much myself, leading to frustration with them and dissatisfaction with my job. Eventually, I raised the issue with my team lead, but by then, I had already formed the impression that the two contractors weren’t team players, making collaboration difficult.

Several problematic behaviours contributed to this situation:

The contractors’ tendency to neglect PRs under review in favour of new tickets
Lack of leadership intervention
My tendency to take on too much responsibility

At the core, though, the issue stemmed from teammates abandoning their PRs after submission, creating a cascade of productivity and morale issues.

Prolonged Review Times

Feeling done prematurely can make the review process take longer. When we feel done with a PR after submitting it for review, we move on to a new task, deprioritising the PR under review. This shift in focus can result in the PR spending much longer in the review phase than necessary, diminishing the overall effectiveness of the review process.

Shifting our attention to a new task means that reverting to the PR to respond to feedback and make changes often involves context switching, which can significantly slow us down.

Prolonged review times also exacerbate the issue of “staleness”. The longer a PR sits in review, the more it diverges from its base branch (as the base branch continues to be updated by other developers). The PR author can manage this in two ways:

Merge main into the PR or rebase the PR on top of main regularly (e.g., first thing every workday)
- Pro: The PR accurately represents what will eventually be merged into main.
- Pro: Merge conflict resolutions are reviewed by the reviewer.
- Con: The reviewer is reviewing a moving target.
- Con: Merge conflicts present opportunities for the PR author to make mistakes.

Waiting until review is done to merge or rebase:
- Pro: The PR remains stable as the reviewer assesses it.
- Con: Merge conflict resolutions are not reviewed.
- Con: There’s potential for a significant discrepancy between what gets merged into main and what the reviewer examined.
- Con: Merge conflicts present opportunities for the PR author to make mistakes.

In summary, neglecting to prioritise PRs not only prolongs review times but also exacerbates staleness and context-switching issues, ultimately impacting the team’s efficiency and effectiveness in delivering quality software.

Bottlenecks

Let’s say a developer, George, submits PR-1 for review and immediately starts working on a new ticket. As George dives deeper into this new ticket, he inadvertently prioritises it over responding to feedback on PR-1. This is an easy trap, and many of us fall into it! We hate context-switching—it kills our flow—so we tend to prioritise what is right in front of us. PR-1 is “out of sight, out of mind.”

George ignores the reviewer’s feedback on PR-1. He will get to it later. Eventually, he submits PR-2 for review. Now, George has two PRs under review.

While PR-1 introduces a new feature expected in the next release, PR-2 fixes a critical bug in the existing codebase. PR-1 has grown stale while neglected and now contains significant merge conflicts. Meanwhile, the feedback on PR-2 is waiting for George’s attention, and another developer, Jamie, cannot proceed with her task because it depends on the successful merge of PR-2.

The team now faces a dilemma: The reviews cannot be done in parallel as they both require George to respond to feedback. Which review does the team prioritise? What is more important: getting PR-1 merged before the next release or unblocking Jamie? George has created a bottleneck that could have easily been avoided.

This situation creates frustration within the team and can lead to a loss of momentum on the project. When a PR author neglects to prioritise their PR after submitting it for peer review, they may create significant bottlenecks, delaying progress for individual developers and the entire team, ultimately hampering the effective delivery of quality software.

How to Overcome the Premature "Done Mindset"

Start with More Precise Language

Consider addressing this issue in a retrospective by introducing a discussion point like, "I've noticed that, during standups, we sometimes say 'done' when we actually mean 'ready for review'. I find this confusing.” By starting a conversation about the importance of precise communication, the team can recgnise how small language shifts can lead to mindset changes.

Even better, give feedback immediately. When someone says “done”, but you think they mean “ready for review,” ask for clarification. For example, "Do you mean that VLT-556 was merged yesterday or just submitted for review?" Prompting for clarification encourages more accurate communication.

Encourage teammates to hold each other accountable for using precise language—it’s a small habit that can have a big impact.

Take Time to Recharge

After submitting a PR for review, it’s the perfect opportunity to take a mental break and refresh. Spending hours—or even days—immersed in our code can lead to “tunnel vision,” limiting our ability to see potential issues or critically evaluate our work.

Stepping back is essential. Whether it’s going for a walk, grabbing lunch, running an errand, or making a cup of tea, engage in something that fully disconnects you from the code. Resist the urge to think about work; the goal is to let your brain recover and reset. By taking this time, you’ll return with a clearer mind and renewed energy, better prepared to address any feedback that comes your way.

This downtime is key for pivoting from “I’ve done my best, there’s nothing to improve” to “Let’s see what I’ve missed.” It’s natural to feel emotionally spent after putting so much effort into our work. But giving ourselves space to recharge helps us approach feedback with openness and a readiness to improve.

As part of this process, it’s worth considering what Dr. David Rock and his colleagues call the Healthy Mind Platter, a set of activities that contribute to optimal brain function. Physical movement, social connection, or relaxation during this break can help us reset mentally, ensuring we’re fully refreshed when feedback arrives.

Small PRs

One way to combat the premature feeling of being done is to embrace smaller PRs. By breaking your work into bite-sized pieces, you can lessen the emotional fatigue that often arises from working on the same task for too long. You are less likely to feel prematurely done when submitting a PR that you only worked on for a day or two rather than something you’ve poured blood, sweat, and tears into for the last week or more.

When a PR drags on, it’s common to feel drained and eager to move on. Small PRs typically require less time to develop, and the turnaround for feedback is usually faster. With quicker feedback, you remain engaged in the review process rather than absorbed in a new task while waiting for responses. This approach keeps the momentum going and helps prevent the excessive staleness that can occur when you linger too long on the same code.

Advocate for PRs

It can be tempting for developers to move directly to a new task after submitting a PR, but maintaining a healthy review process requires prioritising work already in progress. When PRs are addressed promptly, the whole team benefits from a smoother workflow.

If you notice a teammate marking a PR “ready for review” and immediately diving into a new task, a gentle nudge can help keep reviews on track. For example, you could say, “Hey George, I saw you marked PR-1 ‘ready for review’—great work! If any PRs are waiting for review, it might be a good time to knock those out so we can keep everyone’s work moving.” You don’t have to be a team lead to do this—it’s about advocating for the work in progress and keeping momentum.

In cases where a direct suggestion might feel like overstepping, you can make it more collaborative by tying the request to your PR. For example, “Hey, I saw you just wrapped up STR-674 and are starting on a new ticket—would you mind giving my PR a review before diving into new work?” This frames the request as a way to move existing work forward rather than halt progress on something new.

Advocating for PRs, particularly your own, helps keep the focus on completing work that is already in progress and ensures that reviews don’t fall behind. It’s about teamwork and encouraging good habits without stepping on anyone’s toes.

For team leads, there’s an added responsibility to step in when developers incorrectly prioritise new tasks over PRs waiting for review. Part of your role is guiding the team toward the most effective use of time and resources. By establishing a culture where reviewing PRs is a priority, you can ensure no critical review is left unattended while team members chase the next task.

Avoid Starting New Work

Over the years, I’ve developed a list of tasks to focus on after submitting a PR for review and before starting work on a new ticket. The goal is to avoid having multiple PRs in flight simultaneously because, as we’ve discussed, this can quickly get messy. I aim to keep my attention where it’s most effective—addressing PR feedback and avoiding distractions that could monopolise my focus.

Once I submit a PR for review, my top priority is responding to feedback as soon as it arrives. But during the waiting period, I don’t want to sit idle. Here’s what I typically do:

1. Take a break. I step away from my computer and do something to recharge, as we discussed above.

2. Review my PR again. Even though I reviewed it before submitting, I always find something new after posting a PR for review. Somehow, the code takes on a different light when I know someone else is about to read it.

3. Make sure the team knows my PR is ready for review. Depending on our process, this might mean pinging the reviewer directly or updating the team.

4. Catch up on emails and chat. I use this time to respond to outstanding messages.

5. Organise my environment. I like to keep my workspace clean and organised because it helps me focus. I might do things like:

Organise the files on my computer desktop
Delete downloads that I no longer need
Clean out my Git stashes
Delete old Git branches

6. Review other PRs. I check the list of PRs awaiting review and pick the highest-priority one to tackle. Before I dive in, I usually check with my team lead to ensure that’s the best use of my time.

7. Tackle low-hanging fruit. If I finish reviewing one PR before I get feedback on my PR, I’ll pick a second PR to review. However, I will make sure that the second PR is low-priority or very small in order to avoid creating bottlenecks. Another developer can easily take over the lower-priority review if necessary.

8. Contribute in other productive ways. If there are no PRs to review, I’ll focus on team progress with tasks like:

Pair programming with someone.
Preparing a presentation for an upcoming team tech session.
Preparing for an upcoming refinement session by reviewing and organising tasks.

Only after exhausting everything on this list will I start a new ticket. And even then, my original PR remains my highest priority. The moment I receive feedback, I’ll switch back to address it before continuing with new work.

As you can see from this list, I try to lean towards tasks that are easy to abandon. For me, this means tasks that are low priority, or that someone else can easily take over.

While it’s always better not to start a new ticket while waiting for feedback, sometimes it’s unavoidable. The key is to remember that the original PR must remain the top priority, and switching back as soon as feedback arrives is essential for keeping the team on track.

This is the personal approach I’ve developed over time. If you create your own system for managing this balance, communicate it clearly to your team lead. They need to understand the rationale behind your actions and have the context to guide your efforts. Transparency is key; it ensures your team lead can provide feedback if they prefer a different approach.

Create a Team Approach

As illustrated in my earlier anecdote, when I was the only member of my team prioritising code review, things didn’t go well. I found myself doing all the reviews and not writing any code, which is far from an ideal team dynamic. A team functions much better when its members agree upon a shared approach. In this case, the approach is to continue prioritising your current PR, even while it is in review—prioritising work done over work started. When everyone is on the same page, code reviews can naturally be distributed more evenly across the team.

So, how can you foster this approach? Team leads can establish this policy and encourage team members to adopt it. Consider facilitating a collaborative exercise where the team comes up with a list of tasks to complete before starting a new PR, similar to the list I’ve developed for myself (shown above). This can help create a shared understanding of expectations and responsibilities.

Addressing team members who do not participate in code reviews is crucial, as this behaviour negatively impacts everyone. To prevent such dynamics, ensure your organisation has clear expectations for code review participation. These expectations should be communicated regularly and reflected in performance reviews and promotion decisions. Team leads should coach team members who neglect their code review responsibilities, as failing to intervene can hurt the entire team and lead to dissatisfaction, turnover, bottlenecks, and, ultimately, low-quality software.

Additionally, it’s vital to recognise and celebrate the contributions of those who actively engage in code reviews. Recognition from higher-ups can motivate team members and reinforce the importance of a collaborative code review culture. This ties into Adam Grant’s concept of “givers and “takers,” where encouraging a giving culture can enhance teamwork and project success. (Watch Grant’s Ted Talk here.)

Conclusion

The importance of staying engaged with a PR after submitting it for review cannot be overstated.

Developers often fall into the trap of feeling done with a PR when they hand it off for review. This mindset has hidden costs that affect the team’s productivity and morale. It can lead to bottlenecks, unnecessarily long review times, and an uneven distribution of work among the team—all of which, in the long run, negatively affect team morale.

Being aware of these pitfalls and proactively taking steps to avoid them can foster a healthier team environment and a more collaborative culture. The importance of staying engaged with a PR, whether through intentional language to clarify expectations, mindful breaks to refresh your perspective, or having a plan in place to mitigate these risks in advance, cannot be overstated.

Remember, the process doesn’t end when you submit a PR for review! This is just the beginning of a valuable dialogue that can lead to better quality code, healthier team dynamics, and a more pleasant and productive work environment.