In a field as vast and varied as software engineering, constant reading is essential for building foundational knowledge and exploring branch knowledge. As in any profession, software development has its must-reads, and Clean Code is one of them. The book comes up consistently in Google’s search results for “top software engineering books,” and it’s well-known in engineering circles.

Here are a few lessons learned from engaging with this touchstone for the very first time.

In many ways, Clean Code is structured like an owner’s manual for code. It’s an extremely opinionated book, as most great books are.

Martin describes best practices and deconstructs poor practices, admonishing those who fail to recognize why and how those habits are bad. Martin is open about his failures. Years of reading (and sometimes writing) bad code have made him intent on helping other developers avoid danger. Taken together, the book’s hundreds of recommendations no doubt produce pristine code. That said, most engineers learn the hard way — by suffering through enough bad code that they want to make it better.

But Clean Code is more than a tutorial. It describes not just how but why to write good code. More than rote memorization of rules (though many of the book’s rules stick with me), I read to understand a great programmer’s inviolable values. For me, it all boiled down to three key concepts.

1. Craftsmanship Matters

Rarely does a coder have the freedom to sit with a piece of code until it’s perfect (also, “perfect code” is an illusion; everything has flaws). Still, writing the best possible code should be a software crafter’s top priority. At times, they may mean pushing back against deadlines, client demands, management demands, and fatigue. Business conditions often set boundaries on what’s “possible,” but a coder always has at least some control over the quality of what he or she writes.

Bottom line: Code that “works” is not always “done.” If a coder’s job is to produce a product that solves a problem, should it matter how it solves the problem? Yes. Software done well benefits everyone in the long run — clients, users, companies, and coders. Code that is messy, rushed, or “good enough” is code with an eye on short-term returns.

Poorly crafted code frays at the edge much faster than you might expect.

Martin suggests that the key to writing stellar code is high-quality input (thoughtful, maintainable, flexible code) that results in high-quality output (long-term business payoffs).

2. Extra Effort Today Saves Pain Tomorrow

All of us have experienced the disappointment that comes with using a low-quality product. Think of the new shirt that frays at the edges after just a few runs through the washing machine, or the plastic toy that breaks mere moments after your child takes it out of the box. Poorly crafted code is no different — it frays at the edges much faster than you might expect.

Compare this to something you treasure for its quality. I once wore a pair of shoes almost daily for over a decade before they finally wore out. They were a bit more expensive than other shoes but their quality was undeniable, and I saved money in the long run. What did I do when the time finally came to throw those shoes out? I bought an identical pair because I knew they’d last me another decade.

The same principle applies to code. High-quality input not only produces longer-lasting output, it also saves money and builds customer loyalty. Meticulously refactoring and testing your code may take longer in the beginning, but the savings in technical debt and maintainability are well worth the extra effort.

3. Your Code Is Not Your Own

It’s important to take pride in your own work. It’s equally important to recognize that the code you write is not your own.

Overly clever tricks, hacks, and sleights of programmatic hand are only fun for the author.

This may seem like a bit of a paradox — after all, writing clean code requires you to have a stake in its quality. But good code is not really yours because it’s intended for consumption by others: your teammates, your customers, and even your future self. What happens when some future project maintainer (possibly even yourself) can’t understand why you’ve written something the way you have? They will no doubt have to spend precious time and mental energy deciphering the puzzle you’ve left for them.

What Is Clean Code?

Everyone has his or her own list of what makes for clean code — indeed, Martin’s book begins with a collection of definitions given by various software luminaries. My definitions, based on what I’ve learned in the book, are as follows:

1. Clean code is simple. Perhaps not simple in algorithmic or system-level complexity, but certainly simple in implementation. Overly clever tricks, hacks, and sleights of programmatic hand are only fun for the author and diminish the code’s long-term value. The same goes for long-winded code that takes forever to get to the point.
2. Clean code is readable. If the naming conventions, spacing, structure, and flow used in a program are not designed with the reader in mind, then that reader will almost certainly fail to understand the original author’s intent. Conventions about how to write readable code may seem dogmatic or lacking in expressiveness, but they help to make code communal rather than arcane.
3. Clean code is considerate. Code that does not do its best to inform future readers is code that does not respect their time. Clean code should be written with the assumption that future consumers are intelligent, thoughtful professionals (like you), and it should go out of its way to help them.
4. Clean code is tested. No one writes perfect, bug-free code on the first try. Even if it were possible to do so, there is no guarantee that perfect code won’t break later. Writing clean code means writing tested code. That way, future users can be confident they’re interacting with something that works. Moreover, when making changes, they will have a ready-made test suite to confirm that nothing broke.
5. Clean code is practiced. Writing clean code requires good muscle memory, just like playing an instrument, kicking a ball, or frying an egg. The best way to learn to write clean code — and, more importantly, retain the skill — is to do it all the time. When you’re at home working on a personal project, do it with clean code — even when no one else will ever see it.
6. Clean code is relentlessly refactored. Clean code should be in a constant state of refactoring. With a good test suite to back up your code, you can refactor it as much as you like and never worry about breakage.
7. Clean code is SOLID. Good code is as much about good design as it is about cleanliness. Following the SOLID principles is one way to ensure that your code is flexible, maintainable, and long-lasting.

If we take Martin’s book as a bible, the attributes for what makes “clean code” could multiply exponentially. But this list, culled from careful reading of Clean Code, is a good place to start. Adhering to these principles requires constant attention to detail and a willingness to acknowledge that what you wrote yesterday can still be improved today — even if it worked just fine before.

Although Clean Code contains a plethora of useful rules and best practices, it’s perhaps more useful for the mentality it imbues in its readers — that craftsmanship matters, effort today saves pain tomorrow, and code is never really your own. The more coders read it, the cleaner the world’s code will be, and all of our jobs will be easier.