The Pragmatic Programmer: A Book Review
Why are you here? Well, for now, it’s not a spiritual question as to why we all are ‘here’ (which should be a constant question in your mind anyways). Right now, the question is why you are here in this field of Software Development.
Are you here only because of the financial stability & better life this field has to offer? Or, are you here because you truly love what you do? If your answer is the latter, then this short article is for you. Not that there is something wrong with the former objective, in fact it’s always an important factor to be considered. But with that objective, this book would not relate a lot to you.
The Pragmatic Programmer by Andrew Hunt and David Thomas is a must-read book for everyone who love what they do and want to get better at it every single day. This book does not get you a fancy certification title, neither does get you quick tips about a certain technology to put on your resume. Rather it helps you set up a right mindset, helps you pay attention to what you do and then guides you with the way to make it better. In short, this book helps you become a better programmer. Even though the title of the book says “programmer”, it’s for everyone that’s in this field i.e. developers, testers and even managers.
Through a series of “tips”, the authors take you through this process of transformations. When I started reading this book about 6 years ago, the very first tip itself caught my attention. “Care About Your Craft”, it said. Imagine looking at any artist, say A. R. Rehman or Lata Mangeshkar (Indian Music Industry Masters), while they are at their daily “riyaaz” (practice). What you would see? You would see an individual focused on what they are doing, being their own self critic and correcting themselves until they achieve perfection by their own set standards. You would see this going on day after day and for hours in a row. Why does that happen? Because they care for their craft. The authors of this book give the greatest emphasis on this aspect, that you must care for your craft. Once you get into the role of a craftsman and you really see yourself wanting to produce the greatest craft ever, you would not need any external factors to get best at it.
And this is just the beginning, as the authors then take us through all of a software developer’s daily problems and provide us a way to approach those with a pragmatic mindset. What is a pragmatic programmer anyways? This book defines it nicely as someone who thinks beyond the immediate problem, always trying to think about the bigger picture, and one who takes full responsibility of his/her own work.
The beauty of this book is that it’s written by programmers after having themselves gone through all of the day to day problems faced by programmers. So, it doesn’t just offer a typical management advice, but serious practical tips and tools to help solve problems. Like me, I am pretty sure you would stop at many instances and think that yes, this is how exactly it happens. My favorite tip in this book is “Don’t Program by Coincidence”. It happened to me so many times that there is a bug, and somebody says they fixed it, but when asked what the problem was, the answer you would get is, “Not sure, but it’s fixed”. This is an example of programming by co-incidence in real life. Unless you know what the problem was, and under which circumstances it appeared, how would you guarantee that it would not come back? Another important thing you notice is that the language of the book is so simple that you feel someone is taking you through all of the tips. And that too with humor and fun. And yes, there is code, along with challenges and exercises to keep you engaged. It introduces you to a variety of tools as a starting point with regards to some of the tips.
You may be thinking in your mind that you know what, all of that sounds good in theory but doesn’t work in practice. When my boss/client is shouting at me, none of that helps. I don’t blame you, as that’s how most of us are used to thinking about most of the books and advices out there. But as I said in the beginning, if you really love what you do, you would automatically get into the habits suggested by the book.
With that, I will leave you with few of the tips this book has to offer in order to help you get an idea of what’s in store. (You can get the full list here - https://pragprog.com/the-pragmatic-programmer/extracts/tips ). Just by reading these tips (which are explained in greater details in the book), you would see how this is different than any other programming book you have ever read.
Do read the book and share your views with me.
· Care About Your Craft
Why spend your life developing software unless you care about doing it well?
· Provide Options, Don’t Make Lame Excuses
Instead of excuses, provide options. Don’t say it can’t be done; explain what can be done.
· Be a Catalyst for Change
You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.
· Critically Analyze What You Read and Hear
Don’t be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.
· Don’t Panic When Debugging
Take a deep breath and THINK! about what could be causing the bug.
· Don’t Think Outside the Box—Find the Box
When faced with an impossible problem, identify the real constraints. Ask yourself: “Does it have to be done this way? Does it have to be done at all?”
· English is Just a Programming Language
Write documents as you would write code: honor the DRY principle, use metadata, MVC, automatic generation, and so on.
· Invest Regularly in Your Knowledge Portfolio
Make learning a habit.
· Fix the Problem, Not the Blame
It doesn’t really matter whether the bug is your fault or someone else’s—it is still your problem, and it still needs to be fixed.
· Don’t Program by Coincidence
Rely only on reliable things. Beware of accidental complexity, and don’t confuse a happy coincidence with a purposeful plan.
· Sign Your Work
Craftsmen of an earlier age were proud to sign their work. You should be, too.