The Pragmatic Programmer, 20th Anniversary Edition
Every developer owes it to themselves to read this book
Sometimes you come across something that resonates with you on a totally new level. For me, back in the year 2000, this was the book “The Pragmatic Programmer” by Dave Thomas and Andy Hunt.
This book was a significant influence on me in my career as a software developer. When, in May 2019, Addison Wesley published a new edition, “The Pragmatic Programmer, 20th Anniversary Edition”, I decided to re-read it.
About the Book
Dave Thomas and Andy Hunt wrote the first Pragmatic Programmer book in 1999. Their original idea was to write a short white paper, containing all the lessons they had learned working with their clients.
This white paper grew into “The Pragmatic Programmer.”
Twenty years on, this new edition re-examines what it means to be a modern developer in 2020. They’ve updated all the technology examples and added 30% of new content.
The book is for people who want to become more effective and productive programmers. Andy and Dave have divided the book into ten chapters, with 53 topics, 100 tips, and 33 exercises.
The two main questions the book tackles are:
- What is a pragmatic programmer?
- How can you become a pragmatic programmer?
Dave and Andy, describe a pragmatic programmer as someone who:
thinks beyond the immediate problem, placing it in its larger context and seeking out the bigger picture. After all, without this larger context, how can you be pragmatic? How can you make intelligent compromises and informed decisions?
The 53 topics in the book explain what you can do to do become more effective. Let‘s look at two examples from the book: “Software Entropy” and “The Essence of Good Design.”
Software Entropy
Dave and Andy describe that once you allow software entropy or technical debt into your system, it can spread uncontrollably. They continue to investigate why specific projects fall into ruin and decay, while even more complicated projects manage to come out well.
They explain that the broken windows theory applies to software and mention the following tip:
Don’t leave “broken windows’’ (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered.
The Essence of Good Design
When I design a solution, I always question how good it is. According to Dave and Andy, it’s simple: “Good Design Is Easier to Change Than Bad Design.”
They describe the Easier To Change (ETC) principle and state that all other principles are special cases of ETC. Decoupling, the single responsibility principle, and naming are all special cases of ETC.
I use the ETC principle a lot in my work. If I have to choose between two options, I prefer the one that makes the solution easier to change.
The Rest of the Book
The rest of the book is filled with the other 51 topics. One funny thing to mention is that once you start reading this book, I guarantee you’ll recognize the phrases of your co-workers. A lot of developers have read this book!
Tell Us About Yourself
When I read the original book back in 2000, it clicked with me. All the tips and examples from the book were things that I’d encountered in my daily work.
Don’t Repeat Yourself (DRY) principle
Although I had already read the previous edition, the new one contained many new and exciting topics. Notably, the famous Don’t Repeat Yourself (DRY) principle.
I always thought I understood the DRY principle. You should not copy and paste source code but instead create reusable functions, classes, or components. This prevents a maintenance nightmare.
The new edition still contains the DRY principle, but now the focus is on preventing the duplication of knowledge. Not copying and pasting code is a part of it, but it’s more than that.
DRY is about the duplication of knowledge, of intent. It’s about expressing the same thing in two different places, possibly in two totally different ways.
Here’s the acid test: when some single facet of the code has to change, do you find yourself making that change in multiple places, and in multiple different formats? Do you have to change code and documentation, or a database schema and a structure that holds it, or…? If so, your code isn’t DRY.
I have been a professional programmer for more than 20 years. I have worked on different sizes and types of projects.
If I had to recommend one book for new or experienced developers, this would be it. The original version resonated with me on so many levels.
Why Should We Read It?
Every developer owes it to themselves to read this book. The wisdom in it will help you over your whole development career.
The previous edition stood the test of time and stayed relevant for 20 years — so will this one.
It is an excellent gift for a developer — I have given away many copies. You can find it at the Pragmatic Bookshelf.
Thanks for reading.
