2008. Robert C. Martin publishes Clean Code. The examples are Java. The audience is teams drowning in 3,000-line methods with no structure whatsoever. For that context, genuinely helpful.
Then the industry decided the rules were universal. One does wish they had read the room.
The Original
Java enterprise monoliths. Methods spanning thousands of lines. No separation of concerns. Code that required an archaeologist, not a developer. One method handled authentication, database access, and email dispatch in a single breath. The codebase did not need refactoring. It needed an intervention.
Martin's prescription was direct: functions should be two to four lines. Extract relentlessly. Zero arguments if possible. No nested control structures. For codebases where a single method did the work of an entire department, this was reasonable advice. The patient was in critical care. Strong medicine was appropriate.
The Copy
By 2012, "read Clean Code" had become the default onboarding instruction. Every language, every codebase, every team size. Java enterprise rules applied to Python scripts, Rust libraries, and shell functions with equal conviction and no adjustment whatsoever.
Code reviews stopped asking "is this readable?" and started asking "is this function longer than five lines?" The question changed. The craft did not improve.
The Cascade
Every well-intentioned rule has a trajectory. Clean Code's is particularly instructive because each step defeats the previous one's purpose.
You split a function to make it readable. Now you need eight functions to understand what one did. The engineering equivalent of cutting a novel into fortune cookies.
The Evidence
Martin's own example in the book tells the story rather well. Chapter 3 presents a refactored FitNesse module: fifteen methods, most of them single-line delegations. To understand the code, you hold the entire call graph in your head. The original was more readable.
He followed his rules perfectly. The result was not clean. It was fragmented.
Martin admits in the book: "I can't provide any references to research that shows that very small functions are better." Experience, not evidence. The industry treated it as law.
The Timeline
The prescription was published. The diagnosis was forgotten. The rest is history, and it rhymes rather predictably.
The Alternative
The alternative is not dirty code. It is lean code: one function, one job, readable without jumping. Clarity through simplicity, not through fragmentation.
A function that does one thing in thirty readable lines is cleaner than five four-line functions that mean nothing alone. The goal was never brevity. It was comprehension. If you need to hold fifteen nodes in working memory to follow the logic, you have not simplified anything. You have merely scattered it.
Dan Abramov learned this the hard way. He refactored a colleague's code to remove duplication. Requirements changed. The abstraction became a prison. His lesson: "Don't be a clean code zealot. Obsessing with clean code is a phase." Coming from a React core team member, that carries a certain weight.
The qntm review is more direct. It walks through Martin's own chapter 3 example line by line, fifteen methods deep, and concludes: the refactored version is harder to read than the original. Martin followed his rules. The rules failed.
The Irony
Clean code is not about line count. It is about clarity. Martin solved a real problem in 2008. The industry copied the prescription and forgot the diagnosis.
The rules were never universal. They were context-specific, aimed at a particular pathology in a particular ecosystem at a particular point in time. Applied without that context, they produce the very thing they were designed to cure: code that is harder to read than it needs to be.
Martin published Clean Code to fix Java monoliths where single methods did the work of entire departments. For that diagnosis, the prescription was fair. The industry photocopied the prescription and handed it to every codebase, every language, every team. KISS in your head, not rules on a wall.