Code Review: A New Developer’s Guide

The article explains that code review is part of the normal software workflow, with goals like finding bugs, meeting team standards, and increasing visibility across the team. It focuses on the challenge newer developers face when they must both accept critique and review others’ work.

Reading notes

#

• A good review starts with readable code, no commented-out code blocks or debugging statements, and passing unit tests tied to the changed functions.
• A useful pull request explains what changed, why it changed, and how to test it.
• Testing instructions should cover the steps to reach the correct feature state and any relevant data or examples.
• Reviewers should follow the instructions, but also do their own exploratory testing.
• When reviewing, developers should run the code, check unit tests, and ask for help if the instructions are unclear.
• Reviewers should test like a user, follow typical workflows, and look for pain points and edge cases.
• If something seems wrong, reviewers should avoid assuming intent and instead describe what they did and ask whether the result is expected.
• Personal coding preferences should be set aside when they do not affect code or client style expectations.
• In-person conversation can be better than comment threads for sorting out assumptions and bugs, with notes added afterward if needed.
• Code review is framed as team care, and feedback should be received as part of improving the work, the product, and professional growth.