Blog‎ > ‎

The Pragmatic Programmer Review

posted Nov 23, 2011, 7:23 AM by Gerardo Sánchez   [ updated Dec 15, 2011, 2:00 PM by Victor Reina ]

The Pragmatic Programmer: from journeyman to master.


When you’re a developer, part of your education and needs is reading books inside this topic. One of the best books for a programmer is this: The Pragmatic Programmer. At first, when I saw it, I thought “This book is so long… it must be boring” but surprisingly it wasn’t. Since the first page, the book is friendly, understandable and entertaining.


The Pragmatic Programmer was written by Andrew Hunt and David Thomas, and in this book they convert the concept of programming into a craft. In the art of crafting, there are three basic categories: apprentice, journeyman and master. Anyone can benefit from this book, but, in my opinion, if a beginner (someone with near-zero experience in programming) reads this book, it’s a little confusing for them. They could get scared and discouraged when they discover how much research and self-learning they have to do by themselves.


Its structure is given in 8 chapters, with a total of 46 sections. A nice thing in this book is the metaphors. The authors usually give us a lot of nice examples to fully understand the confusing concepts. For example, they tell us the story of the stone soup (http://en.wikipedia.org/wiki/Stone_soup) and link it with the actions we have to do in order to make people support our project. I really liked the idea of the metaphors, because it’s a new point of view of the concept we’re trying to learn.


We can also find several useful exercises and challenges which we can implement in our own projects. That exercises can contain practices, technical questions or some questions to make us think about what we’re doing well and what we’re doing wrong.


While we read the book, we discover some useful tips the authors put there for us. They’re like key words to remember the concept you learned on that section. These are one of the best I found:

  • Don’t leave broken windows: fix bad designs, wrong decisions, and poor code when you see them. If you leave broken windows on a building, there will be graffiti and then garbage on the street, and finally the whole neighborhood is devaluated. The same happens in software; if you leave some hidden errors, there will be more and more over time.
  • DRY – Don’t repeat yourself: every piece of knowledge must have a single, unambiguous, authoritative representation within a system. You have to avoid duplication every time. There are four types of duplication: imposed, inadverted, impatient, interdeveloper.
  • Design to test: start thinking about testing before you write a line of code. It’s better for us to keep testing in mind every time we’re programming. If you write your code thinking about testing, you’ll make it better and easier to test. We have to avoid creating a “time bomb”.
  • Find bugs once: once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on. No matter how much the developer complains and says “Oh, that will never happen again”, the tests should be modified for that particular bug from then on.

I’m going to give a little description for each chapter from the book:


  • Chapter 1: a pragmatic philosophy. In this chapter, the programmer will learn the attitudes of a pragmatic programmer, like being open to new challenges and changes, communicate with others, create your knowledge portfolio or being responsible.
  • Chapter 2: a pragmatic approach. Here we can find information for decision making, orthogonality, duplication and nice tips about creating prototypes.
  • Chapter 3: the basic tools. This chapter shows us the tools needed by a programmer to master. The authors write about plain text, source code control and debugging. They recommend us to have one text editor for everything (programming, documentation, sending e-mails), but in some places the environment needs the employees to have different places to work on different things.
  • Chapter 4: pragmatic paranoia. In chapter 4, we will learn how to find and fix errors in software which seemed perfect in a first look. Finding bugs in the first look is a nice strategy to fix them and minimize their effect as soon as possible. Then we learn about how to use asserts and exceptions in our main or future project. In my opinion, this chapter is very useful for those who have difficult to find and fix bugs in a code.
  • Chapter 5: bend, or break. Here we learn techniques which will help us to program a more maintainable and modifiable code. This can be achieved by using, for example, the Law of Demeter for functions. This law states that any method of an object should call only methods belonging to:
    • Itself
    • Any parameters that were passed in to the method
    • Any objects it created
    • Any directly held component objects.
  • The authors’ recommendation is the use of metadata instead of hard coding configurations, using blackboards and handling events.
  • Chapter 6: while you are coding. Don’t program mechanically, just to make source code based on a detailed design. You have to think in other factors too, like the future testing. In this chapter we can find the tip mentioned above about testing. Mindlessly translating a design into a code is a factor in creating poorly written software.
  • Chapter 7: before the project. We need to put attention on the requirements before we start programming. The full understanding of the requirements is the key to a successful code. You can’t start the project until you’re totally ready to do that, this is, with the required previous documentation and the development methodologies.
  •  Chapter 8: pragmatic projects. Jumps from the pragmatic thinking of one person, into the pragmatic thinking of a whole team. In this chapter, the authors show us topics which can carry us to the best success or the worst failure of the project. This topics include how does the pragmatic teams should work, the ruthless testing attitude in a team, and how to manage the customer’s expectations.

In general, I learned a lot from this book. I liked the fact that any programmer (no matter which language he/she uses) can read it and learn new approaches, methodologies and strategies to be better day by day. This book is a must-read to any programmer who wants to improve his/her own programming thinking.

Comments