The Pragmatic Programmer

The Pragmatic Programmer is a book that was recommended and leant to me by a colleague. He explained that it wasn’t about a particular language or framework, but that is was more about the philosophy of creating software.

So I said: “what, you mean like Steve McConell’s Code Complete 2?”. The moment I put this book in my bag ready to take home and read that question got translated into: “Will this be as good as Code Complete 2?”.

If you would like to find out the answer to that question, then read, read, on.

One point to make about this book, is that all the way through, there is a theme of basing everything on a “tip” – or more precisely, a witty one-liner or cliché representing the underlying programming principle, concept or general attitude of the authors.

The preface of the book contains the first few tips; the first being “Care about your craft” which the author translates into meaning you should care about what you do or you wont do it well.

Chapter 1 lays the ground work for the rest of the book and generalizes about what they call a “Pragmatic Programmer”. My favourite tip from this chapter is a good one: Tip 4 – Don’t Live with Broken Windows.

Tip 4 is based on the “Broken Window Theory”, where, basically, if a building has one smashed window, this will be more inviting for other windows to be smashed, in turn causing the whole building to become a wreck. They then translate this to software, and recommend that, leaving small cracks in your code will encourage you or other to leave other smalls cracks – which will ultimately cause your software to crumble.

Credit where it is due, tip 4 makes a lot of sense and is often in my mind when I now write code.

Chapter two moves onto to sharing principles common to all programmers. This chapter contains the ubiquitous Tip 11 – DRY – Don’t Repeat Yourself. In software circles, this cliché is everywhere, hence its value. It means to never duplicate code – to always reuse common code. If you need to make a change, then you only have to make it in one place. It might seem obvious, but until I had DRY ingrained on my mind, I was prone to unnecessary duplication. God bless DRY.

Tools – what kind to use, how to use them expertly and their value to a programmer is the focus of chapter 3. In this chapter I worry that the content can become a little dated and the authors may be too opinionated. For instance, Tip 22 – Use a Single Editor Well. Granted, it may make you more productive to spend all your time with one application, but if you put all your eggs in one basket and that basket gets behind the times – those productivity gains may cease to exist.

The rest of this book then continues the theme with chapters covering how to:

· Do the best job possible – accepting you can’t write perfect software.

· Write flexible and extensible code

· What to think about as you are actually typing your code

· Nailing your conventions before you get cracking on a project

· Thinking about the project as a whole

What’s cool about this book is the little pull-out you get with all the tips written on. This is very handy for remembering all of the concepts represented in the book (for better of for worse).

Another good touch from the authors is to add exercises to the end of each chapter, to help put into practice what you should have got from the chapter. Mostly they are no gimmick either.

So, is it better than Code Complete 2?.........No

Nevertheless, it is a solid book, containing some great principles. Wiser I definitely am for taking the time to read it.

It has its blemishes though, and through being so opinionated, the authors don’t seem to go halfway. So rather than compromise and say, “we think you should have code comments”, they instead say “your code should always have comments”. Well, even some experts agree that comments are unnecessary. But that is subjective and this book is opinionated – which overall makes it an almost essential read for programmers (if only Steve McConnell hadn’t written Code Complete 2).