Uses
The personal operating system behind the work
Not a gadget list. The methods, models, and tools I actually rely on to learn, think, and design systems that survive complexity.
How I learn
Toward the source
Learning, for me, is a loop of reading primary material, building something small to test it, and writing to find the gaps. The order matters less than the honesty of each step.
Read the source, not the summary
I go to primary material - papers, RFCs, the actual codebase, the original argument - before reaching for anyone's distillation of it. Summaries are useful maps, but they hide the trade-offs that matter most.
Build to understand
I do not believe I understand a system until I have rebuilt a small version of it. A throwaway prototype teaches more in an afternoon than a week of reading. Most of what I keep starts as something I threw away.
Write to find the gaps
Writing is how I discover what I do not actually know. If I cannot explain a decision in plain prose, the decision is not finished. Half my essays began as attempts to convince myself of something I turned out to be wrong about.
How I think
Three habits
The same instincts show up in every problem I work on. They are less rules than defaults I have to consciously override when a situation calls for it.
Start from the failure mode
Before designing how something should work, I describe in detail how it will fail - at scale, under compliance, when the people who built it have left. The failure mode is the real spec.
Separate the decision from the implementation
Most arguments about tools are actually arguments about decisions no one wrote down. I try to surface the decision first, record the rationale, and only then choose the mechanism that serves it.
Optimize for the second reader
The first reader of any system is the person who built it. The second reader is everyone who inherits it. I design for the second reader - the one who has to understand a choice they did not make.
How I design systems
Principles that hold under pressure
Architecture is the set of decisions made before any tool is chosen. These are the ones I return to when the trade-offs get hard.
Context is infrastructure
Decisions, rationale, and constraints are durable assets, not disposable conversation. I capture them as first-class data, not as comments that rot.
Legibility over cleverness
A system someone can reason about beats a system that is marginally faster but opaque. I would rather be obvious than impressive.
Govern at the boundary
Accountability, provenance, and access belong at the interfaces between systems - designed in from the start, never bolted on after an incident.
Reversible by default
I bias toward decisions that are cheap to undo. The few that are not get the scrutiny they deserve, and a written record of why we crossed the line.
Tools & stack
What I actually reach for
Deliberately boring where it can be, sharp where it counts. Tools are downstream of decisions - these earn their place by staying out of the way.
Editor & environment
- Editor
- VS Code with a deliberately minimal extension set, plus Vim bindings for muscle memory
- Terminal
- A tiling setup with tmux; most of my work happens close to the shell
- Notes
- Plain Markdown in a git-versioned vault - decisions and rationale live next to the code
Languages
- TypeScript
- Default for anything with an interface or a contract - types are the cheapest documentation that cannot lie
- Python
- Data, modeling, and AI orchestration; the lingua franca of the systems I integrate with
- SQL
- I write it by hand. Understanding the query plan is understanding the system
Cloud & platform
- Infrastructure
- Infrastructure as code, immutable where possible, with provenance on every change
- Data
- Event logs as the source of truth; derived views downstream
- Observability
- Tracing and decision records treated as core telemetry, not afterthoughts
AI tooling
- Models
- Frontier and open models chosen per task - capability matters less than how legibly the output can be governed
- Orchestration
- Retrieval and context pipelines I can inspect end to end, never a black box
- Evaluation
- Written evals before deployment; I do not ship judgment I cannot measure
Mental models
The lenses I keep close
A small set of models does most of the work. I distrust collecting them for their own sake - these are the few I find myself reaching for again and again.
Systems mirror the communication structure of the organizations that build them. Architecture is, in large part, a social decision.
The first-order result of a change is rarely the one that matters. I trace at least one level past the obvious before committing.
Before removing something that looks pointless, I make sure I understand why it was put there. Most legacy is a decision I have not yet reconstructed.
Every model omits something. I stay alert to the moment my abstraction stops describing reality - that gap is where the failures live.
When the future is uncertain, the right move is often the one that keeps the most doors open at acceptable cost.
Making a system easier to see can make it easier to break. I weigh what I am simplifying against what that simplification removes.
Decision frameworks
How choices get made
Good decisions are mostly a matter of process, not brilliance. These three steps cover the large majority of what I have to decide.
Reversible or not
The first question on any decision: can we undo this cheaply? Reversible decisions get made fast and low. Irreversible ones get written down, reviewed, and slowed deliberately.
Decide at the last responsible moment
I commit when the cost of waiting starts to exceed the value of new information - not earlier out of anxiety, not later out of avoidance.
Write the decision record
Every consequential choice gets a short record: the context, the options, the rationale, and what would make us revisit it. The record is the deliverable, not the meeting.
Books that shaped me
A short shelf
The handful that changed how I see the work, rather than just informing it. A fuller reading list lives in the library.
Thinking in Systems
Donella Meadows
The clearest grounding I know in feedback loops, stocks, and leverage points.
The Design of Everyday Things
Don Norman
Affordances and failure attribution - why good design makes the right action obvious.
Seeing Like a State
James C. Scott
On the cost of legibility, and what gets erased when systems are made simple to govern.
High Output Management
Andrew Grove
Leverage, decision-making, and treating output as a function of the system, not the effort.
The Pragmatic Programmer
Hunt & Thomas
The craft attitude that still underwrites how I write and maintain code.
Antifragile
Nassim Taleb
Optionality, convexity, and designing for systems that gain from disorder.