This book gave a lot of insight into how to be pragmatic while developing any software. The books put more effort into the DRY principle. If anything is repetitive then try to extract in some function, class, or module. They went beyond code with the DRY principle that if some task/work is repetitive then try to automate and save time for yourself to focus on some other better stuff.
They’ve also provided tips and a checklist to be a pragmatic programmer. https://bit.ly/2L56wUu
It also emphasizes “Don’t code blindfolded”. One of the examples I usually come across is just copying/pasting answers from StackOverflow. I found this interesting blog for this.https://bit.ly/2q5Vrvh
While reading this book I came across this “The Changelog” podcast.https://changelog.com/podcast/352
As Dave describes at the beginning of this podcast: The Pragmatic Programmer is probably not a book on technology per se. If I had to say what it was, it’s a book on people, and people haven’t changed that much. Expectations have changed, but the actual way people do things -that hasn’t changed for thousands of years; we’re just as bad now as we were then, and that’s just the way it is.
They have published a new edition of this book after 20 years and talked about what’s changed in the software industry in the past 20 years. It’s that nowadays developers are now jumping to new shiny tools/frameworks which sounds cool very early, with less knowledge of the basics of how it works, which creates high dependency.
I want to confess that in the early 2 years of my career I exactly did the same mistake. I just look for a library/tool which is easy to integrate and solve my problem ASAP without considering its impact on the project.
The current situation has changed for me. Now I look more towards stability and long-tested solutions for the project instead of jumping and using any new shiny tool/frameworks which sounds cool.
Basically, it’s called HDD (Hype Driven Development)