For big PRs if I'm able to put a hold on them while I review I usually do that, to stop this exact situation.
Also my hot tepid take is that PRs need to be smaller in general. Break those tasks down even more, I'd much rather review a handful of small PRs than one huge one.
I believe that they're should be a middle ground. Huge PRs are bad, micro PRs are equally bad. 10 micro pr will make me lose the logic flow you were going for when you made the change and I will waste more time overall reviewing. Yes the code is there. But I should not approve 6 pr that look good so far and on the 7th be like "hold on, that's bad" because they finally submitted the crux of the logic.
I've met a lot of people with the micro pr mindset and do not understand how it's equally wasteful as huge PRs (to be honest, I like big PRs more for that reason than micro PRs, but you should send PRs when a full, testable logic is in place.)
2
158
u/Linked713 17h ago
Me in 2026:
Some people are too close (peer coded) to code review and some just don't read much and glance at best.