It's been open for three weeks. It touches 47 files. Everyone has seen it. Nobody has reviewed it. This is a story about that PR.
The PR was opened by someone who was trying to do the right thing. They saw a problem — a sprawling, inconsistent codebase that had grown organically over years — and they decided to fix it. They spent two weeks refactoring. They touched everything. They opened the PR with a detailed description and a list of all the changes and a note that said "happy to walk anyone through this."
Nobody walked through it.
The problem with the massive PR is not that it's bad. It's that it's too much. Reviewing 47 files of changes requires a kind of sustained attention that most engineers can't give to someone else's work in the middle of their own sprint. The cognitive load is real. You open the PR, you see the diff, you close the tab. You tell yourself you'll come back to it. You don't come back to it.
The person who opened it is now in a difficult position. They can't merge it without approval. They can't close it without losing the work. They can't split it up without significant effort. They're stuck, and the PR is sitting there, getting staler every day as the main branch moves on without it.
I've been on both sides of this. I've opened the massive PR and watched it sit. I've been the reviewer who couldn't bring myself to engage with it. The dev culture around code review is full of good intentions and bad incentives. Everyone agrees that code review is important. Nobody wants to be the one who reviews the 47-file PR.
The solution, in retrospect, is always the same: don't open the 47-file PR. Break it up. Open a PR for the first piece, get it merged, open a PR for the second piece. This is slower in the short term and faster in the long term. It's also harder to do when you're in the middle of a refactor and everything is connected to everything else.
The software development principle here is about scope. The PR that's too big to review is a scope problem, not a review problem. The reviewer isn't failing. The PR is asking too much.
The maker mindset that produces good PRs is the one that thinks about the reviewer before opening. What does this person need to understand to review this? How much can I ask of their attention? The answer is usually: less than you think.
The PR is still open. I'm going to review it this week. I've been saying that for two weeks. This time I mean it.
The technical observations that stick with me are the ones about the gap between what we know we should do and what we actually do. Code review is one of those gaps. We all know it matters. We all know the massive PR is a problem. We open them anyway. We avoid reviewing them anyway. The knowledge doesn't change the behavior. That's interesting. I don't have a solution. I just think it's interesting.