Pragmatic programmer is one of the most preachy programming books I have ever read, and this without offering any substance to the preaching. The principles talked about in great length are sometimes extremely simplistic , such as “Think about your work” – of course you should think about your work; it’s programming after all, not tightening screws in a car plant. These principles are bolstered with childish stories everyone knows, such as the frog in the pan, which have no relevance to the programming craft. At the same time, the authors avoid discussing the real tough problems that software teams face, such as dealing with incompetent managers who apply pressure all the time, and take no responsibility when defects start cropping.
The age of this book, written in 1999, also shows, because of the specific nature of examples chosen. For example, the authors write about using a ‘scripting language’ such as Python or Tcl/Tk to prototype before moving on to a ‘real’ language to build a working version. This distinction has long been superceded, scripting languages (which aren’t called even that anymore; they are now called ‘very high level languages’) becoming some of the most popular tools for all kinds of software. Accordingly, the examples and longer discussions are mostly C++ and Java-oriented. The authors sometimes argue for things that could be due to the one and a half decades that went by, but I doubt whether there was any discussion at the time either. Examples for this are using Notepad for programming, and syntax highlighting in an editor. These are the most primitive topics in programming, and don’t belong as discussions in a book that deals with topics of object-oriented modelling a few pages later.
The authors are also dead wrong on two fronts, in my opinion. One is their self-confident argument that a programmer should learn a new language every year. How can a programmer who has so much experience as the authors claim something like this? Really learning a language does not only mean learning the syntax and reserved keywords, but understanding the paradigm and idioms of the language, and the facilities of the underlying platform. What the users should have said is “Learn new programming paradigms”. The imperative paradigm is overrepresented in today’s industry, and looking over to others such as functional or logic languages certainly improves a programmer’s skills. Jumping from one language to another each christmas, however, will only lead to half-baked knowledge of the logic operators of different languages. The second topic where I think the authors are wrong, in my opinion, is their defense of code generators. To be perfectly honest, if you need code generators to keep your code base concise and clean, the language you are using is simply too limited, and you should consider some alternatives.
The reason I’m still giving three stars despite my criticisms is that, except for the mentioned two topics on which I think they are completely wrong, the authors don’t write nonsense. Although the tone is so preachy and content simplistic, most of what they say is right. There is a time to read this book, just like there is a time to read Enid Blyton books: At the very beginning of your career, when you can’t even touch-type. But then again, just talk to some experienced teammates, or read a few classic posts from programming blogs like Coding Horror or Joel on Software (or better, read all their posts). You will learn much more about building software, and that while being entertained and not feeling as if you’re being treated like a child.