American culture is often stereotyped as confrontational. In my experience, software engineers are less willing to directly correct a coworker than that stereotype would suggest.
Code review is an interesting place where this causes problems. Reviewers seem afraid to push back on a difficult request, even when a direct conversation would help both people.
Say something when you open the PR
You open a huge PR and think, “Oh my gosh. This is going to take me an hour. I have a deadline.”
You close it. Two days later, you come back and chug through it.
The author waits. You carry the stress. They never learn that the request itself was a problem.
I think the correct response is immediate:
This PR is too big for me to review effectively. You need to make it smaller and reviewable.
It’s easy for an author to unintentionally disrespect a reviewer’s time. They might be new, or they might be experienced and under pressure. If they’ve crossed an unwritten expectation, you need to tell them what that expectation is.
Establish what you need
You have deadlines too. A review request needs to account for the effort you’ll spend understanding the change.
Sometimes you need a smaller PR. Sometimes you need a walkthrough:
I understand you’re on a deadline, but this is difficult to review with the context I have. Let’s go through it together.
That gives the author something concrete to work with. They can adjust the request, and you can agree on how to get the review done.
Have that conversation when the problem appears. Waiting for a retrospective leaves you both struggling with the current request when you could already be correcting it.
Be willing to receive the correction
As an author, you shouldn’t take offense when a reviewer asks you to make their work manageable. You’re asking for their time and attention, and they’re telling you what they need to give it.
When you take on the review burden yourself, you’ll recognize the same feeling. Make room for that pushback in both directions.