The books doing quiet work in every decision.

The clearest argument I know for why complexity is the enemy, not a tax you just pay. Deep modules, small interfaces over real implementations underneath. BankID's sixteen-plus flow modules behind one public API are this idea applied with five banks watching.

Boundaries are linguistic before they're technical. Hamoon has two identity-proofing paths, attended and unattended, feeding one issuance pipeline. Getting that split right came from thinking about the domain first, not the code.

The non-software book I recommend to engineers most. Feedback loops, stocks, and delays explain why codebases decay, why teams thrash, and why the fix is almost never at the place the symptom appears.

The book behind how I think about Coinlocally's real-time market-data path — replication, consistency, and the honest admission that "the data is always correct" doesn't survive a burst of updates arriving faster than you can process them. Chapter by chapter it replaces folklore with mechanisms you can actually reason about.

Currently working through it. Lamport’s discipline — state the system as mathematics, then check your beliefs — is the formal version of what my simulation harnesses grope toward. Humbling, in the productive way.

Read early, absorbed permanently. Tracer bullets, broken windows, and "don't live with a broken build" shaped my defaults years before I could defend them theoretically.

Less about code than about what you owe the people depending on it. The chapter on saying no is why the honest answer to Hamrah Card's Apple account outage was "here's a Flutter fallback and a real timeline," not a promise I couldn't keep.

Made changing code a discipline instead of a mood: small verified steps, behavior held constant, tests as the ratchet. Coinlocally's Objective-C-to-Swift migration and Saraf's ongoing MVVM-C rebuild are both this book, run for months on a live app.

Most engineering happens inside systems you didn't design. Saraf still compiles a 226-file legacy tree alongside the new architecture while it's replaced one flow at a time — seams and characterization tests, not a rewrite, got it there.

The inside view of how Apple actually decides: working demos over documents, taste applied through iteration, small teams with real authority. It reset my bar for what “review” should mean — show the thing, not the plan for the thing.

Leader-leader instead of leader-follower: push authority to where the information is, and build competence so the authority is safe there. It’s why my design reviews teach reasoning instead of issuing verdicts.

Engineering management treated as systems engineering — queues, constraints, and org design as architecture. It gave me the vocabulary for something I kept observing: the module graph and the org chart converge.

Fifty years old and still the most accurate book about software schedules ever written. Conceptual integrity — one coherent design mind, however many hands — is the oldest argument for the architect’s job existing at all.

Affordances, feedback, and the insistence that user error is usually designer error. I apply it to APIs more than interfaces: a method signature is a door handle, and if integrators keep pushing the pull door, the door is wrong.