Senior Software Engineer Reads

Grokking Simplicity by Eric Normand teaches the difference between actions, calculations, and data as a way to reason about mutation and side effects, and it works better as a vocabulary book than a technique book. If you’ve already internalized what map, filter, and reduce are for, and I mean really internalized it and not just being able to write the syntax, most of the core material is going to read as confirmation of things you already believe instead of new information. The higher-order function chapters and the copy-on-write chapters fall right into that bucket. They’re clearly and patiently explained, and useful for someone who’s never had the difference between mutating and copying spelled out, but they’re slow going if you’ve been burned by shared mutable state enough times to already distrust it on instinct. ...

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. ...

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. ...

Advanced Functional Programming with Elixir turned out to be a pretty good, easy introduction to functional programming concepts, and it uses good domain examples instead of math. It walks through Elixir’s protocol system with a DDD slant, using a theme park domain with rides, patrons, and Fast Passes instead of the numbers-only examples you get in most Haskell books. The code is built around a companion library called FunPark, a teaching-scale version of Koski’s real production package, Funx. The theme park was a good choice, and it paid off most in the Eq/FastPass chapter, where a real business rule (two Fast Passes with the same datetime conflict, but should still be equal by id) motivated contramap far better than an abstract definition ever could have. ...

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. ...

A perfectly good introduction to the Elixir language, although it didn’t have anything specific to learning functional programming in it beyond getting used to doing things the Elixir way. I guess it had more recursion than most introductory programming books… It feels like a terrible introduction in comparison to Dave Thomas’ Programming Elixir though, since it stops totally short of introducing the Actor model and OTP, which are unique strengths of Elixir, but that’s obviously a longer book to read. ...

I listened to two Great Courses lecture series on existentialism, No Excuses: Existentialism and the Meaning of Life by Robert C. Solomon and Existentialism and the Authentic Life by Skye C. Cleary. No Excuses had a lot of lectures devoted to fictional works, more than I expected from a philosophy course. The title comes from Sartre’s idea of Absolute Freedom, that even chained in a dungeon you’re still free to choose your own interpretation of the facts and how you react to them. The Bad Faith concept stuck with me too, the idea that you’re acting in bad faith any time your aspirations ignore the actual facts of your situation. I could aspire to be a champion basketball player, but the facts say I’m 5'11" and almost 50, so aspiring to that would be bad faith. ...

I picked up Build Websites with Hugo because I’m a PragProg loyalist with plans to revive my old blog, and if they have a book on something I’m using, I like to have an opinion on it. My opinion is that it’s fine, but barely. The book is from 2020, and Hugo has changed enough since then that half the examples either don’t work or generate deprecation warnings. I was running Hugo 0.164 against a book written for 0.68, and the scaffolding generated by hugo new theme is completely different now, so it actively conflicted with the book’s instructions at nearly every step. ...

This was one of the better books I’ve read recently for actually changing how I think about programming. It combines domain-driven design, test-first development, and functional programming into one coherent story, which is pretty rare, since most books only tackle one of those at a time. Unlike some of my other recent reads, the Kotlin itself was well-structured and idiomatic throughout, not just functional-flavored Java. ...

Better than initially assessed: Chapter 2 introduces collections, good variance coverage (with a Pet hierarchy), covers extensions and their role in the stdlib, two lambda/HOF chapters. Unusual ordering: generics before lambdas. map/filter/fold deferred to lambda chapters. Coroutines appendix exists but dated. Head First Kotlin uses the usual Head First spiral approach - introduce a concept lightly, let it sit, circle back with depth later - which meant it deferred anything not strictly load-bearing to the appendices. Labeled breaks and enum classes, both things I’d consider core language features, got pushed all the way to Appendix C rather than covered in the main chapters. That appendix is even honest about it in the title: “The Top Ten Things (We Didn’t Cover)” - ten separate topics, including packages, visibility modifiers, sealed classes, and object declarations, that never made it into the twelve main chapters at all. ...