Your PRs Are Someone Else's Problem

I was staring at a PR the other day. It had been open for six days. The author had rebased it twice, resolved a merge conflict, and was about to need a re-approval because the conflict touched reviewed code. Six days. For a change that would take maybe twenty minutes to review.

We’ve all been there. And if you haven’t been on the waiting side, I promise you’ve been on the other side — the reviewer who meant to get to it tomorrow and then tomorrow turned into Thursday.

Here’s the thing. We already have code review requirements. You know what they are. If you don’t, check Code Review. And most agree. This is a good thing.

Why This Matters More Now

In the age of AI and LLMs writing code, reviews matter more than they ever have. LLMs are literally engines designed to produce plausible-looking output. Plausible-looking. Not correct. Not safe. Plausible. The errors hide in plain sight because the code reads well even when it reasons poorly. Your review might be the only thing standing between a subtle bug and production.

Yes, reviews have an inherent delay. You need another human to look at your code and stamp it before it lands. That delay is a feature, not a bug. It’s load-bearing.

But when that delay stretches from hours to days? Now we have a different problem.

What Happens When Reviews Stall

PRs that sit open for a week aren’t just an inconvenience. They’re compounding debt. Every day that PR is open, the author is rebasing, re-resolving, re-requesting. They’re context-switching back to a change they finished thinking about days ago. Their stack is blocked. Their momentum is gone.

And here’s the part nobody says out loud: when your teammate’s PR sits in your queue for three days, you’re telling them something about how much you value their work. You might not mean to. But that’s the message that lands.

Reading Code Is Your Job

As a software engineer, your job involves reading code just as much as it involves writing code. Maybe more. And as part of a team, your job includes collaborating with your coworkers on shared projects — like, say, shipping software.

If you’re a blocking reviewer, that review isn’t a favor. It’s an obligation. One you owe your team.

This Is a Culture Problem

This is not a new policy. Policies are what you deploy when culture fails. What I actually want is for folks to internalize this message.

Code reviews are among the most important things we do as Software Engineers. They’re part of our job. They aren’t optional to our success. ¹

And that means we need to shift how we think about them. Not “I’ll get to it when I have time.” More like “this is the time.”

Finish your reviews. Your teammates are waiting.