The Pragmatic Programmer Review

This post is a review of the book The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and Dave Thomas

It may be having read a number of similarly scoped books recently, or sitting next to someone who raves about this book but I didn't learn as much as I expected from this book. As mentioned, I don't actually think this is down to the book not being full of useful information and insights, becasue it is, but rather because the content overlaps with many other books (many of which were actually written after this book).

The Pragmatic Programmer has a very practical focus, most of the content concerns writing code from a  variety of perspectives, from architectural, through functions, down to line to line coding. The coverage is very solid and feels quite complete in it's covering of many areas, though as the Authors say themselves they don't go into deep detail in every area.

The things I found most interesting or new from the book were:

• The DRY principle not only refers to functions but also to pieces of knowledge or assumptions. You should only have to change 1 thing if these change.
• Comments that basically repeat the code break the DRY principle
• "Don't rely on the properties of things you can't control"
• Try and abstract away things like, which kind of database you're using, which OS, whether you're client/server or just client etc.
• Tracer code - develop an entire vertical slice to check it all works and you're on the right track and keep that code (different to prototyping)
• Prototype to learn
• Leave assertions on in production code
• Exceptions couple routines and their callers
• Encapsulate resources into classes using the constructor to allocate them and the destructor to clean them up. Means garbage collection will clean up resources and in non-GC environments it will help remind you to clean them up
• "Abstractions in code, details in metadata"
• Design for concurrency even in non-concurrent environments - makes temporal couplings obvious
• Software is like gardening 
• Don't try to refactor and add functionality at the same time
• "think of Unit Testing as testing against contract"
• "Don't use Wizard code you don't understand"
• When faces with a problem, write down all ideas no matter how stupid and check that whatever makes them stupid actually stands
• Organise teams around functions of the product
• "Failure to meet usability criteria is just as big a bug as dividing by zero"
• Test your tests by purposefully breaking the code
• "Find bugs once" write test to detect bugs that you discover

The idea of using metadata extensively in a program is a new one to me. On the one hand I can see it adding some complexity at first for the code that reads the metadata from it's source (the Authors highly recommend plain text files for many reasons), also adding complexity in that you can't tell exactly what the code is going to do without having to look at both the code and the metadata. On the other hand, there is the obvious advantage of not having to recompile your code when some program you're dependent on starts sending you 6 messages at a time instead of 5. Also I've come across many situations where test code needs a copy of the details that the production code doesn't expose which if they both got the details from metadata would reduce the number of  changes needed from 2 to 1.

The book has obviously been a success and the respect the community gives to the authors has allowed them to publish an entire range of books, with the Pragmatic moniker, the website of which is here http://pragprog.com/. It is a sign of the confidence the book inspires in me about the authors that I've now purchased another book from their range and have a few more on my Amazon wish list.

Someone who has read many books on general programming practice may only gain a few insights from this book, but for someone with little reading in the area then this book comes highly recommended compared to it's competition.

Link to Buy the book on Amazon