The Pragmatic Programmer: From Journeyman to Master

Andrew Hunt, David Thomas (1999)
Review date: February 2009

This book is written in form a series of short stories treating no less than 46 topics related to software construction and software projects. Its simple goal is to make people better programmers. Each story is roughly 2-10 pages long and explains a phenomenon or practice, gives the authors' opinion on them, and finishes with tips and exercises. The stories can be read in isolation, but are heavily cross referenced.

This book's richness comes from the number of stories, the insights therein, and mentioning of universal principles such as orthogonality, the DRY principle and the Law of the Demeter.

To give the reader a teaser, this is how the stories are presented (they are grouped into sections):

  1. A pragmatic philosophy
  2. A pragmatic approach
  3. The basic tools
  4. Pragmatic paranoia
  5. Bend, or break
  6. While you are coding
  7. Before the project
  8. Pragmatic projects
Each section contains 5-6 stories with colorful names like "Evil wizards", "Solving impossible puzzles", and "The specification trap".


First time I read this book was pretty much ten years ago! It was course literature in a course on programming paradigms, and we were told to read the book without further explanations. At that time many of the practices mentioned were unheard of to me, and every chapter came as a great revelation.

When reading this book now, I experienced less drama, though I still got the impression that the authors really know their trade and succeed in communicating it. Upon a second reading some of the guidelines and tips seem "obvious" (they didn't seem like that ten years ago though), some of them feel awkward, and a few of them have become a bit aged. Fortunately the majority are still valid and insightful, and the book still deserves to be the often-quoted classic it is.

As usual, I'm gong to pick some things that caught my attention.

"Flexible architecture" is one of the sections I don't agree with. The essence of this story is that we should keep open architectures that are future-proof because they are generalized. This is pretty much the opposite of agile methodologies and TDD, and very 80's in general. Thumbs down.

Tracer bullets are an interesting concept. As opposed to prototypes, they aim at fully implementing a certain subset of functionality, but properly. The authors make a big point of of this. Is that good or bad?

Time Estimation is a tough area that's treated sort of half-heartedly. Although there's nothing in this section that's wrong, it could have been given more space. Instead, it's summarized on one page.

The story promoting the Law of the Demeter is, in my opinion, one of the most controversial parts of the book. In short, the Law of the Demeter states that if object b holds a reference to object of type C, that has method c', then the caller of object b should not be allowed to do b.getC().c'. Instead, b should provide an operation that invokes c'. The authors do point out that this implies that b will act as a general contractor, which is a bad thing, but the benefit of objects only knowing about their direct references obviously outweigh that. Personally I don't agree, but I've seen people abuse designs that didn't follow this principle by building spaghetti code that reminds of something that was spawned directly from hell.

Throughout the book, it becomes quite obvious that the authors like meta-driven applications. This seems logical and appealing: You put your rules and definitions in some file(s), and run a program/script to generate code, database definitions, and maybe even documentation from that central place. No duplication, hooray. I've been doing this kind of programming around 2000, thinking of myself as extremely clever when I used my complicated data structures to generate various things, however, maintaining the code for processing the meta data wasn't without problems. Meta programming, sure, but spend much time writing proper code for processing the meta data, otherwise you're in for a maintenance nightmare.

Well, that were the things that annoyed me. Not many, and not uncontroversial. In this light, let's remember that this book promotes so many good practices, of which few deserve dissecting. However, some deserve special emphasis, like one of the first things discussed in the debugging topic: before debugging, make sure that you have no warnings. Too many people don't care about warnings. They are there for a good reason, and not to harass us.

Rubber ducking is another practice that I haven't tried, but sincerely believe will work. It's the verbal equivalent to writing something down. Whenever you get stuck, try explaining your problem to a rubber duck! If you don't like ducks, pick another cute plastic object.

If you've read my other reviews, you might have noticed that I like discussing metaphors for software construction. Here I'm given another opportunity! In the refactoring chapter, the authors equate software construction with gardening, which isn't quite as scientific an repeatable as building construction. I light of this metaphor, trimming the software the way you do with refactoring becomes quite natural.

Towards the end of the book we find a small section on maintaining glossaries. These are supposed to hold definitions of commonly used terms like "client", "paid invoice", and alike. While this topic is rather lightly treated, I've witnessed the lack of the glossary, or a similar document lead to lots of frustration and project failures.

Finally, I have to give the authors credit for early insights on self-organizing teams. While promoting the XP style self-organizing, magic-doing teams, pretty much ahead of the hype, the authors recognized the need of forming such teams from responsible developers being surrounded by strong project management. The opposite is "a recipe for disaster". Who agrees?

I've tried to discuss good things and bad things, but the recommendation is simple: buy, read, enjoy.

Who should read this book

Primarily, this book is intended for beginners. It covers a lot of ground and will aid people new to software development in setting many good practices. Experienced professionals may have a glance too sometimes to get a good summary and overview of practices they should adhere to.


  • 2015-09-29

    It's been almost one and a half year since I reviwed a book! I've been too absorbed by Writing my own. Anyway, I'm back with Jeff Patton's relatively...
  • 2014-01-04

    New category! Performance! Reviewed The Every Computer Performance Book. Check it out!
  • 2013-09-10

    Reviewed a book that' slightly less technical, but much more fun to read. It's I.T. Confidential.
  • 2013-08-13

    Reviewed yet another book on Visual Studio 2012 and TFS. I also created a "Microsoft" category and moved the other TFS book there from the "Tools"...
  • 2013-08-05

    Updated the FAQ. Included information about getting a book reviewed.