I recently embarked on a journey to read (or re-read) all the great classic books in the software literature.

The Pragmatic Programmer is one of those books which is usually included in the recommended readings for a software developer, and deservedly so. The book, released in 1999, has been so successful that the two authors, Andrew Hunt and David Thomas, have since created their own publishing company, the Pragmatic Bookshelf (with titles spanning a broad range of programming topics).

This book must really have been a breakthrough when it hit the bookstores about 10 years ago. 1999 is one year before Kent Beck released his seminal book Extreme Programming Explained: Embrace Change which exposed the agile software process to the masses. Both Andrew Hunt and David Thomas originally signed the Agile Manifesto, together with Kent Beck himself and a few others, and it shows. But it would be dismissive to describe this as a book on agile since it’s much more.

The book is structured as a series short 46 sections. Each section has challenges and even exercises where appropriate. It touches on design concepts such as orthogonality, decoupling, DRY (which it coined), Domain Specific Languages, Design By Contract, Metaprogramming, Refactoring; it has pages on process topics like build automation, “design to test”, test automation, estimation, requirements collection.

But where the book really shines is where it shows you how to “become a better programmer” (today we might say a software craftsman) and to take pride from it.

The pragmatic programmer is an early adopter, is inquisitive and realistic, and tries to be “familiar with a broad range of technologies and environments“.

The pragmatic programmer takes responsibility, values quality but recognizes when the software is “good enough”. The pragmatic programmer is a continuous learner (the “learn at least one new language every year” advice is often quoted), thinks critically about what he reads and hear, and knows how to communicate. The books explains how you can build these qualities.

The sections that I enjoyed the most is when the authors discuss about tools: the pragmatic programmer prefers working with plain text (the book itself it’s been written from XML transformed into TeX), masters a shell (command line) which he/she can program, knows at least one text manipulation language (e.g. Perl) and how to generate code from metadata.

Even though the recent reprints have links to later tools like JUnit, Ant, etc… still a few parts of the book begin to show its age. For example the authors suggest to pick one text editor (e.g. Emacs or VI) and become a power user (not just know the keyboard shortcuts but also how to extend it to suit your needs). There used to be a time when you could spend your whole working day inside Emacs: you could edit and build your programs, open a shell, handle emails and browse newsgroups, edit text documents (with LaTeX for example), even play games. As much as I love Emacs, I believe today it’s virtually impossible to beat the productivity gains you can get with specialized IDEs like Visual Studio or Eclipse, with their intellisense and plug-in ecosystems.

All in all, the Pragmatic Programmer is easily one of the best book on software development I have ever read. It has really inspired me to continue my journey to become a “better programmer”. Thanks to this book, I have now in my action list: learn a scripting language (Ruby?); learn a functional language (F#?); learn how to use a shell in the Windows environment (PowerShell?); read a book on usability; read a book on the human side of software development (“Peopleware”?). A lot of things. A lot of fun ahead.