If you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read. — Robert C. Martin
—What lingers after this line?
Speed Begins With Clarity
At first glance, Robert C. Martin’s quote sounds paradoxical: if you want to move quickly, slow down enough to make your code easy to read. Yet the insight is practical rather than poetic. Most of the time spent in software development is not in typing new lines but in understanding existing ones, whether they were written yesterday or years ago. Readable code shortens that understanding loop, allowing developers to make changes with less hesitation and fewer mistakes. In that sense, readability is not a luxury added after the real work is done; it is part of the real work. Clear names, small functions, and straightforward structure help the next decision happen faster. As Martin argues throughout Clean Code (2008), code is read far more often than it is written, so optimizing for reading often becomes the quickest route to delivery.
Why Hard-to-Read Code Slows Teams Down
From there, the quote expands beyond individual productivity to team dynamics. A clever but obscure implementation may feel fast to write in the moment, yet it creates hidden costs for everyone who touches it later. Teammates must decode intent, trace dependencies, and guess at assumptions that were never stated clearly. What looked like speed at the keyboard becomes delay in maintenance, debugging, and review. This is why many engineering teams treat readability as a form of operational efficiency. Code review practices at companies like Google, reflected in its Engineering Practices documentation, consistently emphasize understandable code over flashy shortcuts. The reason is simple: when a team can read code quickly, it can discuss, test, and improve it quickly as well.
Readable Code Reduces Bugs
Just as importantly, readable code is often safer code. When logic is expressed plainly, errors become easier to spot because the program’s intention is visible on the page. By contrast, dense abstractions, overloaded functions, and cryptic variable names hide defects inside unnecessary complexity. A bug survives longer when nobody can immediately see what the code is trying to do. This principle echoes Antoine de Saint-Exupéry’s oft-cited design idea from Terre des hommes (1939): perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. In programming, simplification helps correctness. The easier a function is to read, the easier it is to test mentally, review collaboratively, and trust in production.
Ease of Writing Follows Ease of Reading
Martin’s quote also makes a subtler claim: if you want code to be easy to write, make it easy to read. That may seem backwards until we notice that readable systems are easier to extend. When modules have clear responsibilities and interfaces, developers do not have to reinvent the architecture each time they add a feature. They can follow visible patterns instead of wrestling with ambiguity. Over time, this creates compounding benefits. A well-structured codebase teaches its own conventions, almost like an internal guidebook embedded in the source. By comparison, a messy codebase forces every new change to begin with archaeology. Thus readability does not merely help future readers; it actively lowers the effort required for future writing.
A Lesson Proven in Real Projects
In practice, nearly every experienced developer has lived through this lesson. A feature rushed out with tangled logic may appear complete by Friday, only to consume the next week in bug fixes and confusing revisions. Conversely, a slightly slower first draft with meaningful names and clean separation often proves faster overall because it survives contact with real use. The initial investment pays back almost immediately. This pattern is visible in the culture of long-lived software projects, from Python’s emphasis on readability in The Zen of Python by Tim Peters (1999)—“Readability counts”—to mature open-source repositories where maintainers favor explicitness over tricks. The anecdotal evidence is overwhelming: code that welcomes readers is code that keeps delivering value.
Readability as Professional Discipline
Ultimately, the quote is a reminder that programming is communication as much as construction. Code speaks to future teammates, future maintainers, and even to our future selves, who will return with less memory than we expect. Writing readable code means respecting that audience. It turns private thought into shared understanding, which is the foundation of sustainable speed. Therefore, Martin’s advice is not simply about style but about professional discipline. Fast development, quick completion, and ease of authorship all emerge from the same source: code that can be understood without struggle. In the long run, readability is not the enemy of velocity; it is one of its most reliable causes.
One-minute reflection
What feeling does this quote bring up for you?
Related Quotes
2 selectedPrograms must be written for people to read, and only incidentally for machines to execute. - Harold Abelson
Harold Abelson
Harold Abelson’s line reframes programming from a primarily mechanical act into a human one: code is a message passed between people, with the computer serving as the strict but secondary interpreter. In this view, corre...
Read full interpretation →Programs must be written for people to read, and only incidentally for machines to execute. - Harold Abelson
Harold Abelson
Harold Abelson’s line flips a common beginner assumption: that programming is chiefly about instructing machines. Instead, it frames software as a human communication medium where the true audience is other developers (a...
Read full interpretation →More From Author
More from Robert C. Martin →