Books that changed my career - The Pragmatic Programmer
This blog post is a next one in the series which contains the most influential books that I have read in my programming career. This is my private ranking, each post contains a good dose of my private opinions (you have been warned), but besides that I hope that you will find it valuable.
Introduction
In the previous post, I have mentioned that I have this book in three copies - two editions of e-book version (Polish and English) and printed Polish translation. The last one is the most valuable for me, because I have received it as a gift from my colleague during studies, with very nice inscription (after graduating 3rd year, if I recall correctly - Hi Rafał! ).
I would like to focus in this post on the actual details, because book is well known in the community. And it definitely deserves its fame and glory. It is even more actual, than C Programming Language by Kernighan and Ritchie. 
Actually it is a huge foundation under the Agile Manifesto (it was published two years before formalized meeting happened, where the document was signed), moreover - both authors are signatories of that manifesto.
The Pragmatic Programmer: From Journeyman to Master
Subtitle
Almost each science specialization has its own book, which is required to read before you will start a professional career. If you are an apprentice, you will probably get most of this book, because your mind is fresh and knowledge base is relatively small, especially regarding topics like estimation, career planning or teamwork.
But in this case, even the subtitle suggests that it is a book for all generations of programmers. Of course younger programmers will benefit the most, but not surprisingly, even the more experienced folks can find this book refreshing. Why? Because it is a classic example of knowledge which is universal, but sometimes not commonly known or even forgotten.
Universal Truths
I would like to introduce the most favorite advice and guides from the book.
- Tracer Bullets and Prototypes - If the second term is well known (maybe even more as a proof of concept), we often forgot about first one. And that is a huge mistake, because it is highly useful. Moreover, we often want to use the tracer bullets, but we misuse prototype instead - building not a walking skeleton, but a walking dead project. The main difference is related with the destiny of both - prototype should be built, conclusions should be gathered and whole project should be thrown out through a window. If we want to build a skeleton and fiddle with the internals, because we do not feel how it should look like right now, we should use a tracer bullet. And the rules how to build both are different. I encourage you to grab your own copy, look into that chapter and read it out loud (if you do not have one yet - here is a link to an official shop).
-
DRY, YAGNI and other acronyms - During my career I ran into these abbreviations many times. And book is full of it - it does not mean that it is something wrong. Our industry is full of it - it builds our internal dictionary and sometimes it adds more meaning. Aforementioned two - DRY (Don’t Repeat Yourself) and YAGNI (You Ain’t Gonna Need It) are kind of an axioms which are not negotiable. For a beginner, especially curious one, listening just one word thrown out as an explanation can be infuriating, but eventually we will all learn what it means to violate that rules. In a hard way.
- Boiling frog - Typical metaphor for a problem, which can be observed from the outside, but never from the inside. It affects our health in the long run, it changes our attitude and forms the future career. Sometimes it is more healthier to step out for a while and just listen, observe our/team/project behavior. Practice makes permanent and our little habits can grow to an overwhelming problems in the future.
- Bus factor - My personal favorite, mostly because I was once such person and I will not lead to that situation again. I really like the Agile attitude about cross-functional teams because it helps solve the problem. Your team should be resilient to a situation, when you are losing one person from the team. And you as a responsible and professional software engineer should not add anything to such problematic factor.
-
Rubber Duck Debugging - This is probably the most known advice from the book. Mostly because our brains works in that way and probably everyone experienced that feeling in the past. This is the easiest way to enable rich mode in our brains, because we are switching perspective and way of thinking about the problem. It does not have to be an actual rubber duck, it can be another person in the office or even a LEGO minifigure.
- Law of Demeter - This the most underestimated law from that book. Someone said that it is applicable to the OOP only, but it is not true. Violations of that rule results in many different forms, the lightest and most famous one is probably a train wreck. I strongly recommend to read this chapter again, mindfully - try to make notes or rethink it in the back of your head. It really helps to understand and shed new light on the meaning.
And what is your favorite advice from that book? Please, share your choice and explanation in the comments below.
What’s next?
I would like to cover another classical position on my bookshelf, which is very underestimated by the community. Recently, it receives proper respect, even the Uncle Bob recommends to read it. Book covers functional programming in an exotic language, but each MIT freshman have to read it and they can do it easily. It is possible thanks to the three brilliant authors who created a very comprehensible and timeless book (which is, in my opinion, even more actual now). Stay tuned to the next post!