Book Lessons: The Pragmatic Programmer
While searching for books to read, I stumbled upon a book that is more than 20 years old which people still praise till today! I got intrigued and decided to check it out.
Turns out it was on the O’Reilly platform on which I am subscribed to. I dove into the book right away.
The book is titled “The Pragmatic Programmer”. It is a book that focuses on topics to help you master the art of Software Engineering. It goes through many topics (over 50) that concentrate on how to improve various aspects of your mindset and way of working, in order to be a better software engineer and programmer.
I have learned many things while reading this book. So, in this article, I will share some of the most impactful lessons I have learned, while sharing my own opinion and own understanding of each lesson.
Lessons
Knowledge Portfolio
One of the topics discussed in the book was the idea of keeping a Knowledge Portfolio. It is basically the different thinks you do to expand your [technical] knowledge.
As a Software Engineer, it is important to keep learning new things one way or another. Whether that is by learning a new programming language, taking courses, or reading books. Knowledge acquiring should never stop as long as you are alive.
There are many things to study. But from my own experience I can tell you to study mainly things that benefit you. While it might be more fun to learn about that new JavaScript framework that is 10 KB smaller than the previous one. You might be better off studying about a less “shiny” technology that actually improves the quality of your work and enhances your skills.
Engineering Daybook
While not discussed together, I believe that the Knowledge Portfolio and Engineering Daybook are related.
An Engineering Daybook is a notebook, physical or digital, where you write about the things you learned about, ideas you thought of, or even issues you managed to fix.
This notebook is very beneficial once you get used to using it. That is because you can rely on a source of truth other than your brain for storing things. We know how forgetful we as humans can be, so it is better to delegate the work of remembering by using a notebook.
I personally use Notion to keep all of the new things I learn about, whether it is through books or courses, as well as ideas for new projects or even ideas on how to fix specific issues that can occur often.
Testing
It is a topic that is neglected by many. But the authors make a great point on why testing is important when building an application. They believe it is not necessarily about the test itself, but rather, the thinking process that you go through while writing the tests.
When attempting to create a test, you would have to think from various angles on how you can reasonably fail the test. Maybe by using wrong form data you can fail the application. Having thought of such an issue allows you to know how an API can be utilized, forcing you to think of better ways to improve your application.
To add to the above. As mentioned in the book:
A Test Is The First User of Your Code.
Software Entropy and Refactoring
When it comes to actual coding, writing bad code once can cause you and any other developers on that project to start going down the path of writing bad code. All it takes is one badly written piece of code.
As described in the book, a building can be designed very well with a great architecture, but once you see one broken window on that building, it will start looking less valuable. The same applies to code. Most of the code can follow the best practices and standard guidelines, but once a developer starts to write bad code (for any purpose, such as a nearing deadline), it all starts going downhill from here.
Which takes us to the other point of Refactoring. The book emphasizes on refactoring any “bad” code. You might encounter code that you do not necessarily understand. You should jot those down and ask the developer of that code about it. But if you happen to come across badly written code, it preferred that you refactor it right then and there.
Version Control
Version Control refers to the retaining of the history of a file or project. You might have heard of a tool called Git (check out this article if you haven’t), it is a software tool that is used to keep track of the different versions of files. It is helpful to know what changes have been made to a file.
Say you deployed the updated code and you noticed that one of the pages or features does not work properly. Git, or Version Control in general, allows you to go back to the history of the related file(s) to view what changes have been made that might have caused this faulty behavior.
I believe that version control should be utilized in most software files. In the example above, it can seem that we are focused on project files only, but keep the history of documents, such as your software architecture document, is also important and can be helpful in the long run.
DRY - Don’t Repeat Yourself
One of the topics that the book focused on, was the idea of not repearing yourself, or DRY. It is the idea of keeping each piece of code unamiguous and conveying only one single idea.
For example, say you have a class that adds two values together and prints them out. Instead of writing one function that takes two inputs from somewhere in the class, validates them, adds them together, then prints them out, the function should only accept two inputs, adds them together, and returns the result. This allows us to convey one idea in the function (addition) and to be able to use this same function in other places in the class or application.
Delight Your Users
We often forget the purpose of writing all of the code and developing all of the programs that we spend days and nights working on. It is not necessarily for entertainment and it is not for competing on who writes more code, it is mainly for taking some inputs and converting them to the proper output.
We need to get back to thinking of programs as something that transforms input into output.
The reason for this is to allow the users of our systems to enjoy using it. To simplify the work of people. What is the point of spending days and weeks working on a feature that the users do not benefit from? That is why pragmatic programmers deliver code to the users when they need it, and they deliver it in the optimal format that fulfills their needs as necessary.
Review
I attempted to summarize some of the most impactful lessons I have a learned from this book above. But the book offers knowledge on various topics that only reading the book can make you to benefit from all of it.
In my opinion, this is a book that every Mid-Level and Senior level Software Engineers and Developers should learn. It would be difficult for a Junior with no experience to read because the lessons won’t resonate with them as much as a Mid-Level or Senior developer. Nonetheless, it is a must-read book because of the amount of useful and applicable information it offers.
Conclusion
I hope you learned something reading this article, and I hope that it excited you and pushed you to read the full book. I linked it below on Amazon if you are interested in buying it online.
Thank you for reading and I hope to see you in the next one!