Jeff Bailey
Written by Jeff Bailey

Learning resources, opinions, and facts about technology.

A Pragmatic Programmer Book Review

Reading Time: 9.8 minutes
Listen to this post

A Pragmatic Programmer book review by Jeff Bailey

I really like this book. As a programmer that has been at it since the 20th century, this book codifies my experiences. As I read through the book, I find myself nodding my head and agreeing more often than not. It’s almost like reading daily affirmations that hammer instinctual best practices home like a nail gun.


The Pragmatic Programmer: From Journeyman to Master is a book about computer programming and software engineering, written by Andrew Hunt and David Thomas and published in October 1999. It is used as a textbook in related university courses.

The book does not present a systematic theory but rather a collection of tips to pragmatically improve the development process. The authors’ main qualities referred to as a pragmatic programmer, are being an early adopter, having fast adaptation, inquisitiveness, critical thinking, realism, and being a jack-of-all-trades.

Release Date: September 13, 2019

The Good

Several chapters stood out to me as golden signals that every programmer could benefit from. Here are some of the key takeaways for those of us with little time available.

Delight Your Users

Delight your users brings the most important aspect of programming to the forefront of your mind.

My favorite part of programming is seeing a happy look on someone’s face when using my creations. If I see any dismay, I am unsatisfied with my work and go back to the drawing board. Happy software users will inevitably lead to more sales, so a focus on making your users happy will never fail you as a software developer.

Delighting your users starts with gathering clear requirements. Knowing the business you serve and solving problems for them is the key to success. A business looks to you for suggestions on solving problems, so collecting information about their users’ problems will ground you in all of your work.

If you’re wondering why you’re writing software, always remember that solving problems people have is what it’s all about.

Tracer Bullets

Tracer bullets teach us that starting with the end in mind will set us up for success. In contrast to a proof of concept/prototype, the act of creating a tracer bullet to aid in the completion of your project ends with usable code. The idea is to create a skeleton that includes all the layers of your application yet provides a single piece of functionality.

As you are firing your tracer bullet, each layer is built with the bare minimum functionality required to reach your destination. Your destination might be displaying a user interface, exposing an API, or consuming a machine learning algorithm’s output. The sky’s the limit on the destination, and a tracer bullet will help you get there quickly so you can start delighting your users as soon as possible.

Don’t Outrun Your Headlights

Don’t outrun your headlights walks us through the perils of predictive programming and limiting your feedback loops.

Early in my career, I would get way ahead of myself. I would dive into the unknown unprepared and without a map. While this was a great approach for earning experience, it’s not great when you’re trying to deliver a project on time.

With more experience comes the feeling that you already know the outcome. Many programmers feel like they are a seer that can predict the future. It’s an easy trap to fall into, especially when you’ve had to rewrite software thanks to missing requirements.

The Pragmatic Programmer reminds us that we cannot predict the future. We can often predict what will happen in an hour or a few days, but beyond that, all we’ll see is the fog of the future.

Instead of attempting to predict the future, we can make our software easily replaceable. When we use software design patterns in our code, we prepare for the inevitable change coming our way. Instead of prediction, we lean on adaptation and secure our future without betting the farm on lengthy fortune-telling sessions.

Shared State Is Incorrect State

Share state is incorrect state walks us through the challenges of managing state.

Managing software state can be difficult, and managing a state with two cooks in the kitchen is even harder.

I used to be a cook in a past life. In any serious kitchen, each cook has their own line to work from. It contains all the ingredients and tools you need to cook the recipes on your menu. If two cooks are on the same line, it is necessary to have your own ingredients and tools set up to avoid breaking each other’s flow. If the state of the kitchen isn’t how you expect it, you’ll lose your flow, and problems will arise.

The software world mimics the real world, and we create separate independently managed states in or designs. The Actor Model is a great example whereby the state of independent yet connected systems works together cohesively.

This real-world example illustrates independent actors (email accounts) that communicate with each other but never change each other’s state. The state of your email box is entirely independent of the state of your friend’s email box. Imagine if deleting an email in your inbox deleted your friend’s email. It isn’t a pretty picture, and there are great reasons beyond user confusion to manage the state independently.

Some of the outcomes of unmanaged or improperly implemented state are as follows.

  • Unintentionally deleted files
  • Orphaned records in a database
  • Software crashes
  • Incorrectly charged customers

And the list goes on and on and on.

Managing state is an important part of software development. In the case of frameworks like Terraform, the state of your resources is a complex issue. Luckily some frameworks manage state for you and will keep your systems running without fail. You’ll want to leverage existing patterns and frameworks to manage the state for you in most cases. If you understand the problems a tool is solving, you can sleep easy at night knowing your state problems are solved.

The Bad

While not necessarily a bad thing, this book will not tell you how to do things. You’ll find examples used to illustrate a point, but don’t look for how to craft your composable enterprise architecture here. Instead, The Pragmatic Programmer is pragmatic and illustrates the what and the why of programming. If you’re still developing your software development philosophy, this book will provide plenty of fodder for that endeavor.

The Ugly

Personally, I don’t have anything ugly to say about this book. It’s telling that the only one-star review on Amazon complains about the smell of the book.

If that’s the worst thing about this book, you could do a lot worse.


I recommend all the books in my book reviews. My reviews are done for books recommended in most programming circles. However, here is my recommendation on which types of programmers can benefit from this book.

  • All Programmers Great & Small


The Pragmatic Programmer is a cornerstone book on my bookshelf that I enjoy rereading to regain perspective when facing difficult problems. As a result of a reread, my mind begins to clear, and the problems fade away. In most cases, I’ll reread a particular chapter then move on with my day. Since most of the chapters are small, it’s easy to do this as you pause between problems. I think you’ll find The Pragmatic Programmer to be that warm blanket you keep near your bed for those cold nights. I hope you enjoy it as much as I do!