What The Optimal Discussion On Code Review Looks Like

• Code review feedback lives on a spectrum of minor to major. Here are the 2 extremes that generally shouldn't happen:
  • Minor: Syntax issues, formatting nits, commit message grammar
  • Major: Redoing the entire approach, architecture teardown, questioning whether the code review should even exist
• You want to avoid talking about minor issues as these should be caught via automation with linters.
• While major issues should definitely be called out on a code review (better late than never), these problems should have been caught prior to the code was written during the technical design and overall planning phase for the project. If you find yourself doing this, you should zoom out and question if the team has the proper processes in place to proactively write good code instead of reactively preventing it from getting merged in at the last minute.
• Some examples of good code review discussion:
  • Calling out an uncovered edge case
  • Suggesting a more descriptive name for a class or method
  • Modularizing the code by making a common interface or utility method

Related resources:

• [Masterclass] How To Do Amazing Code Review - This is the full video this clip was taken from
• "How to give better code reviews without full business context?"
• "How to review code in another language/ from another team?"