Article

The Pragmatic Programmer book review

October 7th, 2013

This book is recommended and referred to in so much other literature, it hardly requires an introduction. I really don't kow why it has taken me so long to finally read it... Luckily, for this book, it's never too late. My goal was to improve myself as a professional software developer.

Readability:

Rather than taking you on a journey with a beginning and an end, this book is a collection of wisdom and practical advice from the trenches. It describes, for many area's of software development and project management, best practices based on experience. Then it compiles that discription into a one-liner as a "tip". There are 70 tips, and some of them are pure poetry. You can read this book in any order, and keep it around for reference on specific subjects.

I do believe that a lot of the information only makes sense if you have personally experienced the problems that are being described. If you're just starting out as a programmer and use this book as a guideline - it will certainly help, but you won't really grasp why. And because of that you won't get as much out of it. So by all means, read it. But then re-read it when you're a couple of years along...

Lessons learned:

  • "Don't live with broken windows" - Tip 4, p.5 A brand new building will always look clean, well built and attractive. But as time goes by, without the proper maintenance, that same building will deteriorate to the point where it's abandoned completely. The theory is, that a single broken window left unfixed will give the impression that nobody cares and cause it to happen. Always fix your windows is some seriously good advice, that I have not taken for way to long in my career.
  • "Rather than construction, software is more like gardening"  - p.184 Traditionally, software development is compared to construction, where something is built according to extremely detailed plans drawn up by an architect. But gardening is a better choice of metaphor, because the initial plan is always subject to change under influence of outside forces (rain and sunshine) and time.
  • "Don't think outside the box, find the box" - Tip 55, p.213 When faced with a problem, we tend to eliminate possible solutions because they are unconventional. But finding those solutions can be done by finding or describing the true constraints (the real "box"), and using that extra space you didn't think you had before.

Conclusion:

This book almost reads like a history lesson. All kinds of advice and popular analogies I've picked up from others over the years comes directly from this book, and I never even knew it.  It's almost painful to think how much trouble I could have spared myself had I read this book when it came out (but like I said, I think it would not have made the impact  it has now).

This book should be on every developers bookshelf, no doubt about it.

Ramon de la Fuente

Pointy haired boss