There's a particular kind of pride in writing a dense, elegant one-liner that does something impressive. Brian Kernighan, one of the people who shaped Unix and C, put a devastating argument against it: debugging is twice as hard as writing code, so if you write code as cleverly as you possibly can, you are by definition not smart enough to debug it.
Key Takeaways
- Kernighan's Law: debugging is twice as hard as writing the code, so maximally clever code exceeds your own debugging ability (Kernighan's Law).
- It traces to Kernighan and Plauger's The Elements of Programming Style (Laws of Software Engineering).
- The practical implication is to write simple code aimed at long-term maintainability.
- Cleverness spends a budget you'll need later, when the code breaks.
The Argument
The original line, from Kernighan and Plauger's The Elements of Programming Style, is worth reading slowly: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" (Kernighan's Law). It usually circulates today in a punchier paraphrase, which ends "you are, by definition, not smart enough to debug it." The logic is almost mathematical. If writing takes X of your capability and debugging takes 2X, then writing at 100% of your capability produces something you need 200% to debug. You've written code beyond your own ability to fix.
That's already uncomfortable. It gets worse in a team, because the person debugging your clever code at 3am is usually not you, and they have less context than you did. Cleverness that only barely fits in the author's head does not fit in anyone else's at all.
| Clever code | Simple code |
|---|---|
| Impressive to write | Easy to read |
| Hard to debug, even for the author | Debuggable by anyone |
| Fits one head, briefly | Fits every head, later |
| Optimizes for the writing moment | Optimizes for the next five years |
Why This Matters More Than It Sounds
Engineers spend most of their time reading and understanding existing code rather than writing new code, as the legacy-code reality shows. So the moment of writing, when cleverness feels good, is a tiny fraction of a piece of code's life. Everything after that is reading, debugging, and modifying, and clever code taxes every one of those.
There's also a compounding effect with Hyrum's Law: clever code tends to have subtle observable behaviors that people accidentally depend on, so it becomes both hard to understand and hard to change safely.
A Concrete Version
An engineer replaces a straightforward twelve-line loop with a single dense expression chaining four higher-order functions and a clever bit of destructuring. It works, it's shorter, and the PR gets an approving comment about elegance. Nine months later a subtle bug appears in that expression. The original author has left. The engineer assigned to fix it spends two days understanding what it does before she can even locate the defect, and ends up rewriting it as the twelve-line loop it started as. The clever version saved eleven lines and cost two days.
The Honest Counterpoint
A caveat on the wording: the version most people quote, ending "you are, by definition, not smart enough to debug it," is a later paraphrase rather than the original sentence, though the idea traces directly to Kernighan and Plauger (the source). More substantively, "never be clever" taken literally is wrong. Some problems genuinely require sophisticated solutions, performance-critical paths sometimes justify dense code, and deliberately using a powerful language feature is different from showing off. The real rule is about gratuitous cleverness: complexity that buys elegance rather than necessity. When sophistication is genuinely required, the answer is to pair it with tests and comments explaining why, rather than to avoid it.
What This Means for Teams
Kernighan's Law is a decent proxy for engineering maturity. Junior engineers often write clever code to demonstrate capability; senior engineers write boring code because they've been the person debugging someone else's brilliance at 3am. That preference for the obvious solution over the impressive one is exactly the judgment we screen for in how to verify a senior engineer, and it's the same instinct behind choosing boring technology. See available engineers.
Frequently Asked Questions
What is Kernighan's Law?
The observation that debugging is twice as hard as writing code, so if you write code as cleverly as you possibly can, you won't be capable enough to debug it. It argues for simple, maintainable code.
Does it mean I should never write sophisticated code?
No. Some problems genuinely require sophisticated solutions, and performance-critical paths can justify density. The target is gratuitous cleverness, complexity that buys elegance rather than necessity.
Why is clever code especially bad on a team?
Because the person debugging it later usually isn't the author and has less context. Code that barely fits in the writer's head doesn't fit in anyone else's.
Is the quote definitely Kernighan's?
The idea and the original wording come from Kernighan and Plauger's The Elements of Programming Style. The punchier version ending "by definition, not smart enough to debug it" is a later paraphrase rather than their original sentence.
The Bottom Line
Writing is the cheap part; debugging and reading are where code actually spends its life. If you write at the very edge of your ability, you've built something past your own capacity to fix, and well past your teammates'. Choose the obvious solution, save sophistication for where it's genuinely required, and leave code the next person can actually debug.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
