~/books

Halfway through. Nike’s origin story is much more precarious and interesting than the polished brand mythology suggests. Knight was making it up as he went for a very long time — undercapitalised, dependent on a Japanese shoe company that could cut him off at any point, running payment schemes that would make a CFO blanch.

What stands out so far: the description of the early team and the energy of building something from genuine conviction rather than investor pressure. Also the sections about Japan — the culture, the relationships, the way of doing business — are vivid in a way that most business memoirs avoid.

Will update this when I finish.

Picked this up on the recommendation of three different people in the same week, which is usually a signal worth heeding. They were right.

Project Hail Mary is the best science fiction I’ve read in some years. The premise is clever without being gimmicky, the science is genuinely interesting without being a lecture, and the protagonist — a scientist who wakes up with amnesia aboard a spacecraft on a mission he can’t remember — is immediately likeable in a way that feels earned rather than manufactured.

I won’t say much about the plot because the less you know going in, the better. But I will say: the middle third of the book is one of the most joyful reading experiences I’ve had in a long time. Somewhere between problem-solving, optimism, and something harder to name.

Andy Weir does “engineer-type protagonist solving hard problems with first-principles thinking” better than almost anyone. If you enjoyed The Martian you’ll love this. If you didn’t read The Martian — read that too, and then read this.

Ousterhout’s central argument is that complexity is the root of all evil in software, and that the way to manage complexity is to design interfaces that are deep: simple on the outside, hiding hard problems underneath. The opposite — “shallow” modules with complex interfaces and trivial implementations — is what makes systems hard to work in over time.

The “deep vs. shallow module” framing has become part of my design vocabulary. When reviewing a PR, I now notice when a module has a complex interface that effectively leaks its implementation details. The red flag isn’t length or lines of code — it’s interface complexity relative to what it actually provides.

I don’t agree with everything here. The advice to comment almost everything sometimes conflicts with the “clean code” school of thought that favours self-documenting code. But the core message — that you should be actively designing to reduce complexity, and that complexity has a cost that accumulates — is important and often under-emphasised.

Shorter than most software books. Could probably be read in a weekend. Worth it.

This is the book I wish I’d read in my first year of professional software development. Not because it would have made me immediately better — I’m not sure I had the experience to absorb all of it yet — but because it would have given me vocabulary for patterns I was already encountering without being able to articulate clearly.

The 20th anniversary edition holds up remarkably well. The specific languages and tools have changed but the underlying advice hasn’t: care about your craft, own your mistakes, invest in your tooling, don’t repeat yourself, build software that’s easy to reason about. These are timeless.

The “broken windows” metaphor has genuinely changed how I approach codebases. Letting one piece of the system be messy creates permission for everything else to follow. Conversely, keeping things clean has a compounding effect on quality.

My most-returned-to sections: the DRY principle (not just about code, about knowledge), the “tracer bullets” approach to architecture, and the chapter on working with domain languages. Highly recommended for anyone who wants to think more deliberately about software as a craft.

I keep seeing this referenced in engineering leadership discussions. Larson’s approach to systems thinking for engineering management — team sizing, technical debt, migrations, succession planning — seems practical and grounded in experience rather than theory.

On my list for when I’m closer to a staff/lead role.