The Pragmatic Programmer [Paperback]

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.

The key principal is one that I (and most people) probably subscribe to, perhaps even subconsciously, which is called 'DRY', which stands for 'Don't Repeat Yourself'. The difference is that the authors explain how to apply this to _all_ aspects of your job, not just the obvious one which is code re-use and sharing.

In general, the message seems to be 'invest time in the short term to automate and increase efficiency in the long term'. A sensible message, but one that many people (and I most definitely include myself here) avoid doing because of the initial time and effort involved in learning the required technologies and implementing the automation (Emacs and Perl for example).

Other advice I particularly agreed with was the importance of recognizing limitations of methodologies and diagram-types, and using them as a guide and communication medium rather than as an end in themselves. I also really liked the sections on decoupling, which has a nice introduction to JavaSpaces - a really cool paradigm for certain classes of problem.

In summary, this is not really a reference book - instead it's a 'memory-jogger', reiterating many things you already know at some intuitive level, but fail to follow - up due to external pressures or just plain homeostasis.

I will imidiately agree with some of the negative reviewers that the book states "the obvious". But that is the whole point, dammit! I do know that I should not do so-and-so, but I still do the bad thing occasionally. The book shows me - gently! - other ways.

Some may be irritated because of the elementary stuff and simple language (and "no examples"), but if you need examples, you have perhaps not that many years of practical experience. I, at least, do not feel the need.

Some say that the book is part of the eXtreem Programming paradigm. Well, no - I think the book to be unrelated to a particular school of thoughts. Instead it is a book that every programmer can relate to.