A code review roast is the application of editorial heat to a colleague’s pull request until the code is transformed from what the developer thought was done into what the codebase actually needs. It is the most common form of roast in software engineering, occurring approximately fourteen million times per day across GitHub, GitLab, and Bitbucket, and it ranges from the constructive (“have you considered extracting this into a function?”) to the devastating (“interesting approach”).
“Interesting approach” is the code review equivalent of “bless your heart” in the American South — technically a compliment, structurally a roast, and universally understood by everyone except the person who wrote the code.
“The best code review I ever received said nothing about the code. It said: ‘I see what you’re trying to do. You’re trying to solve Problem A. But this is Problem B. Step back.’ That was the entire review. It saved me three days.”
— The Lizard
The Vocabulary
Code review has developed its own euphemistic vocabulary, a system of polite indirection that allows developers to roast each other’s work while maintaining the fiction of professional courtesy:
| What they write | What they mean |
|---|---|
| “Interesting approach” | I have never seen anyone do this before, and I now understand why |
| “Have you considered…” | You should have considered |
| “Nit:” | This bothers me more than the word “nit” suggests |
| “Is this intentional?” | This cannot possibly be intentional |
| “This could be simplified” | This is the most complex solution to a simple problem I have ever seen |
| “LGTM” (after 30 seconds) | I did not read this |
| “LGTM” (after 2 hours) | I read this, I tested this, this is genuinely good |
| “Let’s discuss offline” | I cannot express what I need to express in writing without HR involvement |
| “Did you mean to commit this?” | You committed your debugging code / credentials / personal notes |
| “I have some thoughts” | I have a roast |
The Squirrel’s PRs
The Caffeinated Squirrel’s pull requests receive the most thorough roasts in any codebase. Not because the Squirrel writes bad code — the Squirrel writes technically impressive code — but because the Squirrel writes code that solves problems that do not exist, using abstractions that are not needed, with a framework that was proposed at 2 AM and that seemed brilliant before dawn and bewildering after coffee.
A typical Squirrel PR review:
Reviewer: “This PR adds a PluginManagerFactoryProvider. What plugins are we loading?”
Squirrel: “None yet. But what if—”
Reviewer: “Closing.”
The Squirrel’s PRs violate YAGNI with the enthusiasm of a developer who has read every design pattern book and wants to use all of them simultaneously. The reviews are roasts because the code is technically correct — it compiles, it passes tests, it handles edge cases that will never occur — and the only objection is that none of it should exist.
This is the hardest roast to deliver: “The code is good. The code should not be here.”
The Constructive Roast
The best code review roasts are indistinguishable from mentorship. They identify not what is wrong but what is unnecessary — the abstraction that adds complexity without adding value, the configuration that will never be changed, the error handling for scenarios that cannot occur.
The Test Coordinator reviews code the way he tests software: by finding the things nobody else thought to check. His code reviews are not line-by-line nitpicks. His code reviews are architectural observations — “this function works, but it assumes Module A and Module B share a database, and they don’t, and they won’t, and when they’re separated in Q3 this function will break in ways that the tests won’t catch because the tests also assume a shared database.”
This is the roast that saves you. Not the roast that says “rename this variable” but the roast that says “you are building on an assumption that is about to become false.” The heat is not on the code. The heat is on the future, which the reviewer can see and the developer cannot.
The Silent Anti-Roast
The worst code review is not a roast. The worst code review is silence. “LGTM” after thirty seconds. The rubber stamp. The reviewer who approves without reading because the standup is in five minutes and the PR has been open for three days and the developer is asking “did you get to my fix yet?” for the fourth time.
The silent review is the absence of heat. No transformation occurs. The code enters the codebase in the same state it left the developer’s machine — unexamined, unimproved, carrying whatever assumptions and shortcuts it was born with. This is a raw chicken served as dinner. Nobody applied the heat. Nobody did the work.
A roast is a gift. Silence is neglect dressed as efficiency.
Measured Characteristics
Code reviews per day (global, estimated): 14 million
Reviews that are actual roasts: ~15%
Reviews that are rubber stamps: ~40%
Reviews that are thoughtful: ~30%
Reviews that say "let's discuss offline": ~5% (HR-adjacent)
Reviews that discover credentials in the diff: ~0.1% (career-adjacent)
Time to write "LGTM" (rubber stamp): 30 seconds
Time to write "LGTM" (genuine): 2 hours
"Interesting approach" frequency: every codebase, every week
"Interesting approach" sincerity rate: 0%
Squirrel PRs reviewed: all of them
Squirrel PRs that should exist: debatable
Squirrel PRs closed with "what plugins?": several
The Lizard's review style: one sentence, correct
The Test Coordinator's review style: architectural, prophetic
The Squirrel's response to reviews: "but what if—"
The reviewer's response to that: "closing"
See Also
- Roast — The unifying taxonomy
- Roast (Comedy) — Same structure, different stage
- YAGNI — What most code review roasts are actually about
- Technical Debt — What accumulates when reviews are silent
- The Caffeinated Squirrel — The most reviewed entity in any codebase
- Test Coordinator — The reviewer who sees the future
- Boring Technology — What the best PRs propose
