The two specialist lenses a reviewer switches on for a diff — thinking like an attacker to catch the injection and the missing authorization check, and thinking like production to catch the N+1 query — while knowing exactly where the human eye stops and a scanner, profiler, or load test has to take over.
The specialist lenses: security review (untrusted input to a sink, missing authz/BOLA, secrets, SSRF, new dependencies) and performance review (N+1 queries, unbounded queries, missing indexes) — flag the smells, defer depth to scanners and profilers.
A reviewer's mental checklist ordered by leverage — design first, then correctness, then tests, then readability, with style and formatting handed off to the tools that were built for it.
A reviewer's checklist ordered by leverage: design first, then correctness and edge cases, then tests, then readability — and what to leave entirely to tools (formatting, lint) so human attention goes where it matters.
The first post in a practical series on code review — what the practice is actually for, what it is not, and why treating it as a collaboration rather than a gate is what makes it worth the time it costs.
The opener to a code-review series: what review is actually for — catching defects early, better design, knowledge sharing, collective ownership — and what it isn't (gatekeeping, style bikeshedding), plus the healthy team norms that make it work.