Some years into my career, I struggled with colleagues writing sloppy code. I felt that they didn’t listen to me, when I gave them unsolicited advice. The optional code review mechanisms we set up were only eagerly used by people who cared about readability already.

So I started to refer to Clean Code when I needed an authority argument: if it’s in a book, you need a stronger argument against it, and unless you have a sound argument, your code is unclean.

I believe Clean Code mostly gets referenced by people who look for someone to agree with them on anything specific. The weaker opinions and examples become “junk DNA” for a selective quoter.

Back then, I often didn’t find a section where Clean Code agreed (or disagreed) with me. Mainly because I got influenced by functional programming, which the book does not address.

Once I decided to read the whole book, because I wanted to collect the good parts. I found myself only disagreeing in a small number of sections. But at the same time, I was completely unable to use his examples for anything.

I think this book serves a purpose. But I don’t think it addresses enough of what I have learned in the last ten years.

A simple example is naming things: the book does a fine job at giving good and bad examples. But I find that once you find the right vocabulary from your problem domain, and you want to choose among words that are all appropriate, thoughts like “is this at the right level of abstraction for this area of the code?” and “will this name also be meaningful in 6 months?” don’t get addressed. It’s the scenario where all your choices are okay, which name is better?

The book played a big role on my early career before I gained an authority and an experience of my own.