Author Kevlin Henney & other
Genres Software
Rating đź’–đź’–đź’–đź’–đź–¤
Date Finished 21/03/2026

🚀 The Book in 3 Sentences

  1. To be a good programmer strive to always learn, improve and master your tools.
  2. To be a good programmer strive to be a good collaborator and treat others well.
  3. Sometimes there is no correct answer. Software is both technical and subjective. Beware of people who try to convince you of the opposite.

🎨 Impressions

How I Discovered It

This book is one that I discovered by myself in my quest to bridge the gap between Software Engineering and the other “more serious” Engineering practices. I wanted to know what other developers had to say on the matter and confront those insights with my own.

Who Should Read It?

Hard to tell. If you are a Junior some of the tips won’t make sense without the context that would allow you to organically learn them. If you are a Senior you will probably already know all of the tips, either from direct experience, or from having read about them somewhere else, even if you don’t apply all the tips all the time.

It’s still worth skimming for juniors. Seniors can skip it unless you want validation.

🍀 How the Book Changed Me

I read the book more as a way to feel “what’s out there” in the programming field, rather than to learn anything new. And I can happily say that most well intentioned programmers will converge to a body of common knowledge. I’m also happy to confirm that I’m not the only one that feels Software Engineering lacks in the “Engineering” department compared to other technical professions and we should collectively try to bridge the gap.

✍ Favourite Chapters

  1. “The Boy Scout Rule” and “The Professional Programmer” by Robert C. Martin
  2. “Continuous Learning” by Clint Shank and “Do Lots of Deliberate Practice” by Jon Jagger
  3. “The Guru Myth” by Ryan Brush

đź“’ Summary + Notes

There are a lot of interesting tips coming from the most disparate backgrounds, but each “Thing” can be categorized into one of the following:

  • Mastery of the tools: or “the tools for writing software”. Study and master your tools, understand why and how things work and why they sometimes don’t work. Don’t dispel complexity as magic, computers are just memory and everything has an explanation.
  • Mastery of the process: or “the skill of not writing software”. From requirement gathering, interviewing customers, interacting with other developers, and everything else in between that is not strictly writing software. This touches the most disciplines because writing software is multi-disciplinary and it’s only the tip of the iceberg.
  • Mastery of the art: this is where all the discussion about paradigms and programming techniques reside. Writing software is technical, but it’s also like art, and like art, lots of things are subjective and have no correct answer, so beware of gurus that tell you otherwise. Every choice that can’t be empirically demonstrated as superior (and even some of those that are) have trade-offs.
  • Professionalism: Treat your customers, colleagues, testers and users with respect. Assume other programmers are smart.

Every discussion ever done on writing software can be categorized in one of those 4 categories. Every method, paradigm, language, IDE vs CLI, tabs vs whitespaces, OOP vs imperative, Clean Code vs Performance-Awareness.

The blessing, and curse, of software is that it’s soft. It’s easy to change so that hardware doesn’t have to. That’s all there is to it.

It’s a blessing because it means less work for the hardware guys. It’s a curse because it means countless hours were spent, and will be spent, arguing about frivolous things that have no correct answer. And even if those discussions brought forth a valid argument, there is always the human factor involved.