The Pragmatic Programmer: your journey to mastery by David Thomas, Andrew Hunt
As the title says, the book tells you how to be a pragmatic programmer. If you do a google search for the work “pragmatic”, you will find the meaning as:
pragmatic /praɡˈmatɪk/ adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations. "a pragmatic approach to politics"
And this is what this book is all about, how to code pragmatically. The book contains nine chapters & each chapter consists of multiple topics. To me, it looks like a long series of posts(called topics in the book) on programming grouped into chapters. In terms of overall content, most of the content is similar to what I already read in “the clean code” and “the clean coder” books by Robert Martin but arranged in a different style.
What does it have?
As already mentioned, the book tells you how to be a pragmatic programmer or, in other words, the best practices for software development. The author expresses that the content in the book is the collection of his notes over his multiple years of experience in software development.
What I found useful
- DRY principle – This means “Don’t repeat yourself”. I think we all know that code repetition is a bad practice, and we must try to avoid it as much as possible. But in this case, the author is not talking about only the code repetition but all kinds of repetitions like unnecessarily adding comments where the code should explain itself, documentation repetitions, and even test repetitions.
- Testing – Follow test-driven development and follow the triangle of testing to test the whole product thoroughly. Run tests frequently and make sure the tests are up to date with the code.
- Automation – The author suggests if you find yourself repeating some task, then you must automate it by writing scripts or using some tools. One point of focus was on using the text manipulation tools and scripts to make sure that we find and manipulate the text faster.
- Teams and Trust – We must communicate a lot in the team to avoid duplicity of code and share knowledge. We must take the lead and motivate everyone to follow good coding practices.
- Refactor often – We use tests to ensure the things are working the way they should. And because we can simply run tests and verify that things are still working properly, we should refactor our code frequently. When you start working on a module, leave the code better than you how found it.
What I liked
- Easy to read – As mentioned already, the book contains many chapters that consist of multiple topics. Because of this division, it is easy for a reader to find and go back to a specific topic or to read only the parts the reader finds intriguing.
- Challenges – Most of the topics contain the challenge problems at the end of the chapter that help in a better understanding of the topic.
What I didn’t like
- Not so flexible – The book gives a lot of great tips and tricks but seems a little too rigid. In my opinion, we always need to break some rules in our software depending on the requirements. Learning best practices is great and keeping them in mind is a must when designing the software, but focusing on perfection can cause a lot more problems for the software than it will solve.
Final words
I did learn a lot from the book but also felt a little bored because I had read similar content in other books. I suggest this book to everyone, especially developers with little or no experience will learn a lot from this book. But make sure that you understand the reasons behind every suggestion in the book and try to incorporate them in your future projects.
Thank you for reading. Let me know if you have already read the book or planning to read it 🙂
