One Diff, One Thesis - What Every Code Review Should Be Like

Here's the full masterclass session on code review, which is where this clip was taken from.

Core points:

• Every commit and pull request (PR) you put out should have a singular focus. Don't just dump your entire feature into 1 massive 2,500 line PR; it's extremely difficult to review and you are robbing yourself of real technical feedback.
• A good average range for a PR is 50-250 lines of code. If it's substantially higher than 250, there's a good chance your PR is simply too big.
• Breaking up your pull requests will take more time initially (10-15 minutes), but it's completely worth it as it saves you time in the long-term. Smaller, more focused PRs get better feedback and are merged in faster.
• Having this habit alongside all the other good code review behaviors (linked below) is one of the most straightforward way to get a stellar performance review as an earlier-in-career engineer. Conversely, not following these guidelines is one of the easiest ways to have bad performance as a software engineer.

Related resources:

• What A Test Plan Is And Why Every Code Review Needs One
• The Most Common Mistake Made When Authoring Code Reviews - This covers how to attach great context to your pull requests.
• "How can I write great code faster?"
• Avoid These Junior Engineer Mistakes With Code Review