I recently finished The Pragmatic Programmer by Andrew Hunt and David Thomas. It’s one of the most informative books on enduring programming practice that I’ve ever read. It makes the case that a 10x programmer is pragmatic and produces more code generation tools than actual code. It also deals with communication and project management skills in a similarly pragmatic fashion.

One of the fundamental principles driving this book is the DRY principle of not repeating yourself. However, the authors correctly identify a place where repetition is useful and necessary. That place, getting a computer to repeat itself, is one of the best tips I took away from the book. By writing generators, a good programmer can create utilities to be used by multiple different software teams. This allows all programmers who work together to be more productive and build software quicker. Often times, though, programmers who are able to be quick and productive become harder and harder to manage. This aspect of software development is also addressed by the book.

Software project management and development is easy when you know exactly what you want. When you know exactly what it is you’re going to build and have all tasks to build it detailed, then you can usually pick from open source packages or tools and tweak them slightly to suit your needs. However, it’s often not the case that projects are so finely detailed, and communication with stakeholders in the project becomes of utmost importance. The Pragmatic Programmer  takes this into account and mentions the necessity of frequent communication with stakeholders and keeping up with changing requirements. There’s not much that you wouldn’t find outside of a good project management book, but the one thing that stood out to me was the application of the DRY principle to project communication.

One of the best practical applications I took away from this book was to apply DRY to every piece of information about your  software project. There is no reason to not tightly couple your documentation to your code if you keep them together. A good example of this is JavaDoc, it allows documentation to be automatically generated for your code from comments left in your source code. This allows documentation to be changed in the same place that you make changes to the code. As much as I like documentation utilities like JavaDoc or JSDuck, I like Python and Elixir’s doctest feature a little bit more. Doctests allow you to write code examples that will be interpreted by Python or Mix as tests. This not only allows you to provide examples of your code to users, it also allows you to verify those examples in a CI build.

The Pragmatic Programmer is a must read alongside other giants like Clean Code and the Mythical Man Month. I’d highly recommend this book as a must read to any programmer who has just graduated with a Computer Science degree. It’s practical applications cannot be understated, and the wealth of referenced material is worth the price of admission.