Your next PR can wait. Your teammates' PRs can't.
There are mornings when I open the editor with a very clear idea: I want to move forward with my task. I have the context fresh in my head, I know which screen I need to touch, which bug I want to close, or which part of the feature I need to finish. And right before I start, I check Slack, GitHub, or the review channel and see two or three pull requests waiting.
My first instinct is usually to keep going with my own work.
Not because I do not want to help. Simply because writing code feels like progress. It is visible. At the end of the day you can say: I moved this feature forward, I opened this PR, I closed this task. Reviewing a PR is different. It feels like an interruption, something you do between blocks of work, almost as if it were a secondary task.
With every passing day, I am more convinced that this intuition is dangerous.
A PR waiting for review is paused work
An open pull request is not finished work. It is paused work.
The code may be written, the tests may pass, and the description may be clear, but while nobody reviews it, that piece still has not entered the product. And, in many cases, the person who opened it is not completely unblocked.
Sometimes they are waiting for feedback before continuing with the next part. Sometimes they need that PR to be merged so they can stop working on top of a branch that changes every day. Sometimes they have real doubts about a technical decision and need another person to look at the context.
From the outside it looks like one more PR in the list. For the person who opened it, it may be the exact point where their work got stuck.
And here is the problem: if I ignore that PR and open another one, maybe my individual feeling of productivity goes up, but the system gets a little more blocked.
Opening another PR does not always help the team
For a long time, I associated productivity with creating new work. If I moved my task forward, good. If I opened a PR, better. If I had several things in parallel, even better.
But a team does not deliver software based on the number of open branches. It delivers software when work is reviewed, integrated, tested, and shipped to production.
If there are already five PRs waiting for review and I open the sixth, I have added more work to the flow, but I have not necessarily helped the team deliver sooner. I may have done the opposite: increase the queue.
Today, this matters even more.
With the intensive use of AI, the pace at which we can generate code has increased a lot. It is easier to explore a solution, build a first version, refactor part of the system, or open a PR with changes that would have taken much longer before. That has very positive sides, but it also changes the bottleneck.
If the limit used to be writing the code, now it may be reviewing it well. AI can help us produce faster, but it does not remove the responsibility of understanding what we are putting into the product. Quite the opposite: if the volume of PRs goes up, the quality and speed of reviews matter even more.
Because generating changes is one thing. Integrating them with judgment is something very different.
You see this a lot in teams where everyone is busy, but things take too long to close. There are many active branches, many almost-finished tasks, many PRs “waiting for review”. The board looks full of progress, but the product does not move at the same pace.
That is where reviewing stops being a favor and starts being a team responsibility.
Reviewing is also engineering work
A good review is not skimming the code and approving it just to get it out of the way. It is also not looking for tiny details to prove that you read the code.
Reviewing well is technical work.
It is checking that the solution fits the problem. That the code can be understood. That we are not adding unnecessary technical debt. That the tests cover the new code. That there are no obvious edge cases. That the person who wrote the PR has not been left alone making a decision that affects everyone else.
It is also a way to share context. Many times I have understood a part of the product better by reviewing someone else’s PR than by reading documentation. And I have also spotted decisions I would have made just as badly if I had been working on that task.
That has value. Even if it does not generate a new branch with my name on it.
The cost of arriving late
The worst part of a slow review is not only that the merge is delayed. It is that context is lost.
If you review a PR ten minutes after someone opens it, the conversation is alive. The person remembers why they made each decision. They can answer quickly. If something needs to change, the mental cost is small.
If you review it three days later, everything is heavier. The branch may be outdated. The person has already moved to another task. The feedback arrives late. A comment that would have been useful at the beginning now forces someone to reopen context, redo parts of the work, or negotiate with the calendar.
The same technical comment can be cheap or expensive depending on when it arrives.
That is why I think review time matters more than we usually admit. Not as a metric to pressure people, but as a signal of team health. If PRs are constantly left waiting, something in the flow is broken.
What I try to do now
I do not always manage it, but I try to follow a simple rule: before starting a long block of work, I check if there are PRs waiting for review.
If there is a small PR I can review in ten or fifteen minutes, I review it. If there is a PR blocking someone, I give it priority. If I cannot review it because I do not have context or I am deep into something urgent, I say it. A “I cannot get to this until tomorrow” helps more than silence.
I also try not to use my own workload as an automatic excuse. We all have work. That is exactly why we need the flow not to get stuck. Today I review your PR. Tomorrow you review mine. Not as an exchange of favors, but because the team needs to close work, not accumulate it.
There is an important difference between being busy and helping the team move forward.
A practical criterion
When I have doubts, I ask myself a very simple question:
What unblocks the team more right now: one more hour on my task, or reviewing this PR?
Sometimes the answer will be to continue with my task. If there is a critical delivery, if the PR is not urgent, or if I am really not the right person to review it, it makes sense to prioritize my work.
But many times the answer is to review.
Because a thirty-minute review can unblock several hours of someone else’s work. Because it can prevent a branch from going stale. Because it can close a technical conversation before it becomes a problem. Because it can help the team ship today something that would otherwise be waiting until tomorrow.
This is not about stopping your work to do someone else’s. It is about understanding that, in a team, unblocking is also progress.
And sometimes, the best way to move forward is not to open another PR.
It is to review the one that is already waiting.