Key points from the best-selling coding book of all time
The Pragmatic Programmer was first published in 1999 and has since been named the best programming book of all time.
Authors Andy Hunt and David Thomas were among the original authors of the Agile Manifesto and have some serious credentials. The book has achieved an average rating of 4.3 on Goodreads from over 16,000 ratings. Suffice to say it’s one of those books every programmer should read.
In this review, I’m going to condense the book into five essential takeaways.
1. Don’t Repeat Yourself
Thomas coined the term “DRY” (or Don’t Repeat Yourself), one of the most useful rules for achieving high-quality code that has ever existed. The authors define the DRY principle as follows:
“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”
In the book, they give the following example as non-DRY code:
https://gist.github.com/jamiebullock/df5a06096d98246fce96d315c2128df9#file-print_balance_non_dry-rb
This is then refactored to the following DRY version:
https://gist.github.com/jamiebullock/6d102e89d41be8278b107d2062f78d41#file-print_balance_dry-rb
In the second fragment, the duplication of constants is removed. Equivalent lines are encapsulated into separate functions for printing, formatting, and reporting.
Interestingly, this actually results in more code. However, the result is more readable, maintainable, testable, and scalable. The DRY principle could be viewed as a means to achieve these other outcomes.
The authors emphasise that DRY is not only about avoiding literal code duplication. This is just a small part of the picture. They write:
“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.”
Duplication could be in representation, data structures, API design, or could even refer to duplicated effort between team members. The latter is a management issue discussed later in the book.
2. Mindset Is As Important as Knowledge
Unlike typical programming books, much of The Pragmatic Programmer is not about the code itself but rather the mindset and philosophy of the programmer.
A lot of what is discussed boils down to thinking about software development more generally as an end-to-end process rather than simply zooming in on the code. This makes sense. After all, programmers are not paid to write code but to produce working software!
Some important aspects of this mindset include:
- Taking responsibility for your work by not making excuses or passing blame when things go wrong.
- Writing software that’s “good enough.” This means not wasting time on things that are better than they need to be to make the product successful.
- Not ignoring technical debt. The authors use the analogy of broken windows for this:
“Don’t leave ‘broken windows’’ (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a ‘Not Implemented’ message, or substitute dummy data instead.”
I find this last point interesting. The authors are not saying code needs to be perfect but that it needs to be kept in a condition where it doesn’t deteriorate. A boarded-up window might not look great, but it prevents a whole bunch of other problems from building up over time.
3. Good Code Is Easy To Change
For me, possibly the most important takeaway from The Pragmatic Programmer is the Easy to Change(ETC) principle.
How often as programmers do we get UI changes from a designer or new requirements from customers that mean reimplementing existing functionality? Basically all the time. Yes, in an ideal world, we’d get a fully considered design up front that we can turn into perfectly crafted code, but the real world doesn’t work like that.
The Easy to Change principle solves this problem. It states that:
“Good Design Is Easier to Change Than Bad Design.”
The authors present this as a guiding value from which many other software engineering principles derive. Specifically, much of SOLID could be thought of as a special case of ETC.
“Why is decoupling good? Because by isolating concerns we make each easier to change.
Why is the single responsibility principle useful? Because a change in requirements is mirrored by a change in just one module.
Why is naming important? Because good names make code easier to read, and you have to read it to change it.”
If you write code with changeability in mind, then next time a designer revises the layout, life will be much easier!
4. Choose Great Tools and Become Fluent With Them
Joel Spolsky famously wrote that programmers should have “the best tools money can buy” in order to be fully productive. The Pragmatic Programmer aligns with this notion and has an entire chapter dedicated to tools.
“Tools amplify your talent.”
I must admit, I’ve become so obsessed with finding the absolute best tools that some of this chapter felt a bit obvious to me, but it was reassuring to have my assumptions reaffirmed.
The key takeaways are:
- Keep knowledge in plain text. According to the authors, this means text “understandable to humans.” This includes HTML, JSON, etc. The reasoning is that it’s more sustainable than binary formats and easier to manipulate with scripts and other software.
- Always use version control. The authors argue that version control should be used for any project, even when working only on your local computer.
- Become fluent with your tools.It’s tempting as a developer to constantly keep evaluating new tools and switching between them. Whilst this can have some value, it’s often better to become highly fluent with the tools you already have.
5. Agile Is Probably Not What You Think It Is
Both authors of The Pragmatic Programmer were involved in writing the original Agile Manifesto. I was therefore expecting a chapter on a favoured agile methodology — SCRUM or maybe Kanban. But there was no such thing. In fact, they actively criticise rigid methodologies and their associated certifications:
“Many certification programs are actually even worse […]: they are predicated on the student being able to memorize and follow the rules. But that’s not what you want. You need the ability to see beyond the existing rules and exploit possibilities for advantage. That’s a very different mindset from ‘but Scrum/Lean/Kanban/XP/agile does it this way…’ and so on.”
Instead, they suggest that developers take the best pieces from a range of methodologies and adapt them for use, advocating what they call The Essence of Agility.
What this means in practice is there can never be an “agile process” because, by definition, being agile is about “responding to change.” According to the authors, project management decisions should always be contextual, depending on your company, the nature of the team, and many other factors. No pre-defined process can take account of all this.
So what does this mean in practice? How can projects be managed? The Pragmatic Programmer provides three brilliant and universal steps:
- Work out where you are.
- Make the smallest meaningful step towards where you want to be.
- Evaluate where you end up and fix anything you broke.
They suggest repeating these steps until you’re done and using them recursively at every level of everything you do.
Conclusion
As you will have gathered from this review, The Pragmatic Programmer isn’t really a book about programming. It’s a book about building working software. This requires many other skills besides writing code.
Going into every detail is beyond the scope of this article, but there is also excellent advice on:
- Estimating
- Requirements analysis
- Refactoring
- Testing
- Prototyping and many aspects of coding
If I have one minor criticism, it’s that the book doesn’t have one central theme about what it means to be “pragmatic.” It feels more like a long list of aphorisms woven together with supporting explanations. These are some world-class aphorisms, though, and overall this book is essential reading for any developer.
