Stage 4 · Lesson 2 of 8
Descriptions and self-review
Before you ask for review, do a . Read your own (the list of lines you changed) in the review tool as if you were the reviewer. You will catch leftover , commented-out code, typos and unrelated changes.
Then write the . Say what changed, why, how you tested it and what the reviewer should look at closely. Link the ticket, and add screenshots for anything visual.
The reviewer sees your code but not your reasoning. Later, the description becomes history for anyone who wonders why the change was made. A good description often halves review time.
Common trapan empty description and a diff full of debug code, which tells the reviewer you did not look before asking them to.
A question to check yourself, an AI practice session and 2 cheat sheet entries come when you add the roadmap to your account. Add it
Resources for this stage
Start with· follow one of these
- GuideFreeGoogle Engineering Practices
Google · Intermediate
Google's guides for change authors and reviewers: small changes, good descriptions and handling comments
- BookPaidThe Missing README: A Guide for the New Software Engineer
Chris Riccomini and Dmitriy Ryaboy (No Starch Press) · Beginner · $29.99 print, $23.99 ebook
The testing, code review, delivery and on-call chapters written for a new engineer