I never did a book review, but since I wanted to improve my writing skills, there is no better time to start than now. Thanks to a lovely co-worker setting up a book club (Hi Max), my reading of programming books became a bit more structured.
This is the second book of the year, the first one being The Staff Engineer’s Path, but I’ll pretend my array’s start at 1.
The book I’m going to review today is The Pragmatic Programmer the 20’th Anniversary Edition by David Thomas and Andrew Hunt.
Based on my observation, the book is one of the most recommended books that highlights good programming practices. This made me curious to figure out by myself why that’s the case, especially since I never read the first book.
The book structures itself in 9 different chapters. Let’s try to get over them one by one and in the process share what I liked about each chapter.
1. Pragmatic philosophy
This chapter introduces the core principles of pragmatic programming, such as DRY (Don’t Repeat Yourself) and YAGNI (You Ain’t Gonna Need It). Who doesn’t like acronyms?
For me there was a subchapter that stood out: “Good-Enough Software”. This hits home because it’s so easy to get distracted by making that one perfect system, when the key is actually iteration.
2. A Pragmatic Approach
This chapter shows how to adopt a pragmatic mindset and attitude, such as being proactive, curious, realistic, and humble.
The code samples are a pleasant touch, but for me as a nonnative English speaker that’s a self-taught programmer, learning terms like Orthogonality helps me put into words things that otherwise I did practice but had a harder time explaining.
The estimating chapter is a nice touch since it puts the dot on the i for one specific thing: the more you know about a system, the better you are at understanding the complexity and estimating. This makes it easier to justify the time spent understanding the system will pay dividends in the long run.
3. The Basic Tools
This chapter covers the essential tools and techniques that every pragmatic programmer should master, such as text editors, source code control, debugging, testing, automation, and documentation.
I am not sure how much of a fan I am of the unstructured approach of output that generic *nix command-line tools exhibit (saying this after 20+ years of Linux in my life) and the chapter at the start leans too much into “The Unix Philosophy”.
I will, sometimes this year, start using an Engineering Daybook as a practice of keeping my thoughts and ideas in order.
4. Pragmatic Paranoia
This chapter teaches you how to anticipate and prevent errors and failures in your code by using techniques such as defensive programming, assertions, exceptions, contracts, and redundancy.
I giggled when I initially read the chapter’s title, but this chapter does indeed take a pragmatic (pun intended) approach. I am not 100% sure I agree with the concept of not using try/catch to just wrap and re-raise the error while just doing extra logging, since it feels like they handle it as an all-or-nothing approach, even though further down the line they cover logging more extensively and the fact that you would like to understand the paper trail of errors as much as possible.
5. Bend, or Break
This chapter explores how to design and write flexible and adaptable code that can cope with changing requirements and environments. It covers topics such as decoupling, abstraction, metaprogramming, reflection, and patterns.
Although beating the topic over and over about pipelines being the best thing since sliced bed this chapter also produces a nice gem: State machines are definitely underused by developers and even if you might not conceptually implement it in code, take a step back and try to draw your process as a state machine to better understand how the flow works.
6. Concurrency
This chapter explains how to leverage concurrency and parallelism to improve the performance and scalability of your code. It covers topics such as threads, processes, locks, queues, futures, promises, actors, and reactive programming. TLDR: Concurrency is harder to reason about and there’s definitely no silver bullet.
7. While You Are Coding
This chapter provides practical tips and advice on how to write better code in various aspects, such as style, readability, naming, formatting, comments, idioms, refactoring, and debugging.
It felt more like reading Thinking, Fast and Slow by Daniel Kahneman (definitely not a bad thing). It is easy to read the whole chapter because it is nicely written and fluid. Also the Password anti-patterns should be printed on all the billboards of the world to get rid of all the stupid ass generic requirements that people pull from their arse when it comes to what they perceive as password security.
8. Before the Project
This tiny chapter discusses how to plan and prepare for a successful software project. It covers topics such as requirements analysis, domain modeling, architecture design, prototyping, estimation, and risk management. However, it’s imho the most important chapter in this entire book, and the reason is simple: you must understand and adapt any kind of magical agile process you read about to your use case, project and team composition. If you take a step back, and look at the bigger picture, there are no two identical top 100 companies in their organization and project management style, and somehow they make it work ;)
9. Pragmatic Projects
This chapter describes how to manage and deliver a software project in a pragmatic way. It covers topics such as team organization, communication, collaboration, feedback loops, agile methods, testing strategies, deployment strategies, and maintenance strategies.
I like the focus on automation, and there was one hit that ‘hit me’ as something I didn’t fully realise before. When talking about continous delivery it’s not necessarily about the actual let’s merge in trunk and get this automagically deployed, but more about: can you always trust your tools, that a deploy process can be done at any given time, and that you understand how to do observability of the systemn.
That being said, would I recommend the book? Yes. Would I read it again? Yes. Did I enjoy the writing style? Yes* (with some exceptions of being overly opinionated in some ways of doing things that don’t apply to all programming languages.)