Code Reviews by Phase and Expectations

Code reviews are amazing for many reasons. And everyone on the team should contribute. Interestingly, the behavior of an engineer with respect to code reviews changes based on seniority or tenure within a team or code repository. I like to refer these changes as “phases”.

This document attempts to describe the expectations of each phase and help provide guidance on maximizing code reviews on your team.

Phases

Learning Phase

• Participates in code reviews to learn (even on day 1)
• Asks questions in person or via comments
• Learning to look for best practices established by team
• May only look for limited things based on their own personal checklist (like correctness)
• Not confident yet to approve a diff

Enforcement Phase

• Consistently reviews code and continues to learn
• Knows enough to confidently approve
• Understands that code reviews are also documentation
• Enforces best practices established by team
• May look for many things based on personal checklist or learned checklist
• Should be pairing with those in learning phase to accelerate making enforcers

Leadership Phase

• Consistently reviews code even when someone else already approved
• Understands reviewing code has higher leverage and long-term impact than writing code
• Confidently approves code and keeps pushing bar higher
• Defines best practices for code quality
• Defines and shares checklists / learnings with team
• Fosters a positive code review culture that inspires craftsmanship
• Pairs with those in enforcement phase to accelerate making leaders

Thought Leadership Phase

• Improves code review process beyond team
• Introduces new best practices throughout company
• Brings in improved tools
• Publishes learnings externally (ie Maslow’s Pyramid of Code Review, Stacked Diffs, Keeping Diffs Small)

Code reviews are great and can be the single biggest thing you can do to improve your code.