The Pragmatic Programmer: 20th Anniversary Edition
The Pragmatic Programmer: From Journeyman to Master by Dave Thomas and Andrew Hunt was given to me as a gift after an internship. The book gave me invaluable advice as I started out in my career as a professional software engineer. Re-reading it a decade later, I thought the general advice still held up well, but it made references to technologies such as CORBA that are no longer used and felt dated as a result. The authors agreed and wrote a 20th anniversary edition that was updated for modern developers. A third of the book is brand-new material, covering subjects such as security and concurrency. The rest of the book has been extensively rewritten based on the authors’ experience putting these principles into practice. We discussed the 20th anniversary edition in my book club at work.
The book is meant for those just starting out in the world of professional software engineering. Many of the tips, such as Tip 28: Always Use Version Control will seem obvious to experienced hands. However, it can also be a guide for senior developers mentoring junior developers, putting actionable advice into words. The book is also valuable to those who lack a formal CS education; it explains things like big-O notation and where to learn more about these subjects. I think that any software engineer will get one or two things out of this book, though it’s most valuable for beginners.
One of the things I appreciate about the book is that they talk about applying the principles not only to software engineering but to writing the book as well. The book was originally written in troff and later converted to LaTeX. For example, to illustrate Tip 29: Write Code That Writes Code they wrote a program to convert troff markup to LaTeX. In the 20th anniversary edition, they talk about their efforts to use parallelism to speed up the book build process and how it led to surprising bugs.
Perhaps the best thing about the book is that the authors summarize their points into short tips highlighted throughout the book. The authors helpfully attach these tips to a card attached to the physical book. This makes it easy to remember the principles espoused in the book and to refer to them later. I think this is a feature that more books should include, especially managerial or technical books.
Chapter 1: A Pragmatic Philosophy
The first chapter is less about coding and more about the general principles a pragmatic programmer follows. Most of all, it’s about taking responsibility for your work. The first tip of the chapter is Tip 3: You Have Agency: if you don’t like something, you can be a catalyst for change. Or you can change organizations if change isn’t happening. The most important tip of the chapter to me is Tip 4: Provide Options, Don’t Make Lame Excuses. In this section, they discuss taking responsibility for the commitments you make and having a contingency plan for things outside your control. If you don’t meet the commitment, provide solutions to fix the problems. Don’t tell your boss, “The cat ate my source code.”
Software rots over time without efforts to fix it. The authors talk about broken windows policing, the theory that minor problems such as a single broken window give people the psychological safety to commit larger crimes. Regardless of whether broken windows policing is actually true, the metaphor applies to software. This leads to Tip 5: Don’t Live with Broken Windows: If you see a broken window in your software, make an effort to fix it, even if it’s only a minor effort to board it up. This may seem impractical if your project already has a lot of broken windows, but this tip helps you avoid creating such an environment in the first place. In my experience, it works: when we set up a new project at work, we made a commitment to use git commit hooks to enforce coding standards. This made each of us more reluctant to compromise on software to begin with, and all of the code was a good example to copy from.
A pragmatic programmer is always learning, and learns things outside their specialty; they are a jack of all trades. Even if they are a specialist in their current role, they invest regularly in a broad knowledge portfolio. In addition to software skills, people skills are important as well. The section “Communicate!” shows how to effectively communicate your ideas, such as how to present, what to say, and how pick the right time. In the words of Tip 11: English is Just Another Programming Language. If you don’t have an answer to an email immediately, respond with an acknowledgment and that you’ll get back to them later - nobody wants to be talking to a void. Don’t be afraid to reach out for help if you need it; that’s what your colleagues are there for, after all. And don’t neglect documentation! Make it an integral part of the development process, not an afterthought.
Finally, the principles in this book are not iron-clad: you must consider the tradeoffs between different values and make the right decision for your project. Your software does not need to be perfect. When working on software, involve your users in deciding what quality issues are acceptable in return for getting it out faster. After all, if you wait a year to ship the perfect version, their requirements will change anyways. As Tip 8 says: Make Quality a Requirements Issue.
... continue reading