Keeping Code Reviews From Dragging | Sandor Dargo's Blog<br>Sandor Dargo's Blog<br>On C++, software development and books

HOME TAGS ARCHIVES BOOKS SPEAKING DAILY C++ WORKSHOPS HI... SUBSCRIBE

Blog 2026 06 03 Keeping Code Reviews From Dragging Post<br>Cancel

Keeping Code Reviews From Dragging<br>Sandor Dargo Jun 3 2026-06-03T00:00:00+02:00<br>Jun 29 2026-06-29T22:42:14+02:00 11 min

You know the feeling. You open a pull request on Monday morning. You ping the reviewer(s). You go to lunch. You come back. Nothing. You context-switch to something else. On Wednesday, the reviewer finally leaves a comment — a single one, on a minor detail. You fix it. You wait again. By Friday, the PR is still open, the branch is conflicting with master, and you’ve forgotten half of what the agent you wrote.<br>I’ve been on both sides of that scenario, like most of us. More times than I’d like to admit…<br>When I gave my talk on code reviews at Meeting C++, one of the attendees wrote a thoughtful reaction afterwards. He agreed with most of what I said, but pointed out that I had under-served one important part: the real-world problem of reviews dragging. I had said that PRs should be reviewed promptly and shouldn’t linger for days — but I hadn’t said much about how to make that happen, especially when junior contributors, unclear guidelines, or just plain over-stretched teams turn each review into a multi-day ping-pong match. A 60-minute talk has its limit, but it’s certainly worth talking about this problem.<br>The Cost Nobody Measures<br>Slow reviews don’t just slow down delivery. They quietly tax everything around them. The author loses context. By the time the first round of feedback arrives, they’ve moved on mentally — and now they have to swap back in, find the right state of mind, and try to remember why they made the decisions they made. That swap costs more than people realize.<br>The reviewer loses context too. Coming back to a PR three days after the author wrote it means re-reading the description, reloading the change, and re-deriving the intent. The second pass through a PR is almost always shallower than the first.<br>The team loses momentum. A PR that sits open for a week eats merge conflicts, blocks dependent work, and sends a quiet signal that this is just how things are around here. The longer it stays open, the more the next PR copies its pace.<br>And then there’s the new dynamic nobody had to think about a few years ago: AI changed the supply side. Generating a PR is now cheap. Reviewing one isn’t. The team that used to produce five PRs a day is producing twelve, and external contributors send another handful on top. Yet, the review capacity hasn’t moved. If your reviews were just barely keeping up before, you’re underwater now — and the queue grows faster than you can drain it.<br>And the manager — the one watching the delivery dashboard — concludes that reviews are slowing us down — which is half true. A review queue that drags slows us down. A review queue that moves doesn’t.<br>What Actually Helps<br>I don’t think there’s a silver bullet. But there are a few patterns that I’ve seen work — across teams, across companies, across languages. None of them are revolutionary. They’re just the things that the fast teams actually do.<br>Review First, Write Second<br>This is the single biggest lever, and it’s also the hardest one to pull. The idea is simple: when you sit down to work, the first thing you do is clear your review queue. Only then do you start writing new code.<br>Most teams operate in the opposite mode. You start the day writing your own thing, and you’ll get to reviews “when you have a moment”. The problem is that the moment doesn’t come. By the time you remember the open PRs in your queue, half a day has passed and the author has already context-switched away.<br>The team that reviews first ships faster than the team that writes first.<br>It’s not intuitive, but it works. Every minute spent unblocking a teammate’s PR pays back several minutes of their productivity. And the moment a team adopts this norm, the average PR lifetime drops noticeably.<br>This only works though when the team agrees. If you’re trying to enforce it alone, while the rest of your team writes first, you’re going to burn out before the culture shifts. Start by getting buy-in. Then you do what you agreed on, you show the way. Lead devs, this is on you — your team copies what you do, not what you say.<br>Have a Playbook for When a PR Drags<br>Sometimes a PR drags despite everyone’s best intentions. Here’s the playbook I try to follow:<br>Day 1: Reviewer leaves a first pass within the working day. Even a partial review. Even just “I’m on it, will come back this afternoon” or just a 👀 emoji. The author needs to know the PR has been seen.Day 2: If the PR is still going back and forth, the author and reviewer have a 10-minute call. Written ping-pong is a smell. Two or three rounds of comments on the same thread usually means there’s a misunderstanding that comments can’t fix.Day 3: Escalate to the...