Preface: Why Do Quotes Endure?

“Talk is cheap. Show me the code.”

Linus Torvalds posted this single sentence to the Linux kernel mailing list on August 25, 2000. A quarter century later, engineers around the world still quote it.

Meanwhile, tens of thousands of other messages flowed through that same mailing list. The vast majority have been forgotten. Why did this one sentence from Torvalds survive? That question is what drove me to write this book.

The Structure of Words That Stick

In their book Made to Stick (2007), Chip Heath and Dan Heath distilled the conditions for memorable ideas into six letters: SUCCESs.

• Simple: Boil the core down to a single sentence
• Unexpected: Break predictions
• Concrete: Show tangible things, not abstractions
• Credible: Back it up with authority or track record
• Emotional: Move feelings
• Stories: Wrap it in narrative

Let’s examine Torvalds’ words through this lens.

Simple: “Stop talking, show me the code.” You can’t cut it any further. Unexpected: The leader of the world’s largest OSS project says “don’t discuss.” You’d expect a leader to value dialogue, yet he says the opposite. Concrete: “Code” — something every engineer can picture instantly. Credible: It carries weight because it comes from the person who started building Linux alone. The same words from someone who only talks would fall flat.

It satisfies four of the six conditions at once. That’s why this sentence hasn’t faded in twenty-five years.

Why This Book, Now

In 2025, Andrej Karpathy coined the term “vibe coding” — a development style where you accept AI-generated code without even looking at the diff. Meanwhile, Dijkstra wrote fifty years ago that “simplicity is prerequisite for reliability.” In an age where AI writes code, are the words of our predecessors still relevant, or are they relics of the past? To answer that question, I decided to dissect 100 quotes through the SUCCESs framework. To give away the conclusion: a surprising number of these words hit harder today than when they were first spoken.

How to Read This Book

This book selects 100 quotes from the history of engineering and organizes them into 10 thematic chapters.

Each quote comes with three layers of commentary:

1. Background: Who said it, when, and under what circumstances
2. SUCCESs Analysis: Which of the six conditions it satisfies
3. Practical Takeaway: How you can apply it to tomorrow’s work

From Chapter 1, “The Aesthetics of Code,” to Chapter 10, “The Engineer’s Way of Life,” feel free to start with any chapter you like. This is a book of quotes — there’s no need to read it in order.

And in the final chapter, “Crafting Your Own One-Liner,” I’ll show you how to use the SUCCESs framework to write sentences that stick in code reviews, documentation, and presentations. The goal of this book isn’t just to appreciate great quotes — it’s to make them your own weapon.

Who This Book Is For

• Engineers with at least one year of programming experience
• Anyone searching for anchors for motivation and technical decisions
• Those who want a systematic look at the wisdom of predecessors
• Tech leads and managers who want to move people with their own words

Most of the original quotes are in English, and this edition presents them with English commentary throughout.

Continue this chapter on Kindle →

Chapter 1: The Aesthetics of Code

What is beautiful code? The answer to this question has been remarkably consistent for over half a century. It is simple. It considers the person reading it. And its intent comes through even when the author is long gone. This chapter presents ten quotes about the beauty of code.

---

01. “Simplicity is prerequisite for reliability.”

— Edsger W. Dijkstra, EWD498 “How do we tell truths that might hurt?” (1975)

Background

In a 1975 memo, Dijkstra bluntly pointed out problems in programming education and the industry. In it, he condensed what’s needed to build reliable software into this single sentence. He was also the person who proposed the concept of “the humble programmer” in his Turing Award lecture (1972).

SUCCESs Analysis

• S (Simple): Compresses the causal chain “simplicity leads to reliability” into one sentence
• Cr (Credible): Backed by Dijkstra’s track record of establishing structured programming
• C (Concrete): The word “prerequisite” makes clear that simplicity is a necessary condition for reliability — not optional

Takeaway

The habit of asking “is this really necessary?” every time you add a feature is captured in this one sentence. Complexity is not a feature; it’s debt. Being able to say in a code review, “Can we make this simpler?” is the first step toward reliability. (-> Chapter 3 #23 “Keep it simple, stupid.”, #24 “You aren’t gonna need it.”)

---

02. “Programs are meant to be read by humans and only incidentally for computers to execute.”

— Harold Abelson & Gerald Jay Sussman, Structure and Interpretation of Computer Programs (1985)

Background

These words appear near the beginning of SICP (nicknamed “the wizard book”), a legendary textbook for computer science at MIT. The book uses LISP to teach the fundamentals of programming and put forward the idea that code is not instructions to a machine but a means of communication between humans.

SUCCESs Analysis

• U (Unexpected): Overturns the assumption that a program’s primary audience is the computer
• C (Concrete): Contrasts with the specific verbs “read” and “execute”
• Cr (Credible): From a textbook that served as MIT’s introduction to computer science for decades
• E (Emotional): The word “incidentally” acts as a quiet provocation against the everyday priorities of programmers

Takeaway

Name your variable elapsedDays instead of d. Write comments about “why” instead of “what.” Everything starts from this principle. The question when writing code is not “can the computer understand this?” but “will I understand this six months from now?” (-> Chapter 9 #81 “The hottest new programming language is English.”)

Note: Code readability is not a luxury — it is the very foundation of reliable software.

---

03. “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

— Martin Fowler (Kent Beck), Refactoring: Improving the Design of Existing Code (1999)

Background

This quote appears in Martin Fowler’s classic Refactoring and emerged from his collaboration with Kent Beck. Refactoring means improving a program’s internal structure without changing its external behavior. This sentence declares that its purpose is to improve readability for humans.

SUCCESs Analysis

• S (Simple): The contrast between “fool” and “good programmer” makes the structure crisp
• U (Unexpected): A provocation that dismisses “code a computer can understand” as something anyone can do

Takeaway

The moment working code compiles is not the finish line — it’s the starting line. Before submitting a pull request, ask yourself: “Could someone seeing this code for the first time understand it?” That one extra step changes the productivity of an entire team.

I felt this quote viscerally during a code review. I’d thought my data-transformation logic was “cleanly written,” but a reviewer commented: “It took me 15 minutes to figure out what this does.” The logic was correct. The tests passed. But if it takes 15 minutes to understand, it’s a liability for the team. From that day on, I started closing my screen before submitting a PR, then re-reading my own code with fresh eyes five minutes later. (-> Chapter 7 #66 “Code is like humor.”)

---

04. “UNIX is simple. It just takes a genius to understand its simplicity.”

— Dennis Ritchie

Background

These words come from Ritchie, co-creator of C and UNIX. The UNIX design philosophy is “combine small programs that each do one thing well.” Behind what looks like a straightforward approach lies layer upon layer of deep design decisions. Ritchie calls that design “simple” while acknowledging that truly understanding it is not easy.

SUCCESs Analysis

• U (Unexpected): The contradictory pairing of “simple” and “takes a genius” sticks in your memory
• Cr (Credible): Spoken by someone who actually built UNIX

Takeaway

Simple design is not “cutting corners” — it is the result of the most advanced design judgment. Implementing a complex problem in a complex way is easy. The truly hard part is stripping away the complexity.

---

05. “One of my most productive days was throwing away 1000 lines of code.”

— Ken Thompson

Background

These words come from Thompson, co-creator of UNIX. They’re a quiet rebuttal to the culture of measuring programmer productivity by lines written. Thompson is a Turing Award recipient who later contributed to the design of Go. Throughout his career, the stance of “cut what’s unnecessary” has been consistent.

SUCCESs Analysis

• U (Unexpected): The paradox of “productive” and “threw away.” Normally, a productive day means you wrote a lot
• C (Concrete): The specific number “1000 lines”

Takeaway

The amount of code is not the value. If you can achieve the same functionality with less code, that’s a better solution. If a refactoring reduces the line count, that’s progress.

I once owned an authentication utility module on a project. After three weeks of implementation — about 800 lines — a teammate noticed the whole thing could be replaced by a config change in an existing library. Honestly, I resisted at first. Throwing away three weeks of effort felt painful. But the moment I deleted it, test complexity dropped by half and CI build times got shorter. I understood firsthand what Thompson means by a “productive day.” (-> Chapter 3 #29 “The best code is no code at all.”)

---

06. “Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it.”

— Edsger W. Dijkstra, EWD896 “On the nature of Computing Science” (1984)

Background

Dijkstra repeatedly championed the value of simplicity, but in this 1984 memo he went further into “the difficulty of simplicity itself.” It’s not just hard to write simple code — recognizing the value of simple code itself requires education. A double-edged observation.

SUCCESs Analysis

• U (Unexpected): Confronts you with the fact that “simplicity” is not a synonym for “easy”
• E (Emotional): Resonates with anyone who has felt their effort toward simple code went unappreciated

Takeaway

You submitted simple code and were told to “try harder.” You explained a complex design and got praised. If you’ve had those experiences, remember Dijkstra’s words. If a culture rewards complexity, that’s an education problem within the team.

---

07. “I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy.”

— Yukihiro Matsumoto (Matz)

Background

Matz, the creator of Ruby, has consistently placed “programmer happiness” at the center of his design principles. Before Ruby, mainstream programming languages prioritized execution speed or type safety. A language that used “is the programmer happy?” as a design criterion was heretical at the time.

SUCCESs Analysis

• E (Emotional): Sets “happy” as the goal rather than technical efficiency. Speaks directly to the hearts of engineers

Takeaway

When choosing tools, it’s perfectly fine to factor in “is this tool enjoyable to use?” alongside benchmark scores. Developer experience (DX) is not a luxury — it directly affects long-term productivity.

---

08. “The principle of least surprise means principle of least MY surprise.”

— Yukihiro Matsumoto (Matz), Artima Developer (2003)

Background

The “Principle of Least Surprise” (POLS) is often cited as a Ruby design principle. In an interview, Matz clarified that this principle doesn’t mean “least surprise for everyone” but “least surprise for me, the language designer.” In other words, Ruby aims to be intuitive for people who have learned it well — it doesn’t need to be intuitive for every newcomer.

SUCCESs Analysis

• Cr (Credible): A design decision from the person who actually designed Ruby

Takeaway

When designing APIs or libraries, it’s important to be clear about “intuitive for whom.” No interface is intuitive for everyone. Deciding on a target user and pursuing consistency for that group tends to produce better design in the end.

---

09. “Elegance is not a dispensable luxury but a quality that decides between success and failure.”

— Edsger W. Dijkstra

Background

For Dijkstra, elegance was not about visual beauty but structural clarity. Elegant code is easier to understand, easier to debug, and easier to extend. It directly affects development speed and maintenance cost — it is a practical quality.

SUCCESs Analysis

• U (Unexpected): Redefines “elegance” from a “luxury” to “the factor that decides success or failure”
• S (Simple): Binary contrasts (luxury vs. necessity, success vs. failure) make the structure clear

Takeaway

Code that “just works” looks fast in the short term. But the pain of every subsequent change is the price of neglecting elegance. Saying “let’s make this cleaner” in a code review isn’t pushing aesthetic taste — it’s raising the project’s odds of success.

---

10. “Science is what we understand well enough to explain to a computer. Art is everything else we do.”

— Donald Knuth, Foreword to A=B (1996)

Background

As the title of The Art of Computer Programming (TAOCP) suggests, Knuth has positioned programming as an “art” (a craft). This quote draws the boundary between science and art at “whether you can explain it to a computer.” In other words, there is always a domain of programming that resists formalization. That domain is the “art.”

SUCCESs Analysis

• S (Simple): Compresses a complex debate into a science/art dichotomy
• C (Concrete): “Can you explain it to a computer?” is a clear test

Takeaway

Many design decisions fall in the domain of “art,” not “science.” There are qualities of good and bad that no benchmark can measure. Gaining experience means improving your accuracy in this “art” side of things. (-> Chapter 9 #82 “I’m mostly programming in English now”)

Continue this chapter on Kindle →

Chapter 2: The Philosophy of Bugs and Failure

Anyone who thinks software has no bugs has never written software. The words in this chapter don’t teach you to fear failure — they teach you how to live with it.

---

11. “Testing shows the presence, not the absence of bugs.”

— Edsger W. Dijkstra, NATO Software Engineering Conference (1969)

Background

The 1968-69 NATO Software Engineering Conferences were a historic forum where the “software crisis” was debated. Dijkstra used a single sentence to capture the fundamental limitation of testing. Even if tests pass a hundred times, you can’t claim there are zero bugs. This recognition laid the theoretical groundwork for why test-driven development and formal verification matter.

SUCCESs Analysis

• U (Unexpected): A surprising truth for anyone who assumed testing “guarantees safety”
• S (Simple): The presence/absence contrast makes it instantly understandable
• Cr (Credible): The historical weight of Dijkstra, a pioneer of formal verification, pointing out testing’s limits in 1969
• C (Concrete): The logically precise contrast between “presence” and “absence” grounds what could be an abstract discussion about testing

Takeaway

Don’t let 100% test coverage make you complacent. Tests are tools for reducing risk, not certificates that guarantee quality. Instead of “the tests pass, so we’re fine,” think “what problems can’t these tests catch?” That shift in thinking is the first step toward building solid systems. (-> Chapter 7 #61 “The only way to go fast is to go well.”)

---

12. “Beware of bugs in the above code; I have only proved it correct, not tried it.”

— Donald Knuth, Notes on the van Emde Boas construction of priority deques (1977)

Background

Knuth appended this sentence to the end of a memo, showing self-aware humor about the limits of formal proof. Even if you can mathematically prove something correct, you won’t find implementation bugs until you actually run it. The world’s greatest computer scientist acknowledging the gap between theory and practice.

SUCCESs Analysis

• U (Unexpected): The contradiction of “proved it” yet “haven’t tried it” is funny
• Cr (Credible): It carries weight precisely because Knuth said it about his own code

Takeaway

Confirming theoretical correctness during code review is important. But it’s no substitute for actually running the code. If you’ve ever said “the logic should be right, though…” remember that even Knuth acknowledged falling into the same trap.

---

13. “It’s easier to ask forgiveness than it is to get permission.”

— Grace Hopper

Background

These words come from Grace Hopper, a rear admiral in the U.S. Navy who contributed to the development of COBOL. She’s also known for the anecdote of discovering “the first bug” (a moth caught in a relay that she documented). Originally, this quote was a survival tactic for driving change within bureaucratic organizations. In a technical context, it’s widely cited to justify the approach of “try first, deal with problems later.”

SUCCESs Analysis

• U (Unexpected): A military rear admiral saying “it’s okay to break the rules”
• E (Emotional): Resonates with the universal frustration of “I want to do something but can’t get approval”

Takeaway

Introducing a new tool, proposing test automation, improving architecture — waiting for the approval process means nothing gets started. Building a small prototype and showing results is more persuasive than writing a hundred-page proposal. That said, doing this in production is a different story.

---

14. “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, The Elements of Programming Style (1978)

Background

Kernighan is known as the co-author of The C Programming Language (K&R). This quote comes from his book with Plauger, The Elements of Programming Style. It cautions against writing clever code and logically derives the case that simpler code is easier to maintain.

SUCCESs Analysis

• S (Simple): “Writing = difficulty X, debugging = 2X, therefore…” — arithmetic structure
• U (Unexpected): The paradox that “the ability to write clever code” works against you
• C (Concrete): The specific multiplier “twice” aids intuitive understanding
• Cr (Credible): A claim grounded in practice, from the co-author of the C language bible known as K&R

Takeaway

If someone says “I can’t figure out what this does” in a code review, that’s not a failure of the reviewer’s skill. Code that its own author can’t debug is a ticking time bomb for the team.

When I was starting out, a senior colleague had a one-liner combining nested ternary operators with bitwise operations. I assumed there was a performance reason. When a production bug hit that line, I investigated and found the only motivation was “I wanted to write it short.” Debugging took a full day. The fix was five straightforward if-statements. The moment both readability and correctness improved, I felt the meaning of Kernighan’s “twice” in my bones. (-> Chapter 1 #03 “Good programmers write code that humans can understand.”)

Note: Every bug has something to teach you — but only if you stop and listen.

---

15. “The most dangerous phrase in the language is, ‘We’ve always done it this way.’”

— Grace Hopper (attributed; similar statements confirmed, but the exact wording lacks a verified primary source)

Background

Widely attributed to Hopper, though Wikiquote notes it as an “unsourced variant.” It is confirmed that she made statements of similar intent, and there are records of her saying in interviews: “Go ahead and do it. You can always apologize later.” This quote also serves as a textbook example of attribution problems with famous sayings.

SUCCESs Analysis

• E (Emotional): Hits directly at the feelings of anyone who has felt trapped by old ways
• S (Simple): The impact of the flat-out declaration “the most dangerous phrase”

Takeaway

When you ask “why is it this way?” while maintaining legacy code and the answer is “it’s always been this way,” that’s not really an answer. Designs that persist without reason are breeding grounds for technical debt. At the same time, the fact that this quote’s own attribution is uncertain teaches us the importance of verifying sources when citing famous words.

---

16. “Shipping first time code is like going into debt.”

— Ward Cunningham

Background

Ward Cunningham coined the metaphor of “technical debt.” He’s also the inventor of the wiki (WikiWikiWeb). By comparing code quality to financial debt, he made it possible to explain technical problems to non-engineer executives. Debt itself isn’t bad. The problem is when you never pay it back and only the interest keeps growing.

SUCCESs Analysis

• C (Concrete): Maps the abstract concept of “code quality” to the familiar concept of “debt”
• Cr (Credible): Cunningham’s track record as a pioneer of wiki and XP

Takeaway

Getting technical debt to zero isn’t realistic. What matters is being aware that you’re deliberately carrying debt, and having a repayment plan. Teams that put “which debts do we pay down this sprint?” on their retrospective agenda are strong teams.

I once proposed “technical debt paydown” during a sprint planning meeting, and the product owner asked, “Is this an improvement users can see?” I used Cunningham’s debt metaphor directly: “Our current codebase is carrying debt at about 20% annual interest. Every new feature we add increases the interest, and in three months, our feature development velocity will be cut in half.” The numbers were rough estimates, but the words “debt” and “interest” translated a technical problem into business language on the spot. That week, two days of engineering time were allocated to refactoring. (-> Chapter 7 #68 “We will meet our schedules by knowing that the only way to go fast is to go well.”)

---

17. “Move fast and break things.”

— Mark Zuckerberg, Facebook internal motto (circa 2009-2014)

Background

Famous as Facebook’s early internal motto. It spread widely as a symbol of startup speed, but Facebook itself changed it to “Move fast with stable infrastructure” in 2014. In other words, this quote is instructive precisely because its limitations are part of the lesson.

SUCCESs Analysis

• S (Simple): Four words. You can’t make it shorter
• U (Unexpected): The boldness of affirming “breaking things”

Takeaway

What’s interesting about this quote is that its validity depends on the phase. During prototyping, it’s correct. But for a product with hundreds of millions of users, the cost of breaking things is catastrophic. The fact that Facebook itself revised the motto is perhaps the biggest lesson. (-> Chapter 5 #46 “Move fast with stable infrastructure.”)

---

18. “Fail fast, fail often, fail forward.”

— Silicon Valley maxim (difficult to attribute to a specific individual)

Background

A phrase that epitomizes Silicon Valley culture, though attributing it to a specific person is difficult. It’s also known as the title of a John C. Maxwell book (2007). It expresses the core of startup culture — “failure is a learning opportunity” — but is sometimes misused to justify reckless failure.

SUCCESs Analysis

• S (Simple): The refrain of three “fails” (with alliteration) makes it stick

Takeaway

Failure itself has no value — the value is in what you learn from failure. The “fail forward” part matters most. Repeating the same failure is “fail backward.” In teams without a postmortem culture, this quote remains an empty slogan.

---

19. “First, solve the problem. Then, write the code.”

— John Johnson

Background

Widely quoted among programmers, though the detailed biography of John Johnson is unclear. But this quote’s value lies in its content, not its attribution. Understand the problem before reaching for the keyboard. Design the solution in your head. Only then write code. One sentence captures that process.

SUCCESs Analysis

• C (Concrete): The contrast between the specific verbs “solve” and “write”

Takeaway

Stand at the whiteboard before opening your IDE. Confirm the requirements before writing tests. If you start implementing while what you’re building is still vague, the cost of rework grows exponentially.

---

20. “The amateur software engineer is always in search of magic.”

— Grady Booch

Background

These words come from Grady Booch, one of the creators of UML (Unified Modeling Language). A new framework, a new language, a new methodology — the illusion that one “silver bullet” will solve everything is what Booch calls “magic.” It’s in the same lineage as Fred Brooks’ “No Silver Bullet.” (-> Chapter 4 #35 “No Silver Bullet.”)

SUCCESs Analysis

• C (Concrete): The vivid image of “magic”
• Cr (Credible): The authority of a UML designer and software engineering leader

Takeaway

Jumping on every new technology that comes along is fun, but silver bullets don’t exist. It’s not the tool that solves the problem — it’s the judgment of the person using the tool. What matters in technology selection is not “what can it do?” but “does it fit our problem?”

Continue this chapter on Kindle →