Last month, Brad published Shame-Driven Development, where he argued that shame is an underutilized motivational tool in software engineering. The post was well-received. Productivity went up. Code quality improved. But Brad's approach relied on implied shame ā the silent judgment of a green CI badge on someone else's PR while yours is red.
We found the implied approach too slow. Some engineers don't pick up on subtext. One developer had a failing build for three days and didn't notice the team's energy shift. We needed something more direct.
We needed insults.
"Linus Torvalds has been doing insult-driven code review for decades and the Linux kernel is the most successful software project in history. Correlation, causation ā at this point, does the distinction matter?"
The Framework
Insult-Driven Development (IDD) replaces traditional code review comments like "nit: consider renaming this variable" with emotionally calibrated feedback designed to motivate immediate improvement. The key word is calibrated ā IDD is not bullying. It's structured, consented-to, and scored on a rubric.
Every engineer on the team signs an IDD waiver during onboarding. The waiver states: "I understand that code review comments may contain language that, in other professional contexts, would be considered inappropriate. I consent to this because my code is inappropriate and someone needs to say it."
The Insult Tier System
Not all code deserves the same level of insult. We've developed a five-tier system:
Tier 1: The Gentle Nudge
For minor style issues. Example: "This variable name tells me nothing about what it does, much like your commit messages."
Tier 2: The Raised Eyebrow
For logic errors. Example: "I see you've implemented your own sorting algorithm. It's O(nĀ³). I didn't know that was possible for a sort. I'm genuinely impressed, in the medical sense of the word."
Tier 3: The Professional Concern
For architectural issues. Example: "This class has 14 responsibilities. The Single Responsibility Principle suggests one. I'd settle for fewer than the number of people who've quit this team."
Tier 4: The Existential
For serious design flaws. Example: "I've been staring at this pull request for twenty minutes and I'm starting to question not just your code but my own career choices that led me to a position where I'm reviewing it."
Tier 5: The Torvalds
Reserved for production-breaking changes pushed without tests. This tier is rarely invoked and requires sign-off from two senior engineers. Example: [REDACTED by HR]
Tier 5 was temporarily suspended after an incident in February. It has been reinstated with additional guardrails, including a mandatory 10-minute cooling period and a review of the insult by someone not involved in the PR. We call this person the "Insult Auditor." Three engineers have applied for the role.
Calibration
IDD requires careful calibration. An overly harsh review on a minor issue erodes trust. An overly gentle review on a major issue defeats the purpose. We maintain a shared spreadsheet ā the Insult Calibration Matrix ā that maps code issue severity to appropriate insult tier, with example phrases for each cell.
The spreadsheet has 847 rows. It's the most-viewed document in our Google Drive. It gets more traffic than the engineering wiki. New engineers read it cover to cover on their first day. Several have described the experience as "formative."
Response Protocol
IDD is not one-directional. The reviewed engineer has three valid responses:
- "Fair." Acknowledges the insult, fixes the code. This is the most common response and the healthiest outcome.
- "Counter." The reviewee insults the reviewer's review. This is allowed once per PR and must be code-related. Personal attacks are not permitted. Attacks on the reviewer's use of Hungarian notation, however, are encouraged.
- "Escalate." If the insult exceeds the appropriate tier for the issue severity, the reviewee can file an Insult Calibration Dispute. These are adjudicated weekly by the Insult Auditor. Disputes are rare because most engineers agree their code deserved it.
Measured Outcomes
- PR review turnaround time: down 45% (nobody wants their code sitting in review accumulating insults)
- Code quality: up 28% (engineers write better code when they know the review will be personal)
- Test coverage: up from 34% to 89% (untested code receives automatic Tier 3 reviews)
- HR inquiries: 7 (all resolved by showing the signed IDD waiver)
- Engineers who opted out: 1 (he was allowed to receive standard code reviews; he reported feeling "left out" after two weeks and opted back in)
- Team retention: identical to before IDD (turns out the people who leave were going to leave anyway)
IDD is now entering its second quarter. We're developing a Slack bot that auto-generates Tier 1 insults for style violations. The bot's working name is "CodeMeanie." Brad wanted to call it something worse. HR said no.