Book of the Month series round#6
“The greatest of all weaknesses is the fear of appearing weak.”
I began reading my current book of choice at a relatively slow pace and kept going with the pages at the same pace, all the way to the very end because I wanted to memorize every single sentence it hold.
The pragmatic programmer, as the book I was referring to in my previous sentence, was first published in 1999, and it has become such an acclaimed book that I’m currently holding a copy of its second edition in my hands, which was released for its 20th-anniversary.
This new edition has been updated to make it more relevant to the current industry standards. The authors removed some outdated topics and updated its content to use more current terminology.
The authors, David Thomas and Andrew Hunt are internationally recognized as leading voices in the software development community. Together, they founded the Pragmatic Bookshelf, publishing award-winning, leading-edge books for software developers.
Nowadays, The Pragmatic Programmer is one of the most recommended books for everyone in the software industry — and quite rightly so. I’m quite certain all developers have heard of at least one (or more) of the principles preached by the authors. Ok, but why has this become so popular among software engineers, you might ask.
The authors not only deliver pragmatic concepts, but they also cover the importance of developing our soft skills and sharing their personal experiences with the readers, fellow eager-to-grow programmers by using their humorous, realistic, easy-going writing voices. So, answering my question, the secret ingredient, in this case, might be their humorous, soft-skill-based approach to the problem.
The book is divided into 9 chapters, each containing a collection of related topics, from practical career advice to the craft of writing software and how to approach working on projects. If I had to highlight a running theme, it would be the decoupling. When we say two pieces of code are “decoupled”, we usually mean a change in one doesn’t require a change in the other. The design by contract, shared state, testing, and refactoring related topics also underpin this theme.
Dave and Andy encourage the craftsman mindset; a delivery-oriented professional approach to software development focused primarily on delivering value. Being able to articulate the value you bring to a project or organization as a software engineer is a career superpower!
“Tools amplify your talent. The better your tools, and the better you know how to use them, the more productive you can be.”
This is the kind of book that everyone can learn something from, regardless of the level of experience.
So, who is a Pragmatic Programmer?
Even though the title of which a Programmer usually has been called is some variation of “Software Developer” or “Software Engineer”, in truth it should be “Problem Solver”. That’s what they do, and that is the essence of a Pragmatic Programmer: finding solutions to problems.
“ Programmers are a bit like cats: intelligent, strong-willed, opinionated, independent, and often worshiped by the net. “
I’ve decided to highlight one hint from each chapter to give an overview of the good stuff this book provides.
Don’t Live with Broken Windows
The authors refer to poorly written code, bad designs, or wrong decisions as broken windows and encourage the reader to follow the boy scout rule: “Always leave the code better than you found it”.
They also introduce the debugging mindset — “ Before you start debugging, it’s important to adopt the right mindset. You need to turn off many of the defenses you use each day to protect your ego, tune out any project pressures you may be under, and get yourself comfortable. Above all, remember the first rule of debugging — don’t panic. “
This sounds silly at first but if you have been debugged an issue before, you know they have a point.
Here is a really good thinking approach to start the debugging process: “Once you think you know what is going on, it’s time to find out what the program thinks is going on.”
Prototype to Learn
I really like how they highlight prototyping as a learning experience, saying that its value lies not in the code produced, but in the lessons learned. That’s really the point of prototyping.
“Kaizen” — a Japanese term that captures the concept of continuously making many small improvements
Don’t Assume It — Prove It
It is so easy to always assume, we do it every single time, even when we are not conscious about it. Next time you find yourself doing it, try to prove your assumptions in the actual environment, with real data and boundary conditions.
Design with Contracts
Use contracts to document and verify that the code of which you are writing does no more and no less than it claims to do. No need for a surprise ‘feature’.
Minimize Coupling Between Modules
If you are familiar with the following scenario where you or your team are afraid of changing the code because you aren’t sure what might be affected, then that codebase is tightly coupled. The rule of thumb is to avoid coupling by writing “shy” code and applying the Law of Demeter. You should aim to reduce dependencies and help build components that are loosely coupled for code reuse, easier maintenance, and testability. A function should only act on its parameters, objects it creates, and methods in the object it creates.
Refactor Early, Refactor Often
As you might weed and rearrange a garden, you can also rework, rewrite, and re-architect code when it needs it. Fix the root of the problem. The rule of thumb here is to not try to refactor and add functionality at the same time. Make sure you have test cases first!
Don’t Think Outside the Box — Find the Box
When you are facing an impossible problem, identify the real constraints. Ask yourself those hard questions: “Why is this a problem? What is it that’s making it so hard to solve? Does it have to be done this way? Does it have to be done at all? Is there an easier way?” Sometimes to solve a bug, you only need a fresh perspective.
Test State Coverage, Not Code Coverage
Code coverage can mislead you, instead identify and test significant program states. Just testing lines of code is not enough.
Sign Your Work
Craftsmen of earlier ages were proud to sign their work. We should do the same.
I want to end my review with this appropriate phrase about our instincts:
Listen to your Lizard brain — Instincts are simply a response to patterns packed into our nonconscious brain.
Overall, I consider this book a must-read and I would recommend it to anyone who is either working in the software industry or is interested in the industry and is eager to know more about the field.
