2026-07-20 · updated 2026-08-30 · 6 min read

How to practice code review (deliberately)

Nobody teaches you to review code. You get hired, somebody adds you to a repo, and within a week you're approving pull requests with your name on the approval, which is a polite way of saying your name is on whatever ships next. The feedback on whether you did a good job arrives weeks or months later, usually in the form of a production incident with your approval stamp sitting right there in the merge history for everyone to see. It's a genuinely strange way to learn a skill that's becoming more important every quarter, so here's a look at how to actually train it on purpose, outside the blast radius of your real codebase.

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 where nobody cared, you did exercises on LeetCode or Exercism or whatever platform you grew up with, got told "wrong answer" in under a second, and tried again. The feedback loop was tight, the stakes were zero, and you could fail a hundred times in an afternoon without anyone's deploy breaking.

Now think about how you got good at reviewing code, and if you're like most of us, the honest answer is that you didn't, exactly. You started doing it because your team needed a second pair of eyes, on real PRs where mistakes have consequences, with nobody grading your work afterward. When you miss a bug in review, nothing tells you. The PR merges, everyone moves on, and the lesson, if it ever arrives at all, shows up so far from the moment you made the call that you can't connect the two anymore. You never learn which line you should have paused on, because you never find out what was in the diff that you didn't see.

This always worked poorly, but it used to be tolerable, because reviewing was the side dish and writing was the main course. That ratio has flipped. AI assistants now write a growing share of the code that lands in your review queue, and your role in the loop is shifting from "person who writes the code" to "person who decides whether the code should exist." The skill you never explicitly trained is quietly becoming the core of the job, and training it the old way, by making mistakes on production PRs and hoping you eventually notice the pattern, is starting to look like a genuinely bad idea.

Why the job doesn't teach it

The research on skill acquisition has been boringly consistent for decades: to get better at something, you need reps that are small enough to repeat often, feedback that arrives close to the attempt so you can connect the miss to the moment, and difficulty that stays slightly ahead of you so you're always working at the edge of what you can do. Sports coaches know this, chess trainers know this, and every typing tutor ever built knows this, and yet code review has none of it. Your reps come when a teammate happens to open a PR, which means some weeks you review ten times and some weeks zero. Your feedback is nonexistent, because a missed bug is silent and even a caught bug doesn't tell you what else was hiding in the diff that you walked past. And your difficulty is random: a one-line doc fix, then a 2,000-line refactor, then a config change, then something in a language you barely know. So the thing you're trying to get better at gives you no control over cadence, no signal about quality, and no progression curve, which is another way of saying it gives you everything except practice.

Practicing deliberately means building what the job refuses to give you: a steady stream of small, reviewable changes where the bugs are known in advance, so that when you finish, someone or something can tell you exactly what you caught and what you missed.

Where to actually get reps

There are a handful of places that work, and they all have real trade-offs, so I'd rather walk through them honestly than pretend there's one right answer.

The free, zero-setup option is reviewing open-source PRs. You pick a project you use, open its pull request queue, review an incoming PR in your head before the maintainers do, and then read what the maintainer actually said. The comparison is a decent feedback proxy when it works, and the code is as real as it gets. The downside is that scope is completely unbounded: you'll spend most of your time building context about a codebase you don't know, not actually judging the change, and on quieter projects the maintainer's review might never come, so you're grading yourself, which is basically the same problem you already have at work.

Exercism is an underrated option that works differently: you review other people's solutions to small coding exercises as a volunteer mentor. The code is small, the intent is clear, and the act of writing feedback that another human actually has to read and understand is half of what makes a reviewer useful in practice. What it won't train is spotting realistic, planted bugs, because the solutions are honest attempts by people trying to learn, so you're mostly reviewing for clarity and style rather than for defects that could ship.

Code-review.org is a free tutorial that walks through the fundamentals with exercises in Python and Fortran, and it's genuinely good for absolute basics and for the etiquette side of reviewing, things like how to phrase a comment so the author doesn't want to set their laptop on fire. But it's a course you take once, not a practice loop you can repeat, so it builds the vocabulary without building the reflex.

If your interest is specifically security review, PentesterLab's code review exercises hand you deliberately vulnerable code and ask you to find the hole, and the feedback loop there is real: the vulnerability is known ahead of time, so you find out exactly what you missed and why. It's narrow by design, though, so it trains one dimension of reviewing very well and doesn't touch the rest.

Reading post-mortems is the most passive option on this list and also the cheapest. Every incident write-up is a bug that survived code review at a company full of competent engineers, and reading enough of them builds a mental library of "shapes that slip through" that starts to fire on its own when you're in a diff. It compounds quietly over months, and it pairs well with anything else you're doing.

And then there's DiffDojo, which is ours, so calibrate accordingly. It's a site where you review realistic AI-written pull requests and get graded on what you caught and what you missed. You read the requirements and the diff, leave inline comments the way you would on a real PR, and give a verdict: approve or request changes. Every PR has a planted bug, or is deliberately clean (which is its own trap, because flagging a clean diff as buggy tells you something about your calibration too), and the moment you submit, you see exactly what you caught, what you walked past, and how a canonical review would have read the same diff. The whole library is over 200 PRs across Python, TypeScript, React, Angular and Node, and it's free with no signup.

Making it stick without willpower

The thing about skill work is that it fails the moment it requires discipline. A two-hour Saturday session sounds great in theory and gets skipped by week three because Saturday arrives and you'd rather do literally anything else. What actually sticks is something small enough that you can do it between your morning coffee and your first meeting: one graded rep a day, whatever the source, kept under ten minutes. When you miss something, write one sentence about why, not a journal entry, just enough to name the pattern: was it the wrong place to look, did you skim the boring part, did you trust a function name instead of reading the body? Those one-liners accumulate surprisingly fast into a map of your own blind spots, and knowing where your blind spots are is genuinely most of the work of fixing them.

If you want to layer something on top of that, one slow real-world review a week, an open-source PR in a project you know with the maintainer's response as your answer key, gives you the full-context version that the short daily reps can't. But the single habit that matters more than any of the others, on the job and in practice, is this: before you hit approve, say out loud what the change assumes. Not what it does, what it assumes. Assumptions are where the bugs live, and that's especially true now that so much code is written by a model that fills every gap in the spec with a plausible guess and never once stops to wonder whether the guess is right.

Common questions

Is there a website where I can review fake pull requests and get graded?

Yes, that's exactly what DiffDojo is: a library of realistic, AI-written pull requests with planted bugs where you review the diff, leave comments, give a verdict, and get graded on what you caught, what you missed, and whether you flagged things that were actually fine. It's free and doesn't require signup. PentesterLab offers a paid, security-focused equivalent if that's your area.

Is there a LeetCode for code review?

The closest thing is a graded-review trainer: LeetCode trains you to write code against known test cases, and a review trainer flips that by handing you code with known defects and scoring your judgment about what's wrong with it. DiffDojo is the free general-purpose option for that; Exercism mentoring gives you unscored but genuinely human practice where you're helping real people learn.

How long does it take to get better?

Faster than most people expect, as long as the feedback is immediate. Most reviewers find their blind spots, the category they consistently miss, whether it's concurrency or off-by-one boundaries or missing authorization checks, within the first twenty graded reviews. And once you can name a blind spot, fixing it turns out to be the easier half of the problem, because now you know where to look.