The Art of the Pull Request — Ben Lomax

Keep PRs small (ideally a few hundred lines) to encourage thorough reviews and avoid reviewer burnout

Create atomic commits that do only one thing - separate refactoring from functional changes

Break large features into independent chunks by mapping dependencies and identifying what can be done in parallel

Review your own PR before asking others to review it - this helps catch obvious mistakes and ensures readability

Provide proper context in the right places:

• Business requirements in PR description
• Implementation details in code comments
• Change rationale in commit messages

Write clear commit messages explaining why changes were made, not just what changed

Don’t mix multiple features or tickets in the same PR - keep each focused on one problem

Structure commits to show the perfect path - rewrite history if needed to make changes clear and logical

Put refactoring changes before functional changes to improve code readability first

Consider PRs as teaching opportunities - they enable knowledge sharing and help team members level up their skills

Optimize for the reviewer’s experience - make PRs easy to read and understand since reviewers are humans with limited time and mental energy