The best part of the book was section 2, where it described different architecture styles and gave each one star ratings across a variety of characteristics, which I’m sure come from the authors’ experience with each style. I also liked how it framed microservices as part of a trend pendulum, reacting against the reuse pain that SOA left behind, since I like noticing when a new trend is really just correcting for the last one’s mistakes. I’m not an architect currently, so I have no need for architecture decision records (ADRs), except maybe for technical decisions made on personal projects so I can go back and remember the thought that went into them. I may start using adr-tools on my own for that. Since I mostly listened to this on runs, my notes don’t really do it justice. I want to go back sometime when I’m not out of breath and write proper summaries of the ratings for each architecture style.

Full book notes.

I first read The Pragmatic Programmer years ago, and the 20th anniversary edition holds up really well. It isn’t just a nostalgia lap, since the updates feel necessary, folding in ideas like ETC (“Easier to Change”), functional-style data pipelines, and more modern concurrency patterns without losing the voice that made the original a classic. It reads less like a list of rules and more like advice from people who have actually shipped things and learned from what went wrong.

I listened to it as an audiobook, and it worked better than I expected for a book this dense with concepts. The narration keeps a good pace, and the material is conversational enough that it doesn’t need diagrams on every page to land. If you’ve read the original, it’s worth a revisit, and if you haven’t, this is the version to start with.

Full book notes.

I didn’t find a lot of the advice in this book terribly useful. It mostly seemed like common sense backed by a bit of research. The onboarding advice was probably the most useful part, if only because I’m senior enough now that it might come in handy with junior colleagues. The idea is basically to focus on single activities at first, starting with concrete code instead of diagrams, and remembering that everything is new to them. It is easy to forget once you’ve been steeped in a codebase for years.

The Roles of Variables Framework was new to me too. I actually paused my run to jot down the key ideas since it felt worth remembering, even though I wasn’t sure how valuable it would be in practice. Looking at my own code though, I mostly stick to “fixed value” variables over any of the other roles (vals in Kotlin, and I’m trying to do some Haskell on the side for fun). I also liked the advice on dealing with interruptions by offloading as much of your thought process as possible instead of trying to hold it all in your head. That’s basically what I use Obsidian for at home, and at work I’ve had the same notes.txt file open for ten years that’s probably 50 pages long by now.

Full book notes.