After 2 years of reviewing code in a fast-paced startup, I have developed a set of rules that I apply to every pull request. These rules have saved us countless hours and prevented many production incidents.
Rule 1: The PR Should Be Small
A pull request should not exceed 400 lines. Large PRs are impossible to review properly. If a feature requires 1,000 lines, break it into multiple PRs.
Rule 2: The Author Writes the Context
Every PR should include a description explaining what the change does and why it is needed. The reviewer should not have to guess.
Rule 3: Review for Design, Not Just Style
Style issues should be caught by linters. The reviewer’s job is to catch design flaws, security issues, and performance problems.
Rule 4: Be Kind, Be Specific
“I don’t like this” is useless feedback. Say instead: “This method is doing three things. Could we split it into smaller methods?”
Rule 5: The Reviewer is Not the Gatekeeper
Code review is a collaboration, not a test. The goal is to ship good code, not to find faults.
Rule 6: Automated Checks Come First
Never review code that fails CI. Tests must pass, linting must pass, and security scans must pass before human review begins.
Rule 7: Respond Within 24 Hours
Blocking reviews slow down the team. Reviewers should respond within 24 hours. If you cannot, assign a backup reviewer.
The Result
PR cycle time: 3 days → 6 hours
Production bugs: decreased by 40%
Team morale: significantly improved