The Professor
Index Course index

Module 11 · Non-technical skills

Lesson 50 — Code review

Giving and receiving feedback without breaking the team.

Published
In this lesson
  1. Exercise 1 — The review with order
  2. Exercise 2 — The comments that teach
  3. Exercise 3 — The disagreement with data
  4. Exercise 4 — The self-review
  5. Exercise 5 — The review culture
  6. Submit

Giving and receiving the feedback. No solutions.md before submitting.

Exercise 1 — The review with order

  1. Take ONE real course PR (or from git's history: a feature's diff) and review it with §1's order: the WHAT → contract → security → correctness → tests → style. Write the comments in order and classify them (blocker/should/nit/question).
  2. The inverted review: review the SAME PR starting with style: how many style comments came out and how many impact findings escaped you? Document the comparison (the mirror exercise).
  3. The 5 DNAs: create the reviewer's checklist with TicketFlow's 5 DNA questions (layers, outbox, lock, handler, config) and apply it to the PR: did any fail? Had the "normal" review caught it?

Exercise 2 — The comments that teach

  1. Rewrite 5 toxic (or typical) comments into the grown-up format (fact+impact+path):
"This is a horrible N+1."                     → ...
"Nobody does it this way."                    → ...
"Why didn't you use X?"                       → ...
"This test proves nothing."                   → ...
"The legacy code was better."                 → ...
  1. The question as comment: hunt ONE real risk in your code (the lock? the outbox? the PII?) and write it as a QUESTION the author (you in the future) would discover alone: "what happens if two requests touch this at once?" — and answer the question yourself with the fix.
  2. The marked nit: in your next PR (or in the history), classify your observations BEFORE writing them: how many were nits dressed as blockers? The honesty of marking.

Exercise 3 — The disagreement with data

  1. The simulated disagreement: invent the review "use a repository for all models" (25 says: no) and respond with data/ADR: the author's answer holding the decision with the context. Paste it.
  2. The healthy escalation: the reviewer insists. What does the disagreement produce (a new ADR? 36's benchmark? the 30-min prototype?)? Write the disagreement-resolution plan in 4 steps.
  3. The small PR's review: split ONE big PR of yours (or simulated: 2000 lines) into 3 small PRs with their descriptions: what changes in the quality of the review you would receive?

Exercise 4 — The self-review

  1. Run the full self-review (§5's checklist) on your last course PR: how many items failed? Fix the failures and note which item broke most often (the never-done self-review? the scope without inside/outside?).
  2. The diff with a stranger's eyes: read your diff the way 47's on-call would in an incident: is the WHAT understood without asking? do the tests' names document the behavior? Rewrite what failed.
  3. The team of 1: define your "virtual review": §5's checklist + 41's linter + the pre-merge ADR. What are you missing to simulate a second pair of eyes (31's scheduled review: a 24 h wait before your own merge?)

Exercise 5 — The review culture

  1. Write the project's docs/review.md: the comments' scale, §5's checklists, §1's order, and the timing rule (review in <4 working h, re-review in <2 h). One page.
  2. The hard case: the reviewer asking to rewrite EVERYTHING ("my way") vs the working PR. Write the author's answer AND the ideal reviewer's (where is the line between repo standard and personal taste? — the answer: is it in the ADR or in the reviewer's style?).
  3. The close: your personal review rule in 3 lines (the one surviving anger and hurry) — paste it into your onboarding (48).

Submit

Paste the review with order and classification, the 5 rewritten comments, the answer to the disagreement with data and the docs/review.md. Next: Lesson 51 — Understanding the business.

^ top