The pull request is done. The tests are green, the description is written, the author has moved on to the next ticket because that's what you do. And it sits.
It sits through the morning because everyone is in the middle of something. It sits through the afternoon because the reviewer had a meeting. By the time someone opens it, main has moved, there's a conflict, the author has to climb back into a change they've already forgotten, and the next ticket, which built on this one, is now stacked on a branch that isn't merged.
Nobody did anything wrong. That's what makes it hard to fix.
What a waiting pull request costs
A review of a reasonable change takes half an hour. The cost is in everything that happens while nobody does it.
- The author's context goes cold. A rename they'd have done in a minute on Tuesday takes a rereading of the whole change on Friday.
- Main moves on. Every day the branch waits, the rebase gets bigger and the chance of a merge that compiles but doesn't work gets better.
- The next ticket stacks on it. One branch waiting is a queue. Two is a dependency chain nobody asked for.
- The board lies. The ticket says done, the product says nothing yet, and the people who need the software hear "done" and ask why they can't see it.
- The reviewer's pile grows. Three pull requests take more than three times the attention of one, because the third gets skimmed.
None of these show up in a report. They show up as the team feeling slower than it is.
The rule
Open reviews come before your own ticket. You do them before you start, not when you reach a good stopping point.
In practice that's twice a day for most people: first thing in the morning and after lunch, the review tab is the first tab. If there's something waiting on you, you review it. Then you code.
Your own work can wait an hour without anyone noticing. Someone else's can't, because they're already waiting.
It felt wrong to the team at first, and it felt wrong to me. Starting the day with someone else's code instead of your own flow. The thing is, the flow you're protecting is the flow you'll lose anyway, at eleven, when the ping arrives.
What makes the rule possible
The rule only works if a review takes half an hour, and two habits keep it that way.
A description that says where to look
The description tells the reviewer what changed, why, and where to start. Which file carries the idea, which files are fallout. A reviewer who knows where to look reads a change far faster than one who opens the files alphabetically.
It also says what the author isn't sure about. That's the paragraph I read first.
Talk before the big ones
For a change that touches a lot, the author and the team talk before a line is written. What's the shape, where does it go, what's the risk. Then the review confirms what was agreed instead of discovering it. Most of the long review threads I've seen were design discussions that happened too late to be cheap.