Reading Notes Q1 2024: Rethinking Risk, Identity, and Better Decisions
How diving into systemic risk, cognitive flexibility, first-principles survival engineering, and Alan Watts transformed my perspective on software architecture and engineering decisions.
During the first quarter of 2024, our engineering team was navigating significant architectural transitions: adopting Swift 6 concurrency, integrating our first production AI features, and redesigning our iOS core networking stack.
In periods of high technical ambiguity, reading outside your immediate domain acts as a mental palette cleanser. The five books I finished in Q1 spanned Eastern philosophy, financial crisis history, hard science fiction, and organizational psychology.
Despite their radically different genres, they converged on a singular theme: how to navigate systemic risk and make resilient decisions when the operating environment is inherently unpredictable.
Here are my key notes from that quarter and how they influenced our engineering execution.
1. Systemic Fragility: Too Big to Fail by Andrew Ross Sorkin
Andrew Ross Sorkin’s minute-by-minute account of the 2008 financial collapse is often read as Wall Street drama. For a systems architect, it reads as a masterclass in cascading systemic failure.
The financial crisis occurred not because a single bank made a mistake, but because hidden, tightly coupled dependencies created an invisible domino chain. When Lehman Brothers collapsed, counterparty risk paralyzed institutions that thought they were completely insulated.
In modern software engineering, we build systems with identical hidden fragilities:
- An iOS app that depends on six third-party analytics SDKs.
- A critical checkout flow that depends synchronously on a remote LLM endpoint.
- Microservices that share a single relational database connection pool without bulkhead isolation.
Reading Too Big to Fail led directly to our Bulkhead Architecture Rule: No third-party service or AI endpoint is ever allowed in the synchronous critical path of a core user interaction. If an external dependency fails or times out, the app must degrade gracefully into an offline or cached state without blocking the user.
2. Relentless First-Principles Problem Solving: The Martian by Andy Weir
When astronaut Mark Watney finds himself stranded on Mars with limited food, damaged oxygen scrubbers, and no communications, he doesn’t panic or look for magical shortcuts. He states his operating philosophy simply: “You solve one problem, and then you solve the next one, and then the next. And if you solve enough problems, you get to come home.”
In engineering leadership, complex outages and daunting technical migrations often cause organizational paralysis. Teams get overwhelmed by the sheer scale of the challenge.
The Martian serves as a great reminder of first-principles decomposition:
- Break massive multi-month migrations into isolated, testable 3-day milestones.
- When an elusive production crash occurs, isolate variables systematically using binary search and telemetry rather than guessing.
- Do the math on memory allocations and token budgets upfront before writing speculative code.
3. Cognitive Agility: Think Again by Adam Grant
In Think Again, Adam Grant explores why smart people often fail: they operate like preachers defending their dogma, prosecutors proving others wrong, or politicians seeking approval, rather than like scientists testing hypotheses.
The faster technology evolves, the shorter the half-life of your technical convictions:
- The design pattern that was optimal for UIKit in 2018 is an anti-pattern in SwiftUI with Swift 6 actors in 2024.
- The prompt engineering pattern that worked for GPT-3.5 is completely obsolete for Claude 3.5 or modern on-device Core ML models.
Adopting a “think again” mindset in engineering means actively seeking out disconfirming evidence. In our design reviews, we explicitly designate a rotating engineer to argue the counter-case against major technical proposals to uncover blind spots before code is written.
4. Systems Thinking and Boundaries: The Book by Alan Watts
Alan Watts’s The Book: On the Taboo Against Knowing Who You Are challenges the Western illusion that an individual is an isolated ego encapsulated in a bag of skin, fundamentally separate from the external world. Watts shows that an organism and its environment are a single, continuous, unified process.
In software architecture, inexperienced developers view a module or function as an isolated box. Senior architects recognize that code and its environment (network conditions, memory pressure, user mental state, battery life, operational telemetry) are inextricably linked.
When we write software, we are not just arranging bytes in memory; we are shaping a dynamic feedback loop between the human mind and the computing device.
Summary
Durable engineering leadership is rarely about having all the answers on day one. It is about building resilient systems that survive unexpected shocks (Too Big to Fail), breaking daunting obstacles into solvable steps (The Martian), holding convictions lightly (Think Again), and designing with holistic context (Alan Watts).
When you pair disciplined technical skills with broad mental models, you make calmer, higher-quality decisions that compound over years.