Review of "The Pragmatic Programmer"

The Pragmatic Programmer, by Andrew Hunt and Dave Thomas. ISBN 0-201-6122-X.

Many years ago, I visited a friend and slept in their spare room. I found a book on their shelves called Programming Pearls. (You’ve probably heard of it; it’s a classic.) I sat up half the night reading it.

A few days ago, I visited a bookshop and bought this book. I sat up half the night reading it. In a few years, I think it might be as famous as Programming Pearls. It certainly reminds me more of Pearls than does any other book I can think of.

The book is a whirlwind tour of a wide range of interesting topics. (Examples, chosen at random by opening the book to random pages: "tracer bullets", a variety of exploratory programming; the advantages of plain-text representations of data; how to handle resources like memory and open files; how to apply the old GUI technique of separating "models" and "views" to things that have nothing to do with user interfaces; how to organise a project team; the value of exceeding expectations.)

The writing is clear and lively. The authors have a keen sense of humour and a fine feel for apposite quotations.

The book is structured as a series of 46 sections, in 8 chapters. Along the way, they give 70 brief tips (random examples: "Don’t Repeat Yourself"; "Estimate to avoid surprises"; "Write code that writes code"; "Separate views from models"; "Don’t use wizard code you don’t understand"; "Expensive tools do not produce better designs"; "Sign your work"). There’s a pull-out card in the back of the book that contains all the tips, and a few "checklists" too.

I only found one typo. The typography is pretty good, although I happen to detest the main typeface they’ve used. The binding is bad; it looks fine, but (on my copy, at least) the covers have a distressing tendency to curl outwards. The pull-out card at the back is difficult to pull out without damaging anything.

I gave some random examples earlier. Here are a few highlights.

  1. An excellent attack on what they call "programming by coincidence": being happy when your system works even if you don’t know why it works.
  2. A discussion of the benefits of automation: code generators, text munging tools to massage your source code, automated test suites and the like.
  3. The multitude of little insights scattered through the book: even in sections whose topics I already knew plenty about, there were usually one or two startling observations or neat tricks or insightful points of view.

Lowlights? Because the book covers such a lot of ground, they have to skim over a lot of issues (but don’t misunderstand me; there’s plenty of meat here). And the two purely mechanical things I mentioned above. I think the only two sections I learned nothing from were the ones on Algorithm Speed (which I think is rather shallow) and Refactoring (which does have some not-generally-known ideas in it; but I’ve just finished reading Martin Fowler’s book on refactoring).

Neophytes will learn a lot from the book. Old hands ought to know most of what’s in here, though too many don’t; those who do will still find enough that’s new to justify the price, and have a lot of fun reading it.

A fine book: enjoyable and instructive.