2026-03-04

Approved. Unread. Shipped.

Every team has a code review process. Tickets move, PRs open, comments accumulate, something gets merged. The system looks like it’s working because the system looks like it’s working.

This is about what actually happens in the middle part – between “created” and “merged” – and the people doing it. You’ve worked with all of them. One of them is you.

The Pure Engineer

“Politics is for people who can’t write good code.”

Every review is a technical audit. Twelve comments on variable names. Zero on whether the feature being built is orthogonal to the direction the company announced last quarter. The code is correct. The code is clean. The code should not exist.

Speaks fluently in O(n). Has nothing to say when the third person this quarter rage-quits after their PR sat unreviewed for two weeks – not blocked, not rejected, simply never opened. The Pure Engineer was busy. There was interesting work to do. Reviews are interruptions to engineering, and engineering is the point.

Has the papers to prove his views on linters. Could talk for forty minutes about why the team’s current approach to error handling is suboptimal, and if given the opportunity, will do exactly that – at the all-hands, at the retro, in your DMs.

That third person left a note in their exit interview. The Pure Engineer was CC’d on the summary email. Did not read it. Was in the middle of a code review.

It was a good review. Six comments. All technical. All correct.

The feature it reviewed was quietly deprioritized the following Monday. Nobody told him. He wouldn’t have found it relevant.

The Team Wellness Champion

“Code is not real. People are real.”

Has never blocked a PR in his career. Mentions this at onboarding. Mentions it at retros. Has it in his LinkedIn headline, between “servant leader” and “psychological safety advocate.”

Calls a retro when two engineers disagree on tabs versus spaces. Calls a retro when the retro runs long. The retro about the retro has a Miro board. There are sticky notes. Everyone’s feelings are now on the board, color-coded by emotional category. The underlying disagreement is unresolved but has been, crucially, held.

So inclusive that when four engineers proposed four different patterns for the same abstraction, the Team Wellness Champion welcomed all four. To pick one would have been to make three people feel wrong about their diff. The codebase now contains all four patterns, coexisting in a state of permanent détente. New engineers spend their first two weeks asking which one to use. The answer, delivered warmly, is “whichever feels right to you.”

Has read three books on psychological safety. Is halfway through a fourth. Has not read the diff – not because he can’t, but because the diff is not where people are.

The codebase, which has the structural integrity of a compromise, was built entirely by people who felt heard. They have since left for companies where someone, at some point, said no to something. They describe the Team Wellness Champion fondly. They would not work for him again.

The Keeper of the Illuminati

“It is a common knowledge”

Has opinions about your code that predate your birth. Leaves 47 comments on a two-line change. Each one cites a source – a 1987 proceedings paper, a blog post from a defunct Sun Microsystems engineer, a book on software craftsmanship that exists in three known copies, one of which is in a climate-controlled room in a castle outside Bratislava. Does not write review comments. Writes treatises. PRs assigned to him develop a specific texture: they go quiet for four days, then return as a PDF.

Junior engineers have been seen physically recoiling from their laptops upon receiving his feedback. Not because it’s wrong – it’s often technically impeccable – but because it arrives with the energy of a disappointed Talmudic scholar who has been waiting his entire career for someone to finally ask about method naming conventions so he can explain, at length, why everyone has been doing it incorrectly since 1994.

Turnover under his watch runs at roughly two engineers per quarter. He attributes this to “low standards in the hiring pipeline.” His own PRs, notably, are never reviewed by anyone. Not out of malice. Nobody has the references to engage.

The Half-Human Half-Bat

“What’s wrong in wanting to be consistent?”

Echolocates inconsistency from three kilometers. Maintains a weekly, color-coded spreadsheet tracking punctuation habits per engineer. Notices you switched from trailing commas to no trailing commas between Tuesday and Thursday and will bring it up, gently, with three suggested fixes and a kind smile.

Leaves twelve comments on a PR. Eleven are perceptive, well-reasoned, and delivered with genuine warmth. The twelfth is a nit on the third nit. The nit has a sub-nit. It’s turtles.

Suggests improvements prolifically and without ego – a cleaner abstraction here, a pattern that might scale better there, a note on how the team usually handles this. The suggestions are good. Many are excellent. You implement six of them gratefully.

Meanwhile, DROP TABLE users; – left in since last Wednesday, commented out with a // TODO: remove before merge, sitting plainly at line 47 of the diff – ships to production on Friday. The bat’s sonar, finely tuned to detect a missing Oxford comma at subsonic speeds, simply does not register it. It is not a style violation. It is not inconsistent with prior usage. It is not a nit. It is, technically, fine.

Post-incident review: he finds four formatting issues in the incident report.

The Catalyst

“Just trying to be helpful.”

Reviews your PR before you’ve finished writing the description. You hit “Create Pull Request,” look up to reach for your coffee, and it’s already approved. Not rubber-stamped – reviewed. There’s a warm comment acknowledging the clever bit on line 23. There’s a genuine “great work here” that makes you feel, briefly, like a craftsman.

The Catalyst never neglects. Never gatekeeps. Embodies the free-flowing stream of merged code the team, in its heart, always wanted to be. First to review, last to block. Shows up for the 5,000-line PR with the same wholehearted energy as the typo fix. No change too large. No engineer left waiting. This is a person living their purpose.

Blink and you miss it. Literally. The PR was open for eleven seconds. You were looking at it. You blinked. It’s merged.

Spaghetti code doesn’t arrive in production via any single dramatic incident. It arrives the way hemlines change – gradually, then all at once – one lovingly encouraged strand at a time. Each strand was acknowledged. Each engineer felt seen. The architecture, which no longer has a discernible shape, was assembled entirely from PRs that received genuine, timely, positive engagement.

Cannot be blamed. Was never not paying attention. Was, in fact, paying the most attention of anyone – to your feelings, to your effort, to the flow state of the team.

Just not to line 47.

The Stoic

“Not my circus. Not my monkeys.”

Reviews with the serene detachment of someone who has made peace with all possible outcomes. The PR reimplements database joins in frontend JavaScript across 400 lines? The code does what it says it does. LGTM. A utility function that could be eight clean calls is instead a self-contained universe of nested conditionals? Consistent with prior art. LGTM. PostgreSQL has been quietly replaced by a JSON file in the repo root named data_final_v3_REAL.json? Not his feature. LGTM.

Has a carefully selected perimeter. Inside: complete rigor, genuine expertise, standards held without compromise. Outside: the rest of software engineering, which is someone else’s problem and always will be.

Saw DROP TABLE users; on line 47. Noted it. It was not inside the perimeter. The perimeter was established thoughtfully, years ago, after a period of burnout nobody talks about anymore. The perimeter is healthy. The perimeter is necessary. The perimeter does not cover line 47.

The incident happened on a Friday. The Stoic was not paged. It was not his feature. He was reachable, had it been his feature, but it wasn’t, so he wasn’t, and that’s simply how the perimeter works.

The Philosopher

“Let’s consider all the angles.”

Has noticed something.

Two lines into the diff, there is a function. The function touches a boundary. The boundary implies a scope. The scope, if you follow it – and the Philosopher will follow it, has already begun following it, is three tabs deep into following it – implies an architectural decision made in 2019 that was never fully interrogated.

This is IT.

IT is not the PR. IT is what the PR reveals. IT is the question underneath the question – the shape of the thing the team has been building without realizing what shape they were building. The Philosopher has seen IT before, in other codebases, at other companies, and IT always ends the same way unless someone stops and asks about IT properly.

Considers IT. Sits with IT. Opens a blank document and writes three paragraphs about IT, then deletes two because they weren’t precise enough. Queries two senior engineers about their memory of the original decision that created IT. Schedules a thirty-minute call to discuss IT, which runs to ninety minutes and produces a shared doc with seven open questions, none assigned to anyone.

Writes the review comment. It is long. It is genuinely brilliant. It traces IT from its origins through its present form and gestures, eloquently, toward what IT could become if the team were willing to have the conversation IT deserves.

The PR, unreviewed, has been waiting eleven days.

The author has since rewritten it twice to avoid IT. The Philosopher has noticed the rewrites. They also raise questions about IT. Different questions now. Possibly more important ones.

Forgets to approve. Not out of negligence – out of genuine absorption. The review is not done. IT is not resolved. You cannot approve something when IT is still open.

IT will always be open.

The Traveling Salesman

“It’s a missed opportunity!”

Has a library.

The library is fine. Genuinely, it solves a real problem, handles edge cases thoughtfully, has decent test coverage and a README written with care. In the right context, on the right project, it provides real value. The Traveling Salesman knows this because he wrote it, maintains it, and has been thinking about it, at some level, continuously since 2021.

Your PR is about pagination. The Traveling Salesman has read it carefully. He has one comment.

Have you considered the library?

The library handles pagination. Not exactly this pagination – the library’s model is slightly different, would require some adaptation, and honestly the wrapper you’d need to write is probably longer than the code you submitted. But that’s not the point. The point is the library. Have you looked at it recently? It’s been updated. There’s a new API. The new API would make this cleaner – not immediately cleaner, there’s a migration cost, but eventually, architecturally, in the fullness of time, cleaner.

Leaves four comments. All four are the library. Two link to different sections of its documentation. One is a code snippet showing how this could be done with it. The snippet is longer than your PR.

Will not block. Is not here to block. Is here to make sure that when you merge this code, you do so knowing about the library, having considered the library, carrying it forward in your heart as a possibility not yet taken but perhaps someday – someday – embraced.

Captain Handwave

“This problem needs to addressed.”

Has found Problems.

Not small problems. Real Problems. Structural Problems. The kind that, if you follow the thread – and Captain Handwave has followed the thread, has traced it back fourteen years to a commit message that reads “temp fix, will revisit” – implicate three project teams, two legacy systems, and a foundational assumption baked into the architecture that nobody alive at the company was present to make.

The Problems are real. This is important to establish. Captain Handwave is not crying wolf. The wolf is there. It has been there since 2011. It has not bitten anyone yet, but it is a wolf, and it is present, and SOMEONE should be aware of it.

Leaves a comment. It is thorough. The Problems are enumerated. The history documented. The potential blast radius, in a sufficiently unlucky sequence of events, described with genuine accuracy. Taken purely as a piece of technical writing, it is correct.

It does not contain a suggestion. It contains a gesturing – firm, well-reasoned gesturing – toward the general direction in which a suggestion might someday live. SOMEONE should address this. A task force, perhaps. A principal engineer with unmeasurable power and calendar availability. A ninja. The comment should be escalated. To whom, exactly, is left as an exercise for the reader.

The PR, meanwhile, changes a button label.

Captain Handwave approves it. The Problems, after all, predate the button. The button is not the Problem. The Problem is the Problem. It has been the Problem for fourteen years and will continue to be the Problem long after this button is in production, long after this codebase is retired, possibly long after the company itself has been acquired and the Slack workspace archived.

Someone should really do something about it.

You

“Not like the others.”

You’ve read through these archetypes with growing recognition – not self-recognition, the other kind. The kind where you nod along because you’ve worked with these people. The Philosopher, the Stoic, the Catalyst. You know exactly who each one is. You could name them. You’ve complained about them, specifically, to your partner over dinner, using their actual names.

You are sensible. Level-headed. You try your best, which is all anyone can do, and your best is – genuinely, you think – pretty good. Your reviews are fair. Occasionally direct, but fair. If someone misreads the tone of a comment, that’s a reading problem, not a writing problem, and you can’t be expected to pad every piece of honest technical feedback with emotional bubble wrap just because some people find directness uncomfortable.

You have no odd habits. No blind spots you’re aware of. No particular axis you over-index on. You just review the code. Objectively. As an engineer.

You would have noticed by now.

You’re currently three weeks into a running comment thread with a junior engineer about a variable name. You started it. You’re not wrong about the variable name. You’ve said so several times, each with slightly more clarity, because the issue is that they’re not understanding your point yet – and once they do, they’ll see you’re right, and then it’ll be resolved, and that’ll be that.

You don’t have a style. You just have standards.

You would’ve noticed.