My job has a learning & development stipend. I usually use it to buy books that are relevant to my work. Here are the ones I read in 2025 and what I think of them.

The Challenger Launch Decision: Risky Technology, Culture, and Deviance at Nasa

After the Challenger disaster, many people were asked to explain how NASA could have allowed it to happen. Ethnographer Diane Vaughn was among them, and her detailed, fascinating, compelling account of her findings has become one of my favorite books. Her "normalization of deviance" theory, in which a long series of individually defensible decisions expanded NASA's tolerance thresholds until catastrophe ensued, is relevant to anyone who's ever made an engineering trade-off. Some problems only appear once you zoom out.

The Mythical Man-Month: Essays on Software Engineering

This is a collection of essays by Fred Brooks, the manager of the development of OS/360, about software engineering. The original version was published in 1975, but I read a later edition that included "No Silver Bullet", an essay he wrote in 1986.

Many of the essays are just as relevant today as when he wrote them. (In particular, I think Brooks anticipated contemporary discussions about LLM-based development - albeit not in a way that is likely to change any minds.) I find this relevance both discouraging and encouraging: While discursive consistency is a sign of underlying structure within a discipline, I guess we haven't made much progress in forty years. I hope to write a more detailed review of the collection in which I explore the particular ways I think it has aged well (and poorly), but my overall impression is good, and I recommend it to anyone interested in how organizations practice software engineering.

The Art of the Metaobject Protocol

What if everything about your programming language were customizable? You could perfectly tune your program to the task at hand: None of your code would be a confusing workaround for anything, because you could demolish every irritating obstacle. A perfect alignment of behavior and objective. Wouldn't that be great? The authors of The Art of the Metaobject Protocol sure think so.

This is The Lisp Philosophy, and in 2025 - thirty years after this book was published - The Lisp Philosophy is dead. It's dead because it wanted us to write every program in a bespoke domain-specific language specifically crafted for that program. The problem is that this makes it extremely difficult for new people to learn how the program works. And if new people can't join a project, the project dies.

We care more about software legibility and maintainability these days. "Can a novice to this codebase figure out what's going on?" is now generally considered an important metric (at least aspirationally), but it's never mentioned once in The Art of the Metaobject Protocol. I believe that's why this "art" has been lost.

Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs

15% of this book explains the nuts and bolts of how OKRs (Objectives and Key Results) work. The other 85% breezily fawns over executives who've implemented them. The funniest example of this is the entire chapter dedicated to Zume, the pizza-making startup that used OKRs to "disrupt" pizza delivery - written three years before Zume "pivoted" because it sucked at making pizza and six years before it closed shop because it sucked at everything else. Oops! Maybe our standards for "success" should be more than getting a Series A, John Doerr.

When the fawning isn't laughable, it can get slimy. One chapter is on the importance of setting seeimngly unattainable goals. Ths is seen by the executive class as laudable decision-making - even as they gloss over the work put in to actually achieve the lofty goals they conjure out of thin air. The worst example of this is the account of some executive declaring that Chrome's JavaScript engine needed to be ten times faster than Firefox's. What visionary leadership! Actually building this new engine got only one short paragraph, which can be summarized as "we hired a guy to build it, and then he built it." I want to read that guy's book, not the one where vice presidents pat themselves on the back for setting unrealistic topline goals ten times, watching nine of them fail, and then cashing out the tenth for 300x what their workers got paid.

Tempo: Timing, tactics and strategy in narrative-driven decision-making

My introduction to Rao was The Gervais Principle, Rao's interpretation of (and elaboration upon) the MacLeod Hierarchy. Some of The Gervais Principle I found tremendously illuminating, but some left me feeling like I'd just finished talking to a used car salesman. Which is the real Rao? The brilliant explainer of deep corporate truths? Or the confabulating charlatan?

To get more data, I picked up Tempo, and now I can confidently say: Rao's dominant analytical trait is laziness. He's got some useful thoughts, but if excavating them requires work, Rao won't do it, because he knows that suckers like me will buy his books regardless. The vast majority of Tempo is Rao repeating pablum like "decision-making is like cooking" and prescribing some home-grown observational exercises. The single half-good idea in the book is that effective decision-making involves the use of "cheap tricks," which are bets against reality that pay off in the short term but not the long term and must be capitalized on before negative consequences manifest. Like, for example, leveraging a popular blog post into a self-published book that I'm pretty sure he typed out in one draft and passed over to an equally lazy editor.

The Programmer's Brain: What every programmer needs to know about cognition

This book purports to use cognitive science to help professional programmers understand how to best deploy our cognitive resources when reading and writing code. Unfortunately, it wasn't written by a cognitive scientist - it was written by a software engineer citing cognitive scientists, and I'm unconvinced she has the cognitive science background to accurately map theory to practice. Not long into the book, the author presents a snippet of Java code and discusses it for two pages, ending with "And I'm guessing you didn't even notice that the main function's identifier was misspelled mian!"

Lady, that is the first thing I noticed. That is the only thing I noticed. I spent two pages wondering if you were gaslighting me, or pranking me, or your editing was just that bad. So I decided to put the book down. Felienne Hermans might have found some cognitive science papers that she feels describe her "Programmer's Brain," but she clearly has no idea how mine works.