The Pragmatic Programmer, Chapter 1 Review.
A Quick Overview
The first chapter of this book describes the pragmatic programming philosophy, and what distinguishes a programmatic programmer from those around them. The author does this by focusing on a few main tenants of software development and management and then further analyzes them by separating them into sections, which were:
I. How to take responsibility.
II. How to deal with software development entropy.
III. How to spark initiative by inspiring those around you.
IV. How to write ‘good enough’ software.
V. How to maintain an effective knowledge portfolio.
VI. How to communicate effectively.
Although each of these sections contained insightful pieces of information, I feel like there were 3 primary sections that the other sections could be reduced to, the sections involving:
I. How to take responsibility.
II. How to deal with software development entropy.
VI. How to communicate effectively.
Here’s a quick synopsis on each of these sections:
In the taking responsibility section of this chapter, the author emphasizes and stresses the importance of taking responsibility through ownership, effective risk management, and the ability to form rational self dialogues before forming solutions and more importantly before forming excuses for a why a solution cannot be achieved with a specific approach. The author also states the importance of offering alternative solutions when a problem cannot be solved with a previous approach.
Following the taking responsibility section of this chapter, the author discusses the effects of software development entropy. In this section of the chapter, the author discusses the importance of maintaining good software development practices early on by drawing an analogy between bad practices and broken windows, and how both of them can easily cause a slippery slope of events. The slippery slope, in this case, can start with one developer on a team implementing bad practices in code, which then expands to the people working on that code potentially not correcting these bad practices and ‘following suit’ thus spreading more bad practices, which could eventually lead to that entire teams code base being filled with bad practices, which could lead to the team as a whole following bad practices in many areas. The author stresses the importance of fixing these bad practices and habits as they occur, analogous to boarding up the broken windows as they are broken, in order to maintain inertia and keep good practices common, all while deterring others from ‘following suit’ in bad practices.
The final section of this chapter that stood out to me was the chapter involving effective communication skills, in which the author stressed the importance of appealing to the audience you are speaking to, by being able to translate your ideas and messages into a format that is easily digestible, approachable and keeps your audience engaged. When it comes to non-verbal communication the author also stresses the importance of being well-written and watching out for grammatical errors.
How Did I Feel About It?
I felt like the first chapter of this book was written very well and the author did an excellent job communicating their ideas, more specifically I really enjoyed how the author used short parables and metaphors to explain what they meant instead of being overly verbose.
More specifically I enjoyed the author's minimal use of overly technical jargon, which when well paired with the analogies/parables given by the author in each of these sections makes the book very appealing to novice developers or even non-technical readers. And I think the author was conscious of this decision as they took advice from their own effective communication skills section, by understanding who their audience is and creating an interface to effectively communicate with them.
When it comes to the pragmatic philosophy introduced in this chapter, I heavily agreed with a lot of the concepts and ideas described on a personal level in many of the sections, but the section that I resonated with the most was the section on software development entropy. I feel like I resonated the most with the section as it is something that almost every developer goes through, but doesn’t necessarily always recognize or put a name on. I think the concept of maintaining inertia with good practices is an excellent way to fight software entropy, in addition to this I feel like a lot of the ideas and attached rationale explained by the author in this section would also be great for developers fighting back against burnout.
On the other hand, the chapter I feel like I resonated the least with was the chapter on how to maintain an effective knowledge portfolio and while I feel like there were some good pieces of advice and somewhat effective analogies in this section I just felt like the author was being a bit too rigid. More specifically I think the author's framework for describing how to develop and keep an effective knowledge portfolio doesn’t accommodate all types of developers and developer learning styles across different areas in industry and academia, like when the author discusses the concept of learning a new language every month. I feel like the author could have appealed to more developers if they perhaps encouraged learning new technologies every month, which could include things like different frameworks (even if they’re in the same language), different design patterns, different use cases and perhaps even open source contributions, etc. But with that said, it’s hard to be overly critical on the author on this point as the book was written over 20 years ago and a lot has changed.
I chose this book as the summary seemed the most interesting, and I’ve had it referred to me several times the past few years, so perhaps that was part of the selection bias. But overall the first chapter of this book was an amazing read, and I think I’m going to want to finish the whole book now. It’s amazing how a technical book is still relevant and engaging almost 20 years from its initial release date! As a whole, I agree with the author on a lot of the ideas and concepts they suggested and I genuinely think they serve as a good platform to not only becoming a better developer but a better and more pragmatic developer as well.
