How to do your first code review without pretending to know everything

Someone added you as a reviewer, and your first instinct is probably that they made a mistake: you barely know this codebase, and the author has been here for years. This guide to how to do your first code review starts from a different premise. You were asked because your read matters, not because anyone expects you to know everything, and the habits you build in the first few reviews decide whether review becomes a skill or a performance.

You were asked because your read matters

The author has been staring at this change for hours or days, and they physically cannot see it fresh anymore. You can. That is the asset a new reviewer brings, and it does not require seniority. If the change does not make sense to you, that is data about the code, not about you: code that confuses a careful reader today will confuse the on-call engineer at 3am next year. Your job is not to certify perfection. It is to report, accurately, what the change did to one attentive reader.

How to do your first code review: start small

Do not make your debut on the 900-line feature branch. Pick small PRs deliberately, because size is the strongest predictor of whether a review is real: a 40-line bug fix you understand end to end teaches you more than an 800-line diff you skim. There is a social bonus, too. Lou Franco’s writeup on getting reviewed faster observes that small PRs get picked up quickly because reviewers grab them as mini-breaks between tasks. Be that reviewer. Small, prompt reviews make you the teammate whose name people are glad to see in the reviewer box, and they build your calibration one digestible change at a time.

Read the description before the diff

Know what the change claims to do before you check whether it does it. The description, the linked ticket, and the test names tell you the intent; the diff only tells you the implementation, and you cannot judge an implementation against an intent you never read. If the description is empty, that is legitimately your first comment, not an obstacle to route around. And if you can run the change locally, do: five minutes of clicking through the actual behavior grounds everything else you will say.

Ask questions as questions

Microsoft’s research on modern code review found that understanding the change is the top challenge reviewers face, seniors included. So “why does this need a lock?” is a contribution, not an admission: either there is a reason, which now gets written down where the next reader will find it, or there is not, and you just caught something. Ask genuine questions plainly, without dressing them up as verdicts or dressing verdicts down as questions. The author answering “why” in a thread is documentation being written in real time.

Lean on a checklist, not on nerve

You do not yet hold the team’s review standards in your head, and you do not need to. A code review checklist removes the blank-page problem: does the error path do something sensible, do the tests assert behavior rather than implementation, do the names say what things do, does anything touch data it should not. Walking a checklist beats staring at a diff waiting for insight, and after a dozen reviews the checklist moves into your head where it belongs.

Know what your approval means

Approving is not politeness; it says “I read this, and I am willing for it to merge on my word.” The empty thumbs-up that skips the reading part is review theatre, and it is the one habit that will quietly zero out your value as a reviewer. The honest alternative is scoping: “I reviewed the logic and the tests; someone else should check the infra part” is a perfectly good review, and saying it out loud is a sign of care, not weakness. Do that consistently and something compounding happens: every change you trace, every “why” you get answered, every checklist pass builds your map of the system. Reviewing teaches you a codebase faster than writing code in it does, because you see every part of it change, with the reasons attached. Your first review is the slowest one you will ever do. Your tenth will feel routine, and by then the team will have learned what your approval is worth.