One of the most recommended books a code newbie can find when browsing through internet is this book. A simple search on Google typing books every programmer should read reveals this fact (e.g: 1, 2, 3). However, I always thought that this was a specialized book for professional programmers, something currently out of my scope.
Nevertheless, I heard one of the authors of the book, Dave Thomas (@pragdave), in two episodes of CodeNewbie (part I, part II) and he was very convincing in saying that the newbies could as well take advantage of reading it. Therefore, finally I made up my mind and read it. It took me over 2 months to finish it with a path of 30 min – 1 hour of reading per day.
If you take in count the advice that Andrew and Dave give, you’re going to be a better programmer for sure. However as a newbie, sometimes I feel that I can’t apply the majority of things I’ve read. Once you reach past the first half of the book, it starts to focus on things useful for big development projects. For example, there’s a chapter about testing and automation which convinced me that I should be testing more, but they talk about developing tools for automatic testing, and I think that will over-complicate the little projects I do (mostly school homework and bonfires from FreeCodeCamp).
On the other hand, the things I did really understand make the book worthwhile. Some of the advice I want to include in my workflow are:
- The DRY principle (Don’t repeat yourself) is not just related with using functions in your code, its influence should affect all the knowledge written in the project, for example the documentation. This is achieved by writing the documentation in your code and then use some documentation generator that looks on your code and makes the docs automatically from it. You write it once and have it in different formats.
- Store information in plain text files which are more likely to last over the years without compatibility issues (something that already happens to me with .doc, .docx and .odt files). The data that a program uses should be on a plain text file rather than inside the code.
- Always comment your code, but the comments should say why you do something, not how. How you achieve something is already written in your code.
- Know the best text editor you can use for all the writing tasks. This means using an editor for writing code, writing txt files, markdown, and so on (in my case I’ve chosen VIM).
- Automate as much as you can. Generating documentation, running tests, writing code (through snippets), etc. Something that I’m not doing at all and still having to figure out how to do it.
- Fix issues as soon as you detect them. If you let them pass in your code for “later fix”, they’ll spoil the code and more bugs will appear until the project becomes nonviable.
- Sign your work, be proud of it, and accept criticism from others, but above all, be critical with your own work.
- Design by contract. Before starting the project the boundaries should be clear (our customer requirements), and we should develop towards meeting those requirements. No less but no more because it’s easy to fall into a spiral of improvements that will make the project never ready for shipping.
As you can see, even though I think there are a lot of things in the book that I can’t use right now or are beyond my current coding skills, “The Pragmatic Programmer” is still an excellent book. What’s more, I’m sure that I’ll read it again in the future when my skills were improved to extract more useful information.
In conclusion, I would recommend you to read this book, or at least the first half of the book if you’re a new programmer, no matter what your skill level is.
Edgar S. Hurtado is a biologist who discovered his passion for programming through MOOCs right after finishing his degree. That passion led him into vocational training on web development, with self-paced resources and the objective of gathering strong programming foundations for his ultimate goal: becoming a Bioinformatician. You can follow him on twitter @edgarshurtado.
Post edited by me. View the original.