The Pragmatic Programmer Book 2nd Edition Differences
What’s the difference between The Pragmatic Programmer 2000 and 2020? If you own the first edition, is the new Pragmatic programmer 20th anniversary edition even worth buying?
In this article, I am giving you the tools to answer that question: this article contains the first three chapters of the significant and (and perhaps some not-so-significant) differences between the original The Pragmatic Programmer and the recently-released Pragmatic programmer 20th anniversary edition.
Overview
20th-anniversary edition cover
The differences between the original and the 20th-anniversary edition The Pragmatic Programmer by Dave Thomas and Andy Hunt are as you might expect: much of it is the same, with words changed here and there for a modern context, but also whole sections have been completely reworked — with a handful of completely-new topics.
Original edition cover
Famous, common sense topics, such as Stone Soup and Boiled Frogs remain nearly untouched.
While technical topics, such as Version Control, changed from Source Code Control, have gotten a major update.
The authors have also gotten less prescriptive over the years. The famous topic, DRY — The Evils of Duplication, has been changed to clarify that certain reuse is warranted. Their topic, Power Editing, has gone away from prescribing mastery of only one text editor.
Small tweaks throughout give more nods toward learning soft and nontechnical skills.
But ultimately, The Pragmatic Programmer is still the classic from 20 years ago.
In an interview about the new edition, co-author Dave Hunt said:
When you write a book that’s so well-received, doing a second version — the only place you can go is down. I would rather not go too far down.
I am pleased to report that the authors have stuck whole-heartedly to the spirit of the original and crafted a worthy update. But don’t take my word for it.
You might love your original edition of the book, concerned you may be disappointed by the new version. Will you get any new wisdom from reading the new edition anyway?
See the following chapter comparisons for your much-sought-after answers. Currently, I have recorded only the first three chapter differences (because I ran out of time and patience), but feel free to contact me on Twitter or by email if you would appreciate a complete-book comparison.
Preface
New foreword by Saron Yitbarek, founder & CEO of CodeNewbie. What Saron covers in the foreword is many of the themes in her podcast episode with The Pragmatic Programmer authors. The podcast episode is Why you should read the new edition of the Pragmatic Programmer.
New preface before the original preface to the first edition. Key quote from the new edition:
”[W]e had to make a decision. We could go through and update the technologies we reference and call it a day. Or we could reexamine the assumptions behind the practices we recommended in the light of an additional two decades’ worth of experience.
”In the end, we did both.”
Chapter 1: A Pragmatic Philosophy
Introduction has a new first sentence: “This book is about you.”
New paragraph introducing the new topic It’s Your Life, which goes “Make no mistake, it is your career, …”
New Topic 1: It’s Your Life
Developers the authors have spoken to feel that they have stagnated, feel like technology is passing them by, or want certain conditions that they can’t seem to get like to work from home. But this topic is to send the message that they can change it!
Software development is one of the most in demand, best paid, and geographically flexible professions, which means there is an abundance of opportunity to create the situation you want.
Even though there is an abundance of opportunity, developers find themselves psychologically stuck and often wonder how to be a successful software developer.
New tip: You Have Agency, which includes these key points:
If you hate your work environment, try to fix it or leave.
Invest in yourself, and do it off the clock.
Have a need like to work remotely? Ask!
If you hear ‘no’, you can find a way
Be proactive and take advantage of the abundance of opportunities out there.
Topic 2: The Cat Ate My Source Code
New Section: Team Trust, which says “In a healthy environment based on trust, you can safely speak your mind, present your ideas, and rely on your team members …”
New paragraph to Tip 4: Provide Options, Don’t make Lame Excuses, which says “Don’t be afraid to ask, or to admit that you need help.”
New challenge at end of chapter, which goes “When you find yourself saying, ‘I don’t know,’ be sure to follow up with ‘—but I’ll find out. …”
Topic 3: Software Entropy
Acknowledges the term “technical debt” as a term for entropy.
Concludes the introduction by bringing the metaphor of broken windows back to software rather than continue to talk about cleanup in inner cities.
First, Do No Harm section now has more tie-ins to software development.
Adds concluding line, “Just tell yourself, ‘No broken windows.’"
Topic 4: Stone Soup and Boiled Frogs
Make clear that the frog story is just a story by saying “fabled frog” and putting actors in the story in parenthesis, like “‘they’ say that if you take a frog and drop it in boiling water…"
New challenge: practice situational awareness
Topic 5: Good-Enough Software
Changed stating that many people would rather suffer to wait for the “multimedia version” to “shiny, bells-and-whistles version"
New challenge: “Consider the effect of modularization on the delivery of software. …"
Topic 6: Your Knowledge Portfolio
Under Building Your Portfolio: Diversify, a new line to also consider diversifying non-technical skills as well.
Under Building Your Portfolio: Buy low, sell high, instead of saying that those who learned Java are “now at the top of that field,” it is in past tense.
Under Goals: Learn at least one new language every year, new version says many free references are available for learning, full stop, whereas the old version says the references are available “on the Internet," which even includes a reference to learn more!
Under Goals: Read atleast one of the must read books for software engineers each month, it is modified from “each quarter” to “each month”. The new addition also acknowledges “short-form” resources online before going on to recommend long-form resources. What the pragmatic programmer book forgot to mention is you should sign up for the Books on Code newsletter below to develop habits of successful software developers & keep that motivation for technical reading.
Under Goals: Read nontechnical books, too, the new edition elaborates on what it means to not forget the “human side of the equation” and underscores the value of soft skills.
Under Goals: Take classes, the new addition acknowledges online courses and tech conferences.
Under Goals: Participate in local user groups and meetups, the “and meetups” is new as well as emphasizing not just going, but listening.
Under Goals: Stay current, the new edition recommends reading tech news online instead of magazines.
Goals: Get wired is removed from the new edition.
The section Care and Cultivation of Gurus is cut from the new edition, which talks about how to use the capital-I Internet to find experts!
The tip Critically Analyze What You Read and Hear is rewritten and greatly expanded with five new questions to ask yourself when thinking critically:
Ask the “Five Whys"
Who does this benefit?
What’s the context?
When or Where would this work?
Why is this a problem?
The challenge that goes “Start learning a new language this week” now recommends modern programming languages like Go, Rust, Swift, and Typescript.
Topic 7: Communicate!
New paragraph in chapter introduction of the pragmatic programmer book that begins “Treat English (or whatever your native tongue may be) as just another programming language. …"
New tip: English is Just Another Programming Language, which includes sections from the older edition, rearranged so that Know Your Audience swaps places with Know what You Want to Say.
The section titled E-Mail Communication is revised and renamed to Online Communication. Not much has changed. Even the tip “Don’t flame” is still included, but now with “don’t act like a troll” as well.
A new tip: It’s Both What You Say and the Way You Say It, with a section on embracing documentation.
A new tip: Build Documentation In, Don’t Bolt It On, which recommends adding comments to modules and exported functions especially, but not documenting every function, data structure, or type declaration.
In the Summary section, there’s a new bullet point: “Keep code and documentation together."
Chapter 2: A Pragmatic Approach
New paragraph introducing the new topic, The Essence of Good Design, which goes “The first and maybe most important topic gets to the heart of software development …”
New Topic 8: The Essence of Good Design
There’s an overwhelming amount of information about there about good design, but the core truth is hard to find. The authors of the pragmatic programmer book state, “we’d like to make amends by explaining something that only became apparent to us fairly recently.”
New tip: Good Design Is Easier to Change Than Bad Design, which includes the following points:
“A thing is well designed if it adapts to the people who use it.”
Believe in the Easier to Change (ETC) principle. Making the ETC argument for good design always works. For example, decoupling is good because of ETC. Or naming conventions matter, because ETC.
New section, ETC Is a Value, Not a Rule, which states that ETC is a guide. ETC is complex because many different things can change over time, and ultimately, these things are judgement calls. To use ETC as a guideline, the section recommends two things:
Make what you write replaceable.
Find ways to give yourself feedback.
Three new challenges. For example, “Think about a design principle you use regularly. Is it intended to make things easy-to-change?”
Topic 9: DRY — The Evils of Duplication
Besides the introduction, the section Interdeveloper Duplication, and the two tips, everything in this section has been rewritten and expanded with the intention of clearing up the misunderstanding in the original that not all duplication is bad.
Removed sections from the original:
How Does Duplication Arise?
Imposed Duplication
Inadvertent Duplication
Impatient Duplication
New, added sections:
Duplication in Code
Not All Code Duplication Is Knowledge Duplication
Duplication in Documentation
DRY Violations in Data
Representational Duplication
Duplication Across Internal APIs
Duplication Across External APIs
Duplication with Data Sources
Many code examples, now written in a modern language.
Topic 10: Orthogonality
Under What Is Orthogonality?, there is a new 3D diagram! The accompanying paragraph has changed to match it.
The section Project Teams is removed.
Under Design, new diagram that is mostly the same, except instead of “Operating System” for the bottom layer, it’s “Container Services.”
Toolkits and Libraries is paired down the the original and does not include an example.
Under Documentation, the authors recommend using Markdown.
Two new exercises that are similar but with a more modern context.
Topic 11: Reversibility
Under the section Reversibility, the example is no longer a “client-server model” but changed a web app.
Under Flexible Architectures, paragraphs about old technologies have been stripped out and replaced with a list of “‘best practice’ server-side architectures,” which include cloud-based virtual machines or containers running services and applications. Then a line is included, “How can you plan for this kind of architectural volatility? You can’t.”
New tip: Forgo Following Fads.
Topic 12: Tracer Bullets
Introduction is revised away from a gun metaphor to be more hypothetical.
Under Use Tracer Bullets to Find the Target, new paragraphs and diagram, which shows the path features make through architectural layers. New text describes tracer bullets as being more important than ever given today’s complex landscape.
Topic 13: Prototypes and Post-it Notes
Under How to Use Prototypes, updated technology recommendations. Also, a new recommendation to “prototype user interfaces, use a tool that lets you focus on the appearance and/or interactions without worrying about code or markup.”
Topic 14: Domain Languages
Topic introduction is significantly shortened to only the first couple paragraphs before moving on to the tip, which is Program Close to the Problem Domain. The description underneath the tip is also cut from the pragmatic programmer 20th anniversary edition.
The following sections are removed:
Domain-Specific Errors
Implementing a Mini-Language
Data Languages and Imperative Languages
Stand-Alone and Embedded Languages
Easy Development or Easy Maintenance?
The following sections are added:
Some Real-World Domain Languages
RSpec
Cucumber
Phoenix Routes
Ansible
Characteristics of Domain Languages
Trade-Offs Between Internal and External Languages
An Internal Domain Language on the Cheap
Replaced and modernized examples. For example, instead of “Implement the time parser using Perl,” it says “Implement the time parser using a scripting language and regular expressions.”
Topic 15: Estimating
Opening example is modernized. Original states, “How long will it take to send War and Peace over a 56k modem line?” New version states, “The Library of Congress in Washington, DC, currently has about 75 terabytes of digital information online. Quick! How long will it take to send all that information over a 1Gbps network?” Instead of sending a backup over “an ISDN line to the central site,” it’s a “network connection to S3.”
How Accurate Is Accurate Enough is reduced in size, removing examples in the original such as “If your grandmother asks when you will arrive, she’s probably wondering whether to make you lunch or dinner. …” The section about estimating in units remains with the duration table.
Estimating Project Schedules is significantly expanded with two new sub-sections.
Chapter 3: The Basic Tools
Changes the topic Source Code Control to Version Control. Original said to use source control “even for things such as our personal address book!” whereas the new version says “even for personal things such as recipes or notes.”
The topic Code Generators is removed and replaced with a new topic, Engineering Daybooks, which includes its own introductory paragraph that goes “Finally, the palest ink is still better than the best memory. Keep track of your thoughts and your history, as we describe in Topic 22, Engineering Daybooks.”
Topic 16: The Power of Plain Text
What Is Plain Text is revised and more concise, starting with a human-readable example instead of a purposeful indecipherable example. The language here is also more casual, like it knows the reader already has an understanding for plain text. In the new version, they add a cheeky statement that the source of the book is in plain text “much to the chagrin of the publisher, who wants us to use a word processor.”
The Drawbacks section is removed. The original drawbacks, which had to do with concerns about storage, are no longer an issue.
The Power of Text calls out that plain text can still be highly structured, such as in HTML, JSON, and YAML.
Under The Unix Philosophy, includes the point about plain text being easier to search with
grep.
Topic 17: Shell Games
Introduction is reduced, with all examples removed before the tip, Use the Power of Command Shells.
Shell Utilities and Windows Systems is removed and replaced with A Shell of Your Own, which talks about customizing your shell. For example, with color schemes or aliases.
Topic 18: Power Editing
Power Editing had a complete overhaul. All sections are removed and replaced with the following sections:
What Does “Fluent” Mean?
Moving Toward Fluency
Growing Your Editor
New paragraph in the introduction: “In the first edition of the pragmatic programmer book we recommended using a single editor for everything: code, documentation, memos, system administration, and so on. We’ve softened that position a little. We’re happy for you to use as many editors as you want. We’d just like you to be working toward fluency in each.”
Removed tip Use a Single Editor Well and replaced with Achieve Editor Fluency, making the case that editor fluency means far more efficiency and less cognitive load thinking about the mechanics of editing.
Four completely-new challenges, including “No more autorepeat” and “Lose the mouse”.
Topic 19: Version Control
Introduction is significantly cut down. The description of version control is moved into a new section, It Starts at the Source.
New aside sections, Shared Directories Are NOT Version Control and A Thought Experiment, which describes a disaster that’s easily recoverable with version control.
The following sections are removed:
Source Code Control and Builds
But My Team Isn’t Using Source Code Control
Source Code Control Products
The following sections are added:
Branching Out, which discusses the benefits of branches.
Version Control as a Project Hub, which describes what to look for in a repository system for projects, such as “security and access control.”
Four new challenges, which includes learning how to roll back changes, recover your computer, and consciously exploring the features of your version control system.
Topic 20: Debugging
Removed quote: “The easiest person to deceive is one’s self,” by Edward Bulwer-Lytton.
Reproducing Bugs is renamed from Bug Reproduction and is removed from an aside section into the text’s main body.
New tips: Failing Test Before Fixing Code and Read the Damn Error Message
Tracing is renamed to Logging and/or Tracing.
Aside section Corrupt Variables? Check Their Neighborhood is removed.
The following sections are new additions:
Coder in a Strange Land
Bad Results
Sensitivity to Input Values
Regressions Across Releases
The Binary Chop, which describes a tip of splitting the dataset into two and seeing if the error occurs when feeding one or the other through the app.
Topic 21: Text Manipulation
In introduction, recommends modern text manipulation languages.
Section under the tip Learn a Text Manipulation Language is completely reworked.
The following sections have been removed:
Database schema maintenance
Java property access
Test data generation
Book writing
C to Object Pascal interface
Generating Web documentation
While the following new sections are added in its place:
Building the Book
Code inclusion and highlighting
Website update
Including equations
Index generation
Three exercises that are completely new. For example, “Your team initially chose to use camelCase names for variables, but then changed their collective mind and switched to snake_case. Write a script that scans all the source files for camelCase names and reports on them.”
New Topic 22: Engineering Daybooks
This short topic advocates for keeping a “daybook,” which the topic describes as a place “to take notes in meetings, to jot down what we’re working on, to note variable values when debugging, to leave reminders where we put things, to record wild ideas, and sometimes just to doodle.”
If you liked this article, please share this article with the programmers in your life and apprise them of the must read books for software engineers, particularly those who love (or are going to soon love) The Pragmatic Programmer and are keen to adopt the habits of successful software developers.
If you want to know how to be a successful software developer, form the habits of successful software developers and heed the Pragmatic life by always reading new and varied technical books, subscribe to the Books on Code email newsletter below. We are thrilled to have you in our community.
Thank you very much for reading, and I will see you in the next article. ✌️😊