2026-07-20 · 5 min read

How to practice code review (deliberately)

Nobody teaches you to review code. You pick it up on the job, one approved PR at a time, and the feedback arrives weeks later, usually as a production incident with your approval on it. That's a strange way to learn a skill this important. Here's how to train it on purpose.

The skill without a gym

Think about how you got good at writing code. You wrote thousands of small programs that didn't matter. You broke things in sandboxes. You did exercises on LeetCode or Exercism or whatever you grew up with, got told "wrong answer" in under a second, and tried again.

Now think about how you got good at reviewing code. If you're like most of us, the honest answer is: you didn't, exactly. You started doing it because your team needed you to, on real PRs where mistakes count, with no one checking your work. When you miss a bug in review, nothing tells you. The PR merges, everyone moves on, and the lesson (if it ever comes) arrives detached from the moment you'd need it to learn anything.

Reviewing has always worked like this, and it used to be tolerable, because reviewing was the side dish. It isn't anymore. AI assistants write a growing share of the code that lands in front of you, and your role in the loop is shifting from author to gatekeeper. The skill you never explicitly trained is quietly becoming the job.

What deliberate practice needs

The research on skill acquisition is boringly consistent. To improve at something, you need reps that are small enough to repeat often, feedback that arrives close to the attempt, and difficulty that stays slightly ahead of you. Sports coaches know this. Chess trainers know this. Typing tutors know this.

Apply that lens to code review and the gap is obvious:

• Reps. You review when a teammate happens to open a PR. Some weeks that's ten times, some weeks zero. You don't control the cadence.
• Feedback. There is none. A missed bug is silent. Even a caught bug doesn't tell you what else was in there.
• Difficulty. Random. A doc fix, then a 2,000-line refactor, then a config change.

So practicing deliberately means constructing what the job doesn't give you: a steady stream of small, reviewable changes where the bugs are known in advance, so someone (or something) can tell you what you caught and what you walked past.

Ways to practice, honestly compared

A few options exist, each with a real trade-off. I'd rather list them straight than pretend there's one answer.

Review open-source PRs

Pick a project you use, open its pull request queue, and review incoming PRs in your head before the maintainers do. Then read what the maintainers actually said. It's free, it's real code, and comparing your review to a maintainer's is a decent feedback proxy. The downsides: scope is unbounded (you'll spend most of the time building context, not judging code), and on quiet projects the comparison review never comes.

Mentor on Exercism

Exercism lets you review other people's solutions to small exercises as a mentor. Underrated option. The code is small, the intent is known, and writing feedback that another human has to understand is half of what makes a reviewer useful. What it won't train: spotting planted, realistic bugs. Most solutions are honest attempts, so you're reviewing for clarity more than for defects.

Work through code-review.org

Code-review.org is a free tutorial that walks through review fundamentals with exercises in Python and Fortran. Good for absolute basics and for the etiquette side (how to phrase feedback, how to receive it). It's a course though, not a practice loop. You finish it once.

Security-specific: PentesterLab

If your interest is security review specifically, PentesterLab's code review exercises hand you deliberately vulnerable code and ask you to find the hole. Narrow, but the feedback loop is real: the vulnerability is known, so you learn exactly what you missed.

Read post-mortems

Incident write-ups are review training in reverse. Each one is a bug that survived review at a competent company. Reading them builds your library of "things that slip through". Passive, but it compounds, and it's the cheapest habit on this list.

DiffDojo

This is ours, so calibrate accordingly. DiffDojo gives you one realistic AI-written PR a day. You read the requirements and the diff, leave inline comments, and give a verdict: approve or request changes. Every PR has a planted bug (or is deliberately clean, which is its own trap), so the moment you submit, you learn what you caught, what you missed, and how a canonical review would have read the same diff. It's the reps-feedback-difficulty loop packaged into about five minutes. The daily challenge is free and needs no signup.

A routine that sticks

Skill work fails when it needs willpower. Ten focused minutes daily beats a two-hour Saturday session you'll skip by week three. A shape that works:

1. One small graded rep a day (a DiffDojo PR, a PentesterLab exercise, one Exercism review). Keep it under ten minutes.
2. When you miss something, write one sentence about why you missed it. Wrong place to look? Skimmed the boring part? Trusted a name instead of reading the body? Patterns show up fast.
3. Once a week, do one real-world review slowly: an open-source PR in a project you know, with the maintainer's review as your answer key.

The single habit that matters most, on the job and in practice: before approving, say out loud what the change assumes. Assumptions are where the bugs live, especially now that so much code is written by a model that never doubts itself.

Read next: How to review AI-generated code: a guide for the human in the loop