logo
CHEATSHEETSTOOLSABOUT中文

Maxims, Aphorisms, and Humor in Software Engineering

Over decades of software development, the community has accumulated an oral tradition of razor-sharp maxims, cautionary aphorisms, and satirical truths.

Beyond their wit, these sayings encode hard-won wisdom about human psychology, architectural debt, and system complexity.

The Four Stages of Developer Progression

[ Stage 1: Simple and Wrong ]
          │
          ▼
[ Stage 2: Complicated and Wrong ]
          │
          ▼
[ Stage 3: Complicated and Right ]
          │
          ▼
[ Stage 4: Simple and Right ]
  1. Simple and Wrong: A novice produces code that is clean and readable, but completely oblivious to race conditions, edge cases, and scale.
  2. Complicated and Wrong: An intermediate engineer discovers design patterns, abstractions, and generic frameworks, producing convoluted architectures that still fail on edge cases.
  3. Complicated and Right: A senior engineer masters edge cases and resilience, but solves them by layering defensive machinery, making the system massive and hard to navigate.
  4. Simple and Right: A veteran architect restructures the fundamental abstractions so that the edge cases dissolve naturally. The system is once again simple, but structurally sound.

On Simplicity, Deletion, and Restraint

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
— Antoine de Saint-Exupéry

  • Deleted code is debugged code. — Jeff Sickel
  • The cheapest, fastest, and most reliable components are those that aren't there. — Gordon Bell
  • Premature optimization is the root of all evil (or at least most of it) in programming. — Donald Knuth
  • Everything should be made as simple as possible, but not simpler. — Albert Einstein
  • The hardest part of design is keeping features out. — Donald Norman
  • Copy and paste is a design error. — David Parnas

On Debugging, Cleverness, and Complexity

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
— Brian Kernighan

  • If debugging is the process of removing bugs, then programming must be the process of putting them in. — Edsger W. Dijkstra
  • Beware of bugs in the above code; I have only proved it correct, not tried it. — Donald Knuth
  • The best performance improvement is the transition from the non-working state to the working state. — John Ousterhout
  • A good programmer is someone who always looks both ways before crossing a one-way street. — Doug Linder
  • Computers are good at following instructions, but not at reading your mind. — Donald Knuth

On Human Nature and Code Maintenance

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
— John Woods (popularized by Martin Golding)

  • Programs must be written for people to read, and only incidentally for machines to execute. — Harold Abelson and Gerald Jay Sussman (SICP)
  • Any fool can write code that a computer can understand. Good programmers write code that humans can understand. — Martin Fowler
  • The three great virtues of a programmer: Laziness, Impatience, and Hubris. — Larry Wall
    • Laziness: The quality that makes you write labor-saving programs so you don't have to repeat yourself.
    • Impatience: The anger you feel when the computer is lazy, driving you to write programs that anticipate future needs.
    • Hubris: The quality that makes you write code you are proud to attach your name to.
  • There are only two kinds of programming languages: those people always bitch about and those nobody uses. — Bjarne Stroustrup
  • Any code of your own that you haven't looked at for six months might as well have been written by someone else. — Eagleson's Law

On Estimation, Deadlines, and Reality

"The Ninety-Ninety Rule: The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time."
— Tom Cargill, Bell Labs

  • Measuring programming progress by lines of code is like measuring aircraft building progress by weight. — Bill Gates
  • Walking on water and developing software from a specification are easy if both are frozen. — Edward V. Berard
  • It’s a curious thing about our industry: not only do we not learn from our mistakes, we also don’t learn from our successes. — Keith Braithwaite
  • The software isn’t finished until the last user is dead. — Anonymous
  • If you’re not embarrassed by the first version of your product, you’ve launched too late. — Reid Hoffman

The Undecidable Boundary

The Halting Problem (Alan Turing, 1936)
No algorithm can ever exist that takes an arbitrary computer program and its inputs as arguments, and definitively determines whether that program will finish running or run forever.

Software engineering is fundamentally bounded by mathematical undecidability: static analysis, compilers, and linters can approximate, bound, and catch heuristics, but perfect automated correctness verification in general-purpose computing is mathematically impossible.

Sarcastic Truths

  • Java is to JavaScript what Car is to Carpet. — Chris Heilmann
  • A multithreaded file system is only a performance hack... concurrent programs wait faster. — Tony Hoare
  • The nice thing about standards is that there are so many to choose from. — Andrew S. Tanenbaum
  • In theory, there is no difference between theory and practice. But in practice, there is. — Jan L. A. van de Snepscheut
  • The best thing about a boolean is even if you are wrong, you are only off by a bit. — Anonymous
Loading...