You need to sign in or sign up before continuing.
Reflection — An Honest Take 8 min

Honest Take — Before You Begin

Honest Take — Module 4: Code Review as Conversation #

Code review is the only writing form where you see your impact on a real person fast. You leave a comment; you get a reply within thirty minutes; you can tell instantly whether it landed well or badly. Every other genre in this curriculum has a long delay between transmission and feedback. That tight loop is both the gift and the curse. The gift is calibration: you can practice written critique hundreds of times a year and watch what happens in near-real time — no other text genre offers that. The curse is risk-aversion: the same loop that lets you calibrate also lets you feel every review that lands badly, and most engineers, after a few uncomfortable exchanges, develop a defensive crouch. Vague comments. Everything softened to mush. The substantive disagreements quietly skipped. The review becomes performative — look how engaged I am — while the actual work of surfacing what needs to change gets dropped. The fix is not to overcome the discomfort but to re-read it: if a review feels slightly uncomfortable to write, you're probably doing it right. The comfortable reviews are usually the useless ones.

Both earlier drafts of this curriculum arrived at the same central practice independently, which is worth noticing: ask before assert. Most review comments are stated as conclusions — "this is wrong, change it to X." The same observation stated as a question — "what made you choose this approach over X?" — gets a different outcome in the large majority of cases: sometimes the author had a reason you didn't see, sometimes they discover their own gap, sometimes you both find a third option. It feels slower. It is faster, because the trust it builds makes every future review faster too. Five reviews of disciplined ask-before-assert will change the temperature of a team's review culture more than any process document. Add severity tags so the author can tell your blocking concerns from your musings, and you've made the two highest-leverage changes available in this module.

A note on the AI angle, because it's reshaping this genre in real time. You review code that is partially AI-generated now, whether anyone says so or not, and AI-shaped code has a specific failure profile: it passes plausible line-level review while containing design choices the author never actually made. The reviewer's question "what's the reason for X here?" is more diagnostic than it was a few years ago — if the answer is "the tool suggested it," you've surfaced something useful, not caught someone cheating. Don't moralize about AI use in reviews; "did you actually write this?" lands as accusation and is unfalsifiable anyway. Just review the code, slightly slower, with the alternatives question doing the work.

If you're the maintainer archetype, one specific pattern: maintainers tend to be rigorous in the internal-team style — high standards, lots of feedback — and under-warm with first-time contributors, because they're applying team norms to strangers who need more warmth. The second-time contributor has a relationship with you; the first-timer has only this thread. The fix costs five seconds: a one-line welcome on first contributions from new accounts before the technical feedback starts. Materially different first experience; measurably different contributor retention.

And on receiving: most engineers' weakness in review is giving — too soft, too sparse. If you're a senior engineer with a strong written voice, yours may be the inverse. The giveaway is hearing yourself draft the rebuttal in your head before you've finished reading the comment. If that's recognizable — and statistically, it is — the ten-minute cool-down before responding to critical comments isn't optional for you. It's the work. The symmetric failure also exists: senior engineers chronically under-push-back on reviews they receive, accepting changes they disagree with to avoid the thread. Pushing back well is a skill, and the only way to develop it is to do it.

Know the conversion rule, because text has a failure ceiling: after two rounds of disagreement on the same thread, convert to synchronous. Not because either of you is wrong, but because written critique strips warmth, both parties read the missing warmth as coldness, and threads spiral on tone while agreeing on substance. A five-minute call resolves what fifteen more comments would inflame — then post the resolution back to the thread so the record survives. The mature reviewer isn't the one who never needs the call; it's the one who notices round two ending and makes the call before round three starts.

Conclusion #

Code review is the highest-frequency, fastest-feedback writing form in your week — the practice arena for every harder conversation later in this curriculum. Two things to internalize: ask before assert, with severity tags, in every review you give; and the ten-minute cool-down before responding to critical comments you receive. Everything else — the AI calibration, the first-timer warmth, the sync-conversion rule — is texture on those two.

Predictions #

  • Ask-before-assert will feel slow for the first five reviews. Around the sixth or seventh, you'll notice response times dropping and defensiveness disappearing from the threads. That's trust compounding; it was never actually slower.
  • You will recognize the defensive-drafting instinct in yourself within the first week of practicing the cool-down. The recognition is most of the fix — once you can name the feeling, you can choose against it.
  • Within a month, an author will reply "thanks, this was genuinely helpful" to a review you wrote differently than you would have a month before. Save that review; it's a calibration artifact.
  • In the same month, one PR thread will escalate faster than it should — text strips warmth, both parties miss it, the thread spirals. You'll convert it to a five-minute call, the call will resolve it, and you'll wonder why you didn't convert two comments earlier. Next time you will.
  • You will under-push-back on reviews you receive. Track it for a month: fewer than two or three pushbacks in thirty days of received reviews means you're absorbing disagreements you should be voicing.
  • If you maintain a public project, the CONTRIBUTING.md audit will be the most leveraged thirty minutes in the checkpoint — three small additions that change the shape of every future contribution. Small fix, long tail.