Back to Blogs
At Omnitech, summer means interns, picnics, and a summer book club. This year, we read the Pragmatic Programmer: Your Journey to Mastery, 2nd edition by David Thomas, Andrew Hunt. Some of us were old enough to read the original book twenty years ago, so we were excited to dive into this updated version.
To become a Pragmatic Programmer/master craftsman requires effort, thinking, and experience. They "get it done" and "do it well." At Omnitech, we continually work to learn, improve and move towards mastery.
Nuggets
Some of us wanted to share highlights that can help you on your journey to software mastery.
John T
One of my favorite lessons from The Pragmatic Programmer was the idea of Designing by Contract. It brought to light some very important ideas about the importance of clarity between what you are building and the components that leverage what you are building. The authors also discuss that a correct program does no more and no less than it claims to do.
Isaac S
A concept that resonated with me from the book was the idea of "broken windows" in software (no, it does not have any relation to the Microsoft operating system). When a building has a broken window, we might think - hey, no big deal, we'll fix it eventually. But over time, as people realize that there is one broken window, why not break another? And another? And why not kick a hole in the drywall since the windows are already broken? Eventually, the whole building falls into disrepair.
The same thing can happen in software. When we let code quality slip in a few places, developers may see that as an opportunity to let it slip all over the place. We must board up those windows and get them repaired as soon as possible. And how do we prevent broken windows in our code in the first place? Code reviews. Making sure we have multiple sets of eyes on all changes to the system that can ensure that standards and quality are being met.
Emily P
One section that stood out to me talked about requirements. We often call the process of collecting information about a project "requirements gathering." However, this doesn't provide an accurate picture of what goes into that process. We found the term "requirements extracting" was more accurate. The authors wrote, "Requirements are often buried beneath layers of assumptions, misconceptions, and politics. Even worse, often they don't exist at all." Figuring out what is needed in a project is a complicated and lengthy exploration requiring constant feedback and adjustments. Our job as pragmatic programmers is to help the client understand the consequences of their requirements and work through their feedback to provide a successful product.
Kevin
This is the 3rd time I've read this book in the last 15 years. It was great to read it with a group this time. Many of the ideas in this book are familiar, but as I continually strive to get better, I need to be reminded and refocused on them. The biggest "eye-opener" for me was about transforming programming, where you take input data and transform it into an output. Thinking of the data as a "mighty river" opened me to new thinking.
Jack
One snippet that I use for every project is "If the suspect code (code that is throwing/causing an error) passes the unit tests around it, are the tests complete enough?" I think it's hard to gauge how well your code is covered, and it's a game of quantity vs. quality while also meeting in the middle. Sometimes test cases are repeated or, in reality, they aren't effectively testing functionality that they should be. I've taken this approach recently regarding the question "what happens if you run the tests with this data" and decided to attack bugs that come in with data I get from the testers. This way, even if the data is malformed or incorrect from the start, I know that the error will not happen again.
Michelle
The book had fantastic, down-to-earth tips. One that stood out initially was #13 "Build Documentation In, Don't Bolt It On." However, as we continued reading, it became obvious that the "Don't Bolt It On" applied to so much more. Every concept we talk about needing to include, such as Security or Quality, needs to be built in and not bolted on. I think about it like remote start for your car. Does aftermarket remote start work, yes. Is it as clean and reliable as when it was integrated as part of the original design, no. If it matters, build it in, don't bolt it on!
Characteristics
As engineers, we can strive to have many characteristics of a Pragmatic Programmer, including being responsible, honest, trustworthy, thinker, value-driven, aware, knowledgeable, experienced, adaptable, big picture in view, take small steps, no fortune-telling, defensive coder, factual, doesn't assume, writes test to think through the problem, analyst, explorer, diplomatic, agile, teammate, engaged, scientist, servant, respectful, proud of work and takes ownership, professional, creative, vigilant, moral, and courageous.
Keeping the big picture and creating "Easy to Change" software are two of the many thoughts put into memorable phrases that will be a part of our common language in the future.
We learned a lot together from reading and discussing this edition of Pragmatic Programmer. We are sure these ideas will guide us for the next 20 years as it has for many in the past 20 years. We recommend this book to all developers.
