"Let’s start with the perspective of the reviewer. Everyone is familiar with this scenario: you get a notification about a new PR you need to review. You open the PR and see that the title of the PR is a JIRA ticket. The description of the PR is blank. You find the JIRA ticket and read it to get some context before continuing. Going back to the PR, you see about forty commits, many of which are things like “migration” or “wtf please work” or worse. Given this you click the “Files changed” tab and see that there are 5k lines of code changed, across 30 files. Resigned to your fate, you then try to understand this large changeset all at once. Because it’s incredibly difficult to do so and because you are also under pressure to deliver your own changesets, you end up reviewing it at the surface level, leaving style feedback and perhaps some more nuanced commentary for the parts you are able to understand more easily."
"As the creator of the PR, you are hoping to merge it. But past that, you also want your teammates to let you know of things that you may not have considered, or why this particular algorithm you’ve employed may have negative effects on the backend APIs it eventually calls. Style nits are OK but avoiding an incident by pointing out an unhandled edge case is much better."
