We seated the masters of software at our code review

There is a shelf in our office. On it: Brooks on the mythical man-month, Ousterhout on the philosophy of software design, Kleppmann on the systems that store and move data, Anderson on security engineering, a battered Dijkstra, a Feathers with a cracked spine.Frederick P. Brooks, The Mythical Man-Month (1975). The essay that named the tar pit, the second-system effect, and why nine women cannot make a baby in a month. Most of the authors are retired. Some are dead. All of them, it turns out, make excellent code reviewers.

This is an essay about a small idea that quietly changed how we review software. It is this: if you want a machine to critique your code with taste instead of politeness, do not ask it whether the code is good. Name the person who would know.

The problem

The trouble with "looks good"

Point a capable model at a function without giving it a perspective, and the answer will often be agreeable. Looks solid. You might add some error handling. Consider extracting a helper. None of that is wrong. It is just nobody. It is the review you would get from a very well-read colleague who would rather not have an opinion in front of you.

A review with no point of view is autocomplete with a compliment. The reviewer who actually helps you is the one carrying a fixed, expensive idea of what good means, and the nerve to be disappointed by anything less. That reviewer is rarely a checklist. Checklists catch the absence of things. They are quiet about the presence of the wrong thing, which is where the interesting failures live.

The idea

Name the master

So we started naming names. Instead of "review this for design problems," we would ask: what would John Ousterhout say about this interface?John Ousterhout, A Philosophy of Software Design (2018). Deep modules: a simple interface over real complexity. The measure of a module is how much it lets a reader forget. The shift was not cosmetic. A name is the most compressed pointer we know into a body of judgment.

Say Kleppmann over a piece of code that stores or replicates data, and you do not retrieve a fact.Martin Kleppmann, Designing Data-Intensive Applications (2017). The standard text on what "reliable," "scalable," and "exactly once" actually cost. You retrieve a standing worry: about idempotence, about what "exactly once" really promises, about the lie every distributed retry tells itself. Nine letters, a career of hard-won suspicion. Say Ross Anderson over a parser and the trust boundary lights up.Ross Anderson, Security Engineering. Threat-model the thing nobody wrote down; assume the input is hostile because one day it is. Say Hoare over a chain of maybe-null returns and the billion-dollar mistake is suddenly in the room.

The anchor does the retrieval. You are not describing what to look for; you are summoning the person who spent a lifetime looking for exactly that.

The system

From a trick to a bench

A trick you use by hand is a trick you forget under deadline. So we built the panel into the method itself. A small core bench is always seated: the generalists of design and construction, the ones with something to say about any unit of code. Around them sits a reserve, and here is the part we are fond of. A master is seated by a property of the code, never by whim.

The code opens a database connection, and Kleppmann and Jim Gray pull up chairs.Jim Gray, Transaction Processing: Concepts and Techniques. What happens between the statements, when the power dies at the worst possible instant. It hand-rolls a token, and Schneier and Anderson lean in. It reaches for unsafe Rust, and a very particular book falls open. The shelf is not decoration. It is an index, and the code is the query. That is the whole move: your library, made executable.

A name is the most compressed pointer we know into a body of judgment. The anchor does the retrieval.

In practice

One function, three masters

Here are six lines you have written a hundred times, in one shape or another. A cache in front of a lookup.

async function getUser(id) {
  const hit = cache.get(id)
  if (hit) return hit
  const user = await db.query(
    "SELECT * FROM users WHERE id = " + id
  )
  cache.set(id, user)
  return user
}

It works on the happy path, and it may pass a review focused only on whether the code runs. Now let the bench in.

Three masters, one tiny function, three failures that live at different depths: a bug that ships a fix today, and two design decisions that deserve a proposal and a conversation rather than a silent rewrite. No single checklist item is likely to surface all three, because they are not the same kind of wrong. The panel makes them visible because each member is looking for a different kind.

The concrete suite behind this – the review profiles, checks, and evidence ladders – is part of our internal method. In client work, the criteria, findings, and supporting evidence remain transparent to you. And the central idea is yours for the taking: name the master, and put them where the code touches their life's work.

The discipline

Opinions are not verdicts

A room full of strong opinions is just a more literate way to be wrong. So the opinions do not get the final word; the evidence does. Runtime observations, tests, static analysis, and engineering judgment answer different questions. We give the greatest weight to the most direct, reproducible evidence for the risk at hand.

Anderson's suspicion about that query is not a finding yet. A focused test that passes a crafted id and retrieves records outside the requested user turns it into reproducible evidence. The conversation can then move from taste to an observed result. Where it matters, we measure instead of relying on estimates, reproduce before we assert, and use relevant boundary cases – empty input, expected peak volume, a row a hot cache never populates – to set the threshold that goes into the code.

The law

Savage about the code, gentle about the coder

There is one more member of the panel, and it outranks all the others. It has no opinion about caches or SQL. It governs how everything the others find is allowed to be said.

The unit of criticism is always a thing: a line, a schema, a query. Never a person.Amy Edmondson, The Fearless Organization. Psychological safety is not comfort; it is the precondition for anyone telling you the truth twice. This is not manners bolted onto rigor. It is part of the rigor. A review that shames does not merely feel bad; it works badly. Fear does not make defects disappear. It makes them go quiet, and the next audit finds less, not because there is less, but because people learned to stop pointing.Sidney Dekker, The Field Guide to Understanding Human Error. "Human error" is often a symptom of the surrounding system. Ask what made the mistake easy, not only who made it.

So every finding comes out in the same shape: what the evidence shows, what it costs, the standard it misses, and a concrete next step, offered as a recommendation with the fix left in the author's hands.Marshall Rosenberg, Nonviolent Communication. Observation, impact, need, request. The grammar that lets a hard thing be heard. git blame is a time machine for understanding why a line exists, not a courtroom for deciding who has to answer for it. We assume competent people did their reasonable best with what they knew at the time, because they almost always did.

Why the dead

The canon is compression

Why reach for people who did their best work before some of our engineers were born? Because the canon is compression across decades. Brooks watched a mainframe project overrun its plans and wrote down what he learned; decades later, many of the same patterns recur in new languages and new organisations.

Some software fashions fade in a handful of years. The classics remain useful because they were concerned with deeper forces than the framework of the season. A master is a bet with a long track record. When we anchor a review to one, we are not being nostalgic. We are using accumulated insight so your project does not have to rediscover it at unnecessary cost.