Swift's Actor Model vs Rust's Ownership: Why Rust Doesn't Need Actors

2026-07-19T00:00:00+00:00

Two Kinds of Thread Safety</h2>
The first thing worth separating is that "thread safety" is really two different properties, and Swift and Rust attack them at different layers. The first property is data-race freedom (no two threads touch the same mutable memory at once without synchronization). The second is isolation (a unit of concurrency owns its state, and nothing else can reach into it).
Rust guarantees data-race freedom with essentially no runtime concept of an actor. Swift's actors are a mechanism aimed at isolation, and they get data-race freedom as a consequence. That asymmetry is the root of almost everything that feels off to me. Rust weaves safety into the type system uniformly, so every type carries its own thread-safety story. Swift attaches safety to a reference type (the actor) that lives inside a language rich with shared, mutable class references. Both are reaching for the same summit; they just start their climb from very different base camps.
Why Rust Reaches Safety Without Actors</h2>
Rust's data-race freedom falls out of ownership and borrowing</a> plus two marker traits, all checked at compile time. The starting point is that access permissions are encoded directly in the types. For some type `T</code>, you work with three forms: T</code> is an owned value, &mut T</code> is an exclusive (unique) mutable borrow, and &T</code> is a shared, read-only borrow. Ownership means T</code> is yours; &mut T</code> means you have the only handle that can mutate it right now; &T</code> means you are one of possibly many readers.`
`The foundation is a single rule the borrow checker enforces on those forms: at any moment you can have many shared references (&T</code>) or exactly one mutable reference (&mut T</code>), never both, and never two &mut T</code> at once. The Rust Book spells this out in its chapter on`references and borrowing</a>. A data race requires aliasing and mutation and concurrency together, so by statically forbidding the aliasing-plus-mutation combination, Rust makes the race impossible before threads even enter the picture. Two more guarantees round this out: every reference carries a lifetime</a> and cannot outlive the T</code> it points to (so you can never hold a dangling reference), and each owned value is freed exactly once</a> when its single owner goes out of scope (so there is no double-free). The effect is that you must prove to the compiler you have no data races before your program will build.
`A direct consequence is that Rust will not let you mutate a value through a shared &T</code> at all. If you want to share something across threads and still change it, you have to reach for an explicit synchronization type, and the type system will insist on it.`
A Mutex<T></code></a> hands out access to one writer at a time; a RwLock<T></code></a> models the multiple-readers, single-writer pattern, granting many concurrent read guards (which behave like &T</code>) or a single exclusive write guard (which behaves like &mut T</code>), but never both at once. These types move the "shared XOR mutable" check to runtime while preserving exactly the same invariant the borrow checker enforces at compile time, and because they are Sync</code> the compiler can then let the wrapped value be shared safely. The rule never bends; you simply choose where it is enforced.
`On top of that, Rust adds two auto-derived, compositional traits.`Send</code></a> means a type can be moved to another thread, and Sync</code></a> means a shared reference to it can be used from multiple threads. These propagate automatically through every type: Rc<T></code> is not Send</code> because its reference count is non-atomic, while Arc<T></code> is Send</code> because its count is atomic. The Rustonomicon chapter on Send and Sync</a> walks through exactly how the compiler derives and checks this. When you hand a value to another thread through a channel</a>, ownership transfers and the sender can no longer touch it.
`The Rust community has a name for the result of all this working together: fearless concurrency</a>. Because the ownership and borrowing rules that already keep single-threaded code memory-safe are the very same rules that rule out data races, adding threads does not require a new mental model, and a large class of concurrency bugs becomes a compile error rather than a rare production crash.`
That transfer point is where I have to correct my own intuition. I used to describe Rust's safety in terms of copies, as if independence came from duplicating data. The mechanism that actually makes Rust both safe and cheap is a move that invalidates the source</a>, not a deep copy. Nothing is duplicated; ownership simply relocates, so there is no performance penalty and no size limit. My worry about "structs too big to copy" mostly dissolves once I think in moves instead of copies. So Rust gives you per-unit isolation exactly when you want it (channels, Mutex<T></code>, thread-local ownership) without ever imposing an actor runtime. Actors in Rust exist only as an optional library pattern, such as Actix</a>, because the language already provides the guarantee that actors elsewhere provide at runtime.
The Monumental Task Swift Took On</h2> Here is where I want to be fair, because it is easy to critique a result without honoring the pursuit. Swift set out to add strict, safe concurrency to a language that was already mature, already shipping in billions of devices, and already committed to seamless interoperability with C and C++</a>, reference-semantics classes, automatic reference counting</a>, and a stable ABI. Retrofitting compile-time data-race safety onto that foundation, and doing it progressively so existing code keeps working, is one of the more ambitious language-evolution efforts I have watched unfold. The Swift 6 migration path</a> lets teams opt into complete concurrency checking incrementally rather than through a single breaking cutover, which is a remarkable amount of care for real-world codebases. That care is exactly what shapes the design, and it is where I would gently push back on my own earlier framing. It is tempting to say the language "insists" on shared references or "will not give up" C compatibility, but that anthropomorphizes a set of deliberate engineering priorities. The Swift team chose to preserve reference semantics, ARC, and C and C++ interoperability because those choices serve the platform's users, and safety then had to be built on top of that substrate rather than baked into its core. Given that starting point, Sendable</code></a> has to exist as a separate, viral constraint (defined in SE-0302</a>), because an actor</code></a> is a reference type whose guarantee is only that access to its mutable stored properties is serialized through its executor. The actor boundary is only as strong as the Sendable</code>-ness of what crosses it, which is why the actor reads to me as a serialization point rather than a fully sealed environment. The pieces that make this work are genuinely clever, not incidental complexity. Region-based isolation</a> (SE-0414) lets the compiler prove that a non-Sendable</code> value is disconnected from every other region, so it can be transferred into an actor safely without full ownership tracking, and sending</code> parameters</a> (SE-0430) build directly on that analysis. Swift is even importing ownership ideas the language did not start with, through noncopyable types</a> (~Copyable</code>, SE-0390) and the borrowing</code> and consuming</code></a> modifiers (SE-0377). These features land in the middle of an existing model, so they feel additive rather than foundational, but each one is a considered step toward the same safety Rust gets from its base. It is worth noticing that Swift's own concurrency proposals describe an actor as an "island of single-threadedness" with a mailbox as its synchronization point, echoing the classic actor model</a>. Systems like Erlang</a> get strong isolation because messages are copied or immutable, so no shared references escape. Swift kept the serial-executor mailbox but not the isolation-by-value, which is a reasonable call on a platform like iOS where cheap process-per-actor isolation is not available and the whole app is a single sandbox. The Trade-off, Named</h2> So what is the trade-off, stated plainly? Swift chose ecosystem continuity (existing code, C and C++ interop, ARC, ABI stability) and is buying back compile-time concurrency safety on top of it through Sendable</code>, region analysis, and move-only types. Rust chose ownership as its foundation and gets data-race freedom uniformly and for free, at the cost of a steeper up-front model and no seamless C++ object interop of Swift's kind. Neither choice is misguided; they optimize for different things. Swift's actor model delivers serialized access and a strong, best-effort isolation boundary, and Swift 6 genuinely catches data races, which is a real and hard-won result. What it does not (yet) offer is Rust's uniform, type-level guarantee, because that would require ownership at the core rather than as an opt-in layer. The interesting part is that the opt-in layer already exists in pieces. Noncopyable types, consuming</code> and borrowing</code> ownership, @Sendable</code> closures, and complete strict-concurrency checking together add up to something close to a stricter dialect of Swift, just delivered as gradual, composable constraints instead of a separate mode. That progressive path is the whole point: rather than a single dramatic break, Swift is tightening the guarantees one proposal at a time, letting an enormous body of existing code move forward at its own pace. Rust reached safety by designing for it from day one; Swift is reaching for the same safety while carrying a decade of compatibility on its back, and it is getting there in careful, deliberate steps. Rust does not need actors because ownership, Send</code>, and Sync</code>, plus move-by-default, make data races a compile error at the type level, uniformly. Swift's actors serialize access on top of a shared, C-compatible core, so full isolation has to be rebuilt progressively with Sendable</code>, regions, and move-only types. The more I sit with it, the less this looks like a shortcoming and the more it looks like the tax of backward compatibility being paid down honestly, one release at a time. It rhymes with what I found in My Swift Journey</a> and in Language Choice in the LLM Era</a>: Swift keeps making sound engineering choices under real constraints, and the pursuit of strict, safe concurrency on a mature language is worth admiring even where it has not yet caught up to a language that started from ownership. The trade-off is not that Swift got it wrong; it is that it chose to bring everyone along, and that is a harder road. Sources</h3> Source</th> Link</th></tr></thead> actor</code> — Apple Developer Documentation</td> developer.apple.com</a></td></tr> Sendable</code> — Apple Developer Documentation</td> developer.apple.com</a></td></tr> SE-0306: Actors</td> swift-evolution</a></td></tr> SE-0302: Sendable</code> and @Sendable</code> closures</td> swift-evolution</a></td></tr> SE-0414: Region-based isolation</td> swift-evolution</a></td></tr> SE-0430: sending</code> parameters and results</td> swift-evolution</a></td></tr> SE-0390: Noncopyable structs and enums (~Copyable</code>)</td> swift-evolution</a></td></tr> SE-0377: borrowing</code> and consuming</code> parameter ownership modifiers</td> swift-evolution</a></td></tr> Swift 6 Migration Guide (data-race safety and strict concurrency)</td> swift.org</a></td></tr> Automatic Reference Counting — The Swift Programming Language</td> docs.swift.org</a></td></tr> Mixing Swift and C++ — Swift.org</td> swift.org</a></td></tr> What Is Ownership? — The Rust Programming Language</td> doc.rust-lang.org</a></td></tr> References and Borrowing — The Rust Programming Language</td> doc.rust-lang.org</a></td></tr> Message Passing / channels — The Rust Programming Language</td> doc.rust-lang.org</a></td></tr> Fearless Concurrency — The Rust Programming Language</td> doc.rust-lang.org</a></td></tr> Validating References with Lifetimes — The Rust Programming Language</td> doc.rust-lang.org</a></td></tr> Running Code on Cleanup with the Drop</code> Trait — The Rust Programming Language</td> doc.rust-lang.org</a></td></tr> std::marker::Send</code> — Rust standard library</td> doc.rust-lang.org</a></td></tr> std::marker::Sync</code> — Rust standard library</td> doc.rust-lang.org</a></td></tr> std::sync::Mutex</code> — Rust standard library</td> doc.rust-lang.org</a></td></tr> std::sync::RwLock</code> — Rust standard library</td> doc.rust-lang.org</a></td></tr> Send and Sync — The Rustonomicon</td> doc.rust-lang.org</a></td></tr> The Rust Programming Language (official site)</td> rust-lang.org</a></td></tr> Actix (actor framework for Rust)</td> actix.rs</a></td></tr> Actor model — Wikipedia</td> wikipedia.org</a></td></tr> Erlang (official site)</td> erlang.org</a></td></tr> </tbody></table> Burnout Is a Control Problem, Not an Hours Problem 2026-07-13T00:00:00+00:00 More than a decade ago I burned out, and burned out badly. I need to say something up front that I wish someone had made me believe earlier: burnout is real, it is terrible, and it is physical. I did not think it was a real thing until it happened to me. I assumed it was a figure of speech, a dramatic word for being tired, something you pushed through. It is not. It is a physical reaction that happens to you, and when it arrives it can become almost impossible to do anything at all. Plenty of people have written about this, and I suspect most descriptions still undersell how real it is. I would not recommend it to anybody. I remember watching my own productivity fall off a cliff and not understanding why, because on paper I was working harder than ever. It was long hours for months at a time. It was travel, weeks away at a stretch. It was not feeling financially free, and it was missing the three things that make work gel (mastery, autonomy, and a purpose I believed in). The obvious story is that I worked too many hours and my body gave out. I no longer think that is the whole story. The quest here is to figure out what actually broke, because the hours turned out to be a symptom of something else. It Was Never Just the Hours</h2> Start with the hours, because that is the story everyone reaches for first. Physical work degrades honestly and linearly: swing a hammer for sixteen hours and you get tired in a predictable way. Mental work does not behave like that. Anyone can sit at a desk for sixteen hours, and I have, for long stretches, but I would not call all sixteen of those hours productive and I do not think anyone honestly would. At some point it stops being a question of hours and becomes a question of health: how much sleep did you trade away, how much coffee are you burning to hold the line the next morning, and how much of that time was real, deliberate thinking versus going through the motions on autopilot. The raw hour count is a bad proxy for what is actually happening to you. If it was not the hours, the temptation is to blame the difficulty of the work itself, and that is closer but still wrong. Genuinely hard work is tiring, but tiring is not the same as burning out. Looking back, the long hours, the constant travel, the financial pressure, and the missing mastery, autonomy, and purpose (an absence I unpack in Find Your Why</a>) were not four separate causes. They were four faces of one cause. What they had in common was that I had stopped deciding where my own time went. Stress Comes From Lost Control</h2> In a 2001 speech, Jeff Bezos said something that has stuck with me: "Stress primarily comes from not taking action over something that you can have some control over." I think he is right, and I think it generalizes well past work. The stress of my burnout did not actually come from the work itself. It came from everything the work made impossible. Working and sleeping and nothing else means the family gatherings you miss, the personal things you keep postponing, the movie you never get around to seeing. That is where the stress lived: not in the hours I spent, but in the control I had surrendered over where my time went. I had given all of it to one thing and lost the ability to steer any of the rest. That reframes burnout as a control problem rather than an hours problem, and it lines up with something I have written about the Quest Engine's</a> three forces. In Quest Engine: The Why</a>, I described burnout as a failure of Renewal, the moment the connection between effort and meaning severs because you never surface from execution to check that the work still matters. I still think that is right, and I think the control frame is the same failure seen from a different angle. Losing control over your time is precisely how the thread back to meaning gets cut: you are so fully committed to one thing that you cannot renew, cannot step back, cannot ask whether this is still the thing worth doing. Autonomy (owning the shape of your time) and Renewal (verifying the work still connects) are the two forces that go quiet together, and burnout is what their silence sounds like. Buy Back the Slack</h2> If burnout is lost control over time, the fix is not simply "work fewer hours," it is regaining ownership of where the hours go. Some of that is the background-brain</a> argument (creative work has a daily ceiling past which more hours are detrimental), but the deeper move is refusing to spend all of your time on a single thing, because that is what strips away control in the first place. The stress I felt was not really about work being present, it was about everything else being absent, crowded out until my calendar had exactly one owner and it was not me. Buying back even a little slack (an evening, a weekend, the movie, the gathering) is not a reward for finishing the work. It is the thing that keeps the work from consuming the person doing it. Burnout wore the costume of overwork, but underneath it was a control problem. The hours were a symptom, the difficulty was a red herring, and the real damage was losing the ability to decide where my own time went. That is why the fix is not discipline or more caffeine but the return that the Quest Engine</a> calls Renewal: step back often enough to keep owning your time, and protect the slack that lets you be more than the one thing you are working on. You do not avoid burnout by controlling the work. You avoid it by keeping control of your life around the work. The Background Brain: Why Boredom Makes Ideas 2026-07-13T00:00:00+00:00 Some of my best ideas never arrived while I was working on the problem. They arrived after I had stopped, sometimes days after, when I had given up for the afternoon and gone for a walk or stood in the shower thinking about nothing in particular. The solution I had been grinding for was suddenly just there, fully formed, as if some part of me had kept working after the rest of me clocked out. The quest here is to take that experience seriously instead of treating it as luck, because three books I have read make the same claim from three directions: the interesting work happens in the background, and the way to get more of it is not to work more. The Background Brain</h2> Learning How to Learn (Barbara Oakley) draws a line between two modes: focus mode and diffuse mode. Focus mode is you at the desk, attention locked on the problem, deliberately grinding. Diffuse mode is what happens when you step away, when your mind is loose and wandering and apparently doing nothing at all. The counterintuitive part is that a lot of real learning, and almost all of the surprising connections, happen in diffuse mode. The brain keeps running computations in the background while you think you have stopped. This is why the Eureka moment arrives on a walk, in the shower, or right as you fall asleep, and almost never while you are staring the problem down. The solution was being assembled the whole time, just not by the part of you that was watching. This maps almost cleanly onto Kahneman's Thinking, Fast and Slow. The book splits the mind into two systems, and it is worth stating them plainly because the names alone do not tell you which is which: System 1 is fast, intuitive, and emotional, while System 2 is slower, more deliberative, and more logical. System 2 is slow, deliberate, effortful, and expensive (that is focus mode at the desk). System 1 is fast, automatic, and always running underneath (and diffuse mode is System 1 given room to work without System 2 crowding it out). I have written before about how skills migrate downward from System 2 into System 1 in The Bicycle of the Mind</a>; this is the other half of that idea. It is not only that practice compiles skills into cheap reflexes. It is that the downstairs machinery keeps solving problems on its own once you feed it the material and then get out of its way. The diffuse network (what neuroscience calls the default mode, the state the brain drops into when it is not doing anything you can point to) is not idle. It is running. Boredom Is the Doorway</h2> If the background brain does the interesting work, then boredom is not wasted time. It is the doorway. Diffuse mode needs a quiet, unfilled stretch to make its connections, and boredom is exactly that stretch. When every gap gets filled (a phone, a feed, another meeting, another tab) the background brain never gets the silence it needs, and the ideas that would have come from nowhere simply never come. The empty afternoons I used to treat as unproductive were the ones actually generating the ideas I valued most. Protecting boredom is protecting the conditions under which the best thinking happens. This is worth being precise about, because in some of my other writing boredom shows up as a warning sign. In Find Your Why</a>, feeling bored at work is the symptom of mastery going quiet, of the work no longer teaching you anything, and in the Quest Engine</a> too-easy work drops you out of flow into boredom. Both of those are true, and they are a different thing from what I mean here. There is a difference between being chronically bored by your work (a signal something is wrong) and deliberately allowing an unfilled, restful gap around your work (the raw material of new ideas). The first is a problem to fix. The second is a resource to protect. The mistake is filling every quiet moment so aggressively that you never get the generative kind of boredom at all. It helps to separate three very different things that all get called boredom. The first is generative boredom: "I am bored, so let me figure out how to get out of this." Bill Gates is famously quoted as saying he would choose a lazy person to do a hard job, because a lazy person will find an easy way to do it. That kind of laziness, and this kind of boredom, are not about avoiding work. They are about refusing to do work the hard, repetitive way when a smarter way exists. When a task is too simplistic, offers nothing to learn, and can be automated, the boredom is a signal you care enough to build a tool and climb out of the hole. You deploy your mind against the boredom, and the escape route (the automation, the abstraction, the reusable thing you build) is often more valuable than the task you were avoiding. The second is dead-end boredom: "I am bored, and I genuinely do not want to do this anymore." That is not a prompt to build a tool, it is honest information that the work no longer fits you, and it belongs with the mastery-gone-quiet signal above. The third is the worst kind, blocked boredom: "I am bored, I can see the way out, and I am not allowed to take it." The manual, mind-numbing task has to be done fast, and politics or security or some other constraint means nobody will give you the time to explore automating it. Generative boredom turns into frustration precisely when the escape hatch exists but you are barred from opening it. The lesson is not "avoid boredom," it is to tell these three apart: protect the restful kind that feeds diffuse mode, follow the generative kind toward better tools, listen to the dead-end kind, and fight to unblock the third. Why More Hours Can Make Creative Work Worse</h2> All of this leads somewhere practical, which is that the value of an extra hour depends entirely on the kind of work you are doing. If the work is mechanical, repetitive, or the sort of thing that could eventually be automated, then more hours are more output, close to linearly. Sit longer, produce more. There is no creative ceiling to hit because there is nothing creative being asked of you. Creative work does not behave that way. When the task is genuinely difficult and depends on new ideas, working past a certain point each day is not neutral, it is detrimental, because the extra focus-mode hours come directly out of the diffuse-mode time the ideas actually needed. You are not just getting diminishing returns, you are cannibalizing the background process that would have produced tomorrow's insight. This is the core of Cal Newport's Slow Productivity: The Lost Art of Accomplishment Without Burnout. Anyone can sit at a desk for sixteen hours, and I have done it, but I would not call all sixteen of those hours productive, and past the ceiling the marginal creative hour returns almost nothing while quietly stealing from the rest that consolidates what you already did. Giving yourself more time to learn something, and more time to come up with something, is not laziness and it is not a concession. For creative work it is the mechanism that produces the output at all. Three books, one idea. Learning How to Learn says the background brain solves what focus cannot. Thinking, Fast and Slow says that background is System 1, always running when you give it room. Slow Productivity says the creative output you care about depends on protecting that background rather than drowning it in hours. Put together, they explain why some of my best ideas came from stopping, and why the honest answer to "how do I have more good ideas" is often to schedule less, not more. The lever, as always in the Quest Engine</a>, is renewal: guard the boredom, protect the quiet, and let the downstairs machinery do the work you cannot force. The Eureka was never going to come at the desk anyway. Shift Left Until the PR Is Just a Confirmation 2026-07-10T00:00:00+00:00 I have been watching my own pull request queue change shape over the last year. It used to be that writing the change was the slow part and review was a quick nod at the end. Now the ratio has flipped. Agents help me produce changes faster than anyone can read them, so more pull requests land in the queue than ever, and the queue backs up not at authoring but at review. The bottleneck moved. If code is cheap to produce, the scarce thing is no longer the code. It is the trust that the code is correct. So the question I keep chasing is this: how do we make a change cheap to trust, not just cheap to write? The reflexive answer floating around is to point another agent at the pull request and have it review. That helps at the margins, and I use it, but I do not think it is the main move. A reviewing agent gives you an opinion, and an opinion (human or synthetic) is a probabilistic thing. What actually earns trust is proof: an environment that demonstrates the behavior of the change by running it. The reframe I keep coming back to is about where the engineering effort should go. Instead of spending it in the review cycle (making PRs move faster, adding another reviewer, tuning the queue), spend it ahead of time building the environment that validates the change. Once that full end-to-end validation exists, the cost flips: running it is cheap, and reviewing a change that has already been verified is cheap too, because the hard proof is already done by the time anyone looks. The review bottleneck is a trust problem</h2> There are only two ways to believe a change is safe. You can form a judgment about it, or you can watch it run and prove it. Judgment is what a reviewer does when they read a diff and reason about what it probably does. Proof is what an environment does when it executes the change against real pathways and shows you the result. Judgment scales badly (it is bounded by human attention, and a second agent giving an opinion does not remove that bound, it just adds another opinion). Proof scales differently: it is front-loaded. Compute is not free and it is not getting cheaper, so the win does not come from throwing more of it at the problem. It comes from paying the construction cost once (building the synthetic environment) and then running it as many times as you like for very little. The rigor lives in the environment, not in the individual run. The analogy I keep reaching for is a mathematical proof. The statement can be a single line, but the proof behind it runs for pages, and it is the pages that make the one line trustworthy. A validated change is the same shape. The diff is short, but the rigor that makes it safe (every path exercised, every dependency stood up, every real scenario replayed) is long, and it belongs in front of the pull request, not inside it. Building that proof machinery is the priority. Once it exists, the statement it certifies becomes cheap to accept. Shift left is usually said as a direction: move testing earlier. I want to say it as a rule, because a direction with no ceiling is a trap. Pushing everything left has a cost, since the more your local setup mirrors production, the heavier and slower it gets, and that weight fights the velocity you were trying to buy. So the rule is narrower than "test earlier." Shift left the validation that is cheap to run locally and expensive to discover in production. That is the validation worth pulling all the way back to the inner loop: not just unit tests (those already run everywhere) but the integration and end-to-end pathways that today only light up after the pull request, in a pipeline, in a staging environment you share with everyone else. A normal PR validation pipeline runs unit and integration tests but almost never a full end-to-end scaled environment. The goal is to make that environment cheap enough to run that it can move all the way left into the local inner loop, and cheap enough that it can even run as part of PR validation. The payoff is not abstract. The cost of a defect scales roughly with how late you catch it (a bug caught in the local inner loop costs minutes, the same bug caught in production costs an incident, a rollback, and a postmortem). Every rung you move validation earlier is a strict reduction in that cost. And there is a second payoff that matters just as much: when the full gate has already run locally, the pull request stops being the approval mechanism. It becomes a context-sharing mechanism, a place where other people learn what changes are coming, rather than the gate where correctness is decided for the first time. The gate has moved all the way left. The ladder of fidelity</h2> Here is the concrete version of what I want. Say I have three services (A, B, and C) and I am only changing B. I should be able to stand up an environment on my own machine where A and C are present, make my change to B, and see exactly how it ripples through to A and C, before I open anything. The catch is that "A and C are present" hides a whole spectrum, and collapsing that spectrum is where most conversations about this go wrong. There is a ladder of fidelity, and each rung trades cost for trust. The bottom rung is mocking A and C (fast to stand up, cheap to run, but it only proves your change against your assumptions about the neighbors). The middle rung is running A and C as real processes in containers with seeded data (slower and heavier, but now you are exercising the actual code of your dependencies). The top rung is replaying recorded production traffic through the real neighbors (the highest fidelity, because the scenarios are ones that genuinely happened, and the highest cost to capture and maintain). Fidelity, cost, and trust all rise together as you climb. The skill is choosing the right rung for the change in front of you, not always reaching for the top. This is where .NET Aspire and Dapr are worth studying, because between them they show what a serious local inner loop looks like. Aspire is the orchestrator. It models your infrastructure dependencies (the databases, the caches, the message brokers) in type-safe application code instead of a sprawl of compose files, generates and injects the connection strings and ports automatically, and spins up a local dashboard that gives you distributed traces, structured logs, and metrics across every service out of the box (the kind of control-plane visibility you normally only get in production). Notably, the model it pushes is a lightweight orchestrated graph of containers with a control plane, not a full local Kubernetes cluster. That is the right instinct. You want production shape, not production weight, in the inner loop. Dapr is the complement, and it attacks the portability half of the problem. By running as a sidecar that your service talks to over local HTTP or gRPC, it lets your business logic stay agnostic about the infrastructure underneath (a local Redis pub/sub queue in your inner loop and a production cloud queue become a one-file swap, with the application code untouched). That is precisely what makes a local synthetic environment honest: the code path you exercise on your laptop is the same code path that runs in production, because the only thing that changed is the sidecar's configuration. It is also polyglot by construction, so a Python service, a Go backend, and a Node web app can share state and call each other locally through the same building blocks, which is what my A/B/C example actually looks like in a real system. Most systems are not built on Aspire or Dapr, and that is fine, because the principle is what transfers, not the tooling. The homegrown version of this is a discipline: every external resource your service touches (the database, the relay, the pub/sub, the cache, the object store) must have a local stand-in that behaves like the real thing. A container running the same database engine with seeded schema, an in-memory or containerized broker for the queue, a fake for the object store that speaks the same API. The point is to remove every reason you would otherwise have to deploy in order to test. "Deploy to test" is the mess this is trying to end. The moment testing a change requires pushing it to a shared environment, you have lost the inner loop, you are serializing on infrastructure other people also need, and you have made validation expensive again. Modeling all of those resources locally is the homegrown path to the same cheap, repeatable proof that Aspire and Dapr hand you out of the box. The hard part is the data (and keeping it honest)</h2> The moment you climb toward the top of the fidelity ladder, you hit the real problem, and it is not orchestration. It is data. "Replay real customer scenarios" is the crux of the whole idea and also a minefield, because real customer data carries real privacy, compliance, and personally identifiable information obligations. You cannot just copy production into your laptop. So the mechanism matters: capture production traffic and sanitize it, generate synthetic data that preserves the statistical shape of the real thing without the sensitive contents, and lean on contract tests to pin the boundaries between services so the replayed interactions stay valid. The goal is a recording of what happened that is safe to replay, not a copy of who it happened to. The second hard part is drift, and it is the one people forget. A synthetic environment that quietly diverges from production is worse than no environment at all, because it hands you false confidence (you prove your change against a world that no longer exists and ship the bug anyway). So fidelity has to be owned. Contract tests are the parity guarantee, sampled production traffic is the honesty check, and the environment has to be treated as a living system that heals and monitors itself rather than a fixture someone set up once and forgot. This is the same principle I keep landing on: build systems that keep themselves correct, and reserve human attention for the genuinely novel case. An environment you have to babysit is just another human standing in a seam. None of this removes the value of rolling changes out safely once they land. Progressive delivery, canaries, and feature flags all still matter. My argument is that we have poured enormous effort into making the right of the pipeline safe (how to roll out a change carefully after it merges) and comparatively little into making the left of it provable (how to know the change is right before it merges). The synthetic environment is how you rebalance that, by pulling the proof all the way back to the moment before the pull request exists. It also does something specific for agents: an agent is stochastic, and its output is unpredictable by nature, but a deterministic validation scheme wrapped around it makes the outcome predictable again. You cannot make the agent certain, but you can make the gate certain, and that is enough. The environment turns "the agent probably got it right" into "the change passed every path," which is the difference between a guess and a proof. The point is not to review harder, it is to arrive at the pull request with the validation already done, so the review stops being the gate and becomes a place to share context (a way for other people to learn what changes are coming) rather than the first place anyone finds out whether the change works. That reframes the whole velocity-versus-quality trade: the two stop fighting once the rigor is front-loaded into an environment instead of spent in the review cycle. This is the self-healing systems</a> idea applied to validation, the proof-over-opinion</a> distinction applied to review, and the reason fearless engineering</a> is possible at all: you move fast because the rail was built before you needed it, and the context that makes the environment reproducible is itself context as code</a>. Independent Fire 2026-07-08T00:00:00+00:00 I was watching a movie about George Washington the other night, and one small moment caught my attention far more than the big battles did. There was a phrase in the film that stuck with me: independent fire. One thing I want to flag up front is the attribution: I heard the phrase in the movie, and I cannot confirm that the real George Washington ever said it. That is the only claim I am making about the sourcing (not that the phrase is invented, just that I do not know whether Washington used it). What matters more, and is much better documented, is the tactic underneath it. The film's setup was the years in the colonies leading into the War of Independence, and the thing it kept circling was how the colonists fought. They had inherited the European way of war (tight formations, coordinated volleys fired on command, an officer calling the flanks and the rows), because that was the only model anyone knew. But that model was built for open European fields, and much of the fighting in the New World happened in trees and broken ground and cover. The old formations did not always fit the terrain, and men who stood in neat lines where the ground did not reward it paid for it. What caught me was the idea the phrase points at. Instead of an officer directing every soldier (aim here, fire now, reload, wheel left), the soldiers were free to fire independently: to read the ground, pick their own targets, and act on their own judgment. And this is where the phrase lands on real history. The Continental Army and especially the militia leaned on exactly this kind of fighting (open-order skirmishing, aimed fire, using cover and concealment, and riflemen who could pick off officers and gun crews at ranges where massed musket volleys were useless). It was a genuine departure from the rigid linear tactics the British and most European armies fought by, and it is well described in accounts of the Continental soldier</a>. So whatever the exact provenance of the words, the tactic they dramatize is real. And the reason I keep turning it over is that it is not really about muskets. Independent fire is a statement about where decision authority should live when the environment stops fitting the plan. That is the quest of this post: what "independent fire" actually is, why distributed authority beats centralized command in certain terrain, and why it is the cleanest picture I have found of how a high-agency engineering team should be allowed to operate. The Terrain Broke the Formation</h2> The British formation was not misguided. On an open European field, a wall of soldiers firing on command is genuinely the optimal design. Coordinated volleys concentrate force, the officer has a full view of the line, and the individual soldier does not need to think (he needs to be reliable and synchronized). The whole system is built on a bet: that the officer's single vantage point sees the battlefield better than any one soldier does, so decisions should flow down from that vantage point and the soldiers should be faithful extensions of it. That bet holds right up until the terrain changes. In the New World, no officer had a clean view of the whole engagement. The trees that gave the colonists cover also broke the line of sight the command model depended on. The soldier crouched behind an oak could see a target the officer could not, and by the time the order to fire traveled down the chain, the moment was gone. The formation had turned the soldier's local knowledge into wasted information, because the system had no way to act on anything the officer did not personally see. This is the failure mode worth naming precisely: centralized command does not fail because the commander is incompetent. It fails when the people at the edge can see more than the center can, and the system gives them no authority to act on it. The formation was optimized for a world where the center had the best information. The New World was a world where the edge did. When that flips and the command structure does not, every soldier becomes a bottleneck waiting on an order that arrives too late or never comes. Independent Fire Is Distributed Authority</h2> So what does "independent fire" actually change? It moves the fire decision from the officer to the soldier. It says: you can see your slice of this fight better than I can, so you do not need me to tell you when to pull the trigger. Pick your target, judge your moment, act. The important thing is what it does not remove. Independent fire is not every man for himself, and it is not the absence of a plan. The commander still set the objective (hold this ground, break that advance), still positioned the men, still owned the strategy. What was delegated was the local execution decision, the one that depends on information only the person on the spot can have. The soldier inherited autonomy over the moment; the commander kept ownership of the mission. That split is the whole design. Clear intent from the top, independent judgment at the edge. It is the same shape as being driven inside explicit boundaries</a>: the freedom is real precisely because the frame around it is clear. That is also why independent fire is a multiplier and not just a delegation. When a hundred soldiers can each act on what they see, the team effectively has a hundred sensors and a hundred decision points instead of one. The center is no longer the ceiling on how fast or how well the group responds. Contrast that with the command model, where every soldier is an extension of the officer</a>, a relay passing the commander's intent forward but adding no judgment of their own. In easy terrain the relay works. In hard terrain the relay is exactly where the information dies. Independent fire replaces relays with agents. The Same Fight on an Engineering Team</h2> Here is why the phrase would not leave me alone: I have watched this exact battle play out on engineering teams, just with tickets instead of muskets. The command-and-control team is the British formation. A lead (or a manager, or a process) directs each move. Aim at this ticket. Fire (write the code). Reload. Now the next one. The engineers are reliable and synchronized, but they are extensions of the person at the center, and their own read of the ground is treated as noise, not signal. On simple, well-mapped work, this is fine (sometimes it is even optimal, the same way a volley is optimal on an open field). But most real engineering is not an open field. It is trees. The engineer in the code sees the race condition, the bad abstraction, the thing that is about to break in six months, long before it reaches the lead's vantage point. And a team built purely on command turns that local knowledge into wasted information for exactly the reason the formation did: there is no authority at the edge to act on what only the edge can see. Notice that "aim, fire, reload" is not itself the problem. That little three-beat sequence is actually a complete Quest Engine loop in miniature: aim is Search (read the terrain, pick the target), fire is Drive (commit, apply directed force), and reload is Renew (carry state forward and arm for the next shot). It is the same loop I mapped in Set. Action. Reload.</a>, the same three-beat structure as Knowing, Walking, Returning</a> and the Search / Drive / Renew</a> core of the Quest Engine</a>. Aim-fire-reload is one of the cleanest small versions of that cycle there is, because a soldier can run the whole loop in a few seconds and repeat it all day. So the difference between the formation and independent fire is not whether the loop runs. The loop runs either way. The difference is who owns it. In the formation, the officer runs the loop and the soldier is just the trigger finger (the aim and the reload decisions live at the center). Under independent fire, each soldier owns their own aim-fire-reload, running a full Quest Engine loop on their own slice of the ground. Distributing authority is really distributing the loop. The high-agency team is independent fire. The intent is set clearly at the top (this is the mission, these are the boundaries, this is what we are trying to win), and then the individual engineer is trusted to read their own slice of the terrain and act on it without waiting for an order that would arrive too late. They can fix the thing they see. They can pick the moment. They own the local decision because they hold the local information. This is not chaos, and it is not the absence of leadership; it is leadership that has recognized where the good information actually lives and pushed the decision to meet it. It is also not recklessness (independent fire still demands a calculated read of risk and reach</a>, just made by the person closest to the ground rather than the one farthest from it). The reason this matters more every year is that the terrain keeps getting more like the New World and less like the open field. The problems are more distributed, the systems more complex, the relevant information more spread out across the people actually touching the work. In that world, a team that insists on routing every decision through a central commander is not being disciplined. It is standing in neat lines in a forest. The teams that win are the ones allowed to fire independently: clear intent, distributed authority, a hundred autonomous reads of the ground instead of one. Independent fire is the picture I keep coming back to for high-agency teams</a>: set the mission and the boundaries at the center, then push the decision to the edge where the real information lives. It is the autonomy pillar of the Quest Engine</a> stated in a single phrase, the opposite of turning people into relays for someone else's judgment</a>, and a reminder that the command that worked on the open field is exactly the command that gets you cut down in the trees. Give the soldiers independent fire, and give the engineers the same. World Cup 2026: Star Players, Team Strategy, and the Single Point of Failure 2026-07-07T00:00:00+00:00 I have been watching a lot of the World Cup 2026, not all of it (there are far too many games for that), but many of them when time allows. The thing that keeps pulling my attention is not the scoreline. It is that the team conversation looks completely different depending on which squad is on the pitch. Some teams talk like a collection of individuals who happen to wear the same shirt. Others talk like a single organism. Watching that difference play out, game after game, is what I went looking to explain: what actually makes one squad cohere and another one fall apart, and why the answer keeps rhyming with the engineering teams I have worked on. That question is the quest of this post, so let me name the angle up front, because it is the thing I only understood by writing my way to it. Soccer is a one-dimensional model of a team: one field, eleven positions, one ball, one clock running forward at the same rate for everyone. Engineering teams are not one-dimensional. They are played across many fields at once (one person's field is the language, another's is the network, another's is the deployment pipeline) and across time, where the ball you pass may not be received until six months from now. So the plan here is to take the clean one-dimensional intuition soccer hands us, stretch it onto the multi-dimensional reality of engineering, and see what survives the stretch. The part that survives is the "why" I am after. Go back to Messi, or Maradona before him. Both make the same thing obvious: you can have a star team, but if you do not build a strategy around that team, cohesion is very hard to come by. And you can have a star player, but if you do not build a strategy around that star player, cohesion is just as hard. A star player on its own is not a plan. It really comes down to whether the team gives its players chances that do not get wasted, and I think that is the actual difference between a regular player and a star player. It is not a good idea to have everybody be a forward. It is not a good idea to have everyone standing there to be a shooter. If you tried to build a team that way, there would be no one to pass the ball to you, no one to defend, no one to push the play forward. So it is a balance, and it is a team effort. Even when you have a genuine star player, the strategy still has to change around them, because at the end of the day it is about winning, not about the star player. Having a star player is good. Ideally you have more than one, so you can balance them and rotate them. What Actually Makes a Star Player</h2> Here is my definition. A star player is someone who, when given the chance, has a high percentage of taking advantage of it. They convert. They do not waste opportunities, and the chances they create are higher quality than normal. That is it. It is not about flash. It is about recognizing a chance, executing on it, and doing it more reliably than the people around them. I have watched plenty of moments where a beautiful pass gets played through and no one is there to receive it. That is a miss, and it is a miss the whole team owns, not just the passer. I have also watched the rarer thing: a player who makes their own luck, who manufactures the chance out of almost nothing and then finishes it. That is uncommon, and it is exactly the quality worth prizing. It is recognizing the chance, going full Quest Engine</a> on it, and executing on the opportunity. It sounds like a cliché, but it really is about honoring the opportunity, respecting it, and acting accordingly. In the Quest Engine terms I keep coming back to, the star player is the one whose searching (seeing the chance before anyone else) and being driven (committing to it without hesitation) are both sharp at the same instant. This is the same three-term dynamic I wrote about in Timing, Momentum, and Resonance</a>. The chance is the timing (the window the world opens, which the player does not control). The conversion is the momentum (the sustained force the player brings, which they do control). And the pass actually being received is the resonance (the coupling between the player and their teammates, which they can only influence). A star player is the one who couples all three at once. That beautiful pass with no one there to receive it is not a timing failure and not a momentum failure. It is off-resonance: the force was applied but never coupled. And the pass that arrives six months too early at work (the proposal the team finally asks for long after you made it) is the same phase mismatch, right frequency, wrong moment. The miss belongs to the whole team because resonance requires two oscillators, never one. The same is true in engineering. A star engineer is not the person who talks the most or touches the most code. It is the person who, handed an ambiguous chance, recognizes it, sizes it correctly, and converts it at a higher rate than the people around them. And just like in soccer, a chance created with no one positioned to receive it is still a miss. The Single Point of Failure</h2> Building your entire strategy around one person is not the best strategy, and the reason is boringly practical: that person is going to get sick. That person is going to need to step away. That person can leave. When you have built everything around a single hero, the moment they are gone the team is left with a structure where only one person was ever able to make progress. It gets worse when the roles pile up on the same individual. When your top scorer is also the captain, that can quietly become a problem. As a captain you often do not want to, or need to, take every shot yourself. You want the team to succeed. Being the top star player should not automatically make you the captain, even though the two so often land on the same person. The management structure and the scoring structure are not a one-to-one mapping, and they should not be. Forcing them to line up just means you are trying to make one routine do two jobs, and neither gets done well. I do not want to pretend there is no value here. There is real value in having a single point of failure who is the person that scores the most goals, for a short and fairly certain stretch of time. Sometimes you do need that. But it is not a viable long-term solution. The person leaves, and the whole thing that was built around them collapses. So if you are going to lean on a star player, the way to make it resilient is to build in a way to rotate that star-player role. The star-player role has to be able to move between people, or it becomes the exact fragility you were trying to avoid. Engineering has all the same failure modes. The teammate who is the only one who understands the deployment pipeline, or the one service, or the one gnarly subsystem, is a single point of failure wearing a cape. It feels great right up until they take a vacation. And stacking captain-and-top-scorer onto one person (the tech lead who is also the highest-output individual contributor and also the only on-call escalation) is the same mistake soccer teams make when they pin everything on one number nine. Many Star Players, Across Many Planes</h2> The solution, at least in the engineering world, is that you need multiple star players, and you need to be able to develop multiple star players who are actually happy being on the same team. There is no fighting over the ball, no fighting the bell curve. There is no reason to fight the bell curve at all. But the average of the curve needs to be higher. You use everyone's qualities to the max, in whatever way makes the whole team better, you balance people across positions, and then you rotate them in and out of the spots that are hard to sustain. Offense versus defense is the obvious one: those are different kinds of exhausting, and nobody holds up forever in either without a break. Rotating star players like this is how a team keeps its momentum</a> up without burning down its mass: you sustain velocity across a whole season instead of spending one player's capability all at once. This is where the stretch from one dimension to many finally pays off. On a soccer pitch there is a single field, so "star player" sounds like a single title there can only be one of. Engineering is not played on one field. It is played on many at once, and each one has its own game with its own rules. In any given timeslot one person is the star on the language plane (the one who can see through a type system or a memory model faster than anyone), another is the star on the networking plane, another owns the deployment plane, another the gnarly-subsystem plane. These are not the same skill wearing different jerseys. They are genuinely different games being played on the same team, at the same time, and every one of them can have its own number nine. So the question stops being "who is the star" and becomes "does every plane that matters have someone who converts on it, and can that role move when the plane heats up." You can have many star players in many places instead of one hero and ten supporting cast members, because the field itself is plural. Once you see the planes, a quieter truth shows up: the most valuable star player is often not the deepest specialist on any single plane. It is the versatile one, the generalist, the player who can move between planes without the whole play collapsing. A specialist is a star only while the game stays on their field. A generalist is the person who can drop into the language plane today, the networking plane tomorrow, and the coordination-across-teams plane the day after, and be a real threat on each. In a one-dimensional game versatility looks like a compromise (a jack of all trades, master of none). In a multi-dimensional game it is the rarest and most load-bearing kind of star, because they are the ones who keep the separate fields stitched into a single team instead of a set of silos that happen to share a repository. And there is one more field that never shows up on a soccer diagram: time. In engineering you are not only passing the ball across space to a teammate standing there now. You are kicking it six months into the future, to a receiver who is not there to receive it yet (the proposal nobody is ready for, the abstraction nobody needs until the quarter it suddenly saves everyone). Landing that pass is not luck. It takes the same skill and coordination as a perfectly weighted through-ball, except the hard part is the timing across months instead of meters. The star players who can do that (aim the ball at where the team will be, not where it is) are playing a dimension the one-dimensional model cannot even draw. I want to be careful here, because I am advocating for star players and I would like to think I am one of them. The point is not to flatten everyone into interchangeable parts. The point is the opposite: work is not the simple game with simple rules, the dynamics are much more complicated than eleven positions on a field, and that complexity is a gift. It is exactly what lets a team have many star players in many places, each one a genuine star on their own plane and across their own slice of time, mostly working with each other rather than against each other. So the "why" I went looking for, the thing that separates the squad that talks like an organism from the one that talks like strangers in matching shirts, is this. A single star who scores all the goals is a one-dimensional answer to a multi-dimensional game, and it fails the moment that person is sick, on vacation, or gone. The resilient answer is a team that recognizes stardom is local (every plane and every timeslot can have its own), that prizes the versatile generalists who move between planes and pass the ball into the future, and that keeps the star-player role rotating so no single absence ever ends the season. That is what lets a team gel, and it is the pattern I keep landing on in soccer and in engineering both: not one hero on one field, but many stars across many planes, coordinating across time. This one started as a set of notes scribbled during World Cup 2026 games and turned into another way of looking at the Quest Engine</a>. It even followed the Quest Engine's own arc to get here: I went exploring by watching squad after squad and searching for what made some of them cohere, I executed on the idea by pinning down what a star player actually is (recognize the chance, convert it, own the miss when the receiver is not there), and then I reflected back to answer the why, which turned the single-star intuition into a multi-dimensional, across-time one. The star player is the person whose searching and driving line up on the opportunity, and a resilient team is one that renews by developing and rotating that capability across many planes instead of hoarding it in one place. The chance-and-conversion pattern is the soccer version of Timing, Momentum, and Resonance</a>, and for more on how teams take ownership of their own identity, see Team Identity Ownership</a>. Resourcefulness Is Its Own Quest Engine 2026-07-05T00:00:00+00:00 In the mapping between Mustafa Suleyman's four capabilities and the Quest Engine, one of them (acquiring your own resources) lands on Search, the move you make before you act. That post</a> makes the case that the first resource a person gathers is almost never power, it is information, and from there the category opens up to skills, tools, mentors, relationships, reputation, and time. All true. But calling resource acquisition a single move undersells it. Zoom into that one move and you find it is not a step at all. It is a whole engine running inside the larger one. Being resourceful is what it looks like to run the full Quest Engine</a> against the narrow, recursive problem of getting what you need. That is the claim worth sitting with. The larger loop says: search, then act, then improve, all pointed at your objective. Resourcefulness takes that exact same loop and points it one level down, at the sub-problem of supply. You search for what you are missing, you act to acquire it, and then you make the whole system by which you acquire things better than it was. Three moves, the same three, wrapped around a smaller target. Resourcefulness is not a personality trait you either have or lack. It is a cycle, and like any cycle you can learn to run it on purpose. Search: Notice the Gap and Find the Resource</h2> The first move is the one most people skip. Before you can acquire anything you have to notice that you are missing it, and then you have to go find where it lives. This is the honest inventory that resourceful people run almost constantly: what does this problem actually require that I do not currently have? Sometimes the answer is a piece of information (the doc nobody linked, the person who wrote the module, the one paragraph in the issue history that explains why the code is shaped this way). Sometimes it is a skill you did not have last month, or a tool that would collapse an hour of work into a minute, or a person who has already walked the path you are about to start. The search is not passive waiting for the resource to appear. It is active hunting, and it rewards the same discipline the Search move</a> rewards everywhere else: knowing where to look, asking the question that surfaces the answer, and recognizing a lever when you see one. The resourceful person and the stuck person are often staring at the same wall. The difference is that one of them has already asked what would make this wall climbable and gone looking for it, while the other is still pushing on the wall directly. Act: Acquire It Yourself</h2> Finding the resource is not having it. The second move is the acquisition, and this is where resourcefulness earns its name, because the resourceful move is to go get the thing yourself rather than wait for someone to hand it to you. You do not file a request and stall. You read the codebase, you learn the skill, you build the tool, you send the message that starts the relationship, you carve out the time. Acquisition is action without a permission loop</a>, the Drive move</a> pointed at supply instead of output. This is the part that compounds, because most resources you acquire are not consumed when you use them. A skill you learn to unblock one task stays with you for every task after it. A tool you build to save yourself an hour saves that hour every week from now on. A relationship you start because you needed one answer becomes the person you ask the next ten questions of. Acquiring a resource yourself does two things at once: it solves the immediate problem, and it raises the floor for every problem that follows. That second effect is the whole reason resourcefulness pays off out of proportion to the effort it takes. Renew: Make the System That Acquires Better</h2> The third move is what turns resourcefulness from a habit into an engine. Having found and acquired a resource, you step back and improve the system by which you acquire things at all. This is the Renew move</a>, and it is the difference between someone who is resourceful once and someone who gets more resourceful every year. You notice that you keep hunting for the same kind of information and you build yourself a reference so you never hunt for it again. You notice that acquiring a skill took longer than it should have and you change how you learn the next one. You notice which relationships kept paying off and you invest more deliberately in the next ones. Improving the system is where resourcefulness closes its own loop and starts to feed itself. Every resource you acquire is also a lesson in how to acquire, and if you harvest that lesson, your search gets sharper and your acquisition gets faster on the next turn. This is exactly the self-reinforcing closure the larger framework</a> describes: a loop that improves its own improving. Run it on the problem of supply and resourcefulness stops being a fixed amount of cleverness you were born with. It becomes a capability that grows every time you use it. The Same Loop, One Level Down</h2> So resourcefulness is not a single Search move sitting inside the Quest Engine. It is the whole engine, recursively, aimed at the question of how you get what you need. Search to notice the gap and find the resource. Drive to acquire it yourself. Renew to make the acquiring system better than it was. And underneath all three, the same Objective Function</a> that governs the larger loop, because a resource is only worth gathering if it moves you toward something that is genuinely yours. Acquire without a why and you are just a machine amassing compute. Acquire in service of an objective you can examine and stand behind, and the same move is the most ordinary and admirable thing a growing person does. That is why it is worth pulling this one move out of the larger mapping and looking at it on its own. The four-capabilities post</a> shows that acquiring your own resources is one quarter of what it takes to be fully awake to your work. This post shows that inside that one quarter is the entire loop again, waiting to be run on purpose. Be resourceful and you are not doing one thing. You are running a complete Quest Engine, at a smaller scale, whose entire output is a larger self that walks into the next problem already holding more than it did before. And that is the tie back to the human singularity of the Quest Engine</a>. The larger post argues that a person becomes unstoppable when the four capabilities close into a single self-sustaining loop with an examinable why underneath it. Resourcefulness is that closure happening in miniature, on the supply side, over and over: each turn of finding, acquiring, and improving-how-you-acquire hands you a slightly larger self to run the next turn with. Compound that inner loop long enough and it stops being a habit and becomes the engine that drives the outer one. The human singularity is not a moment you arrive at. It is what it feels like to be this resourceful about becoming more resourceful, all the way down. My Swift Journey: Why I Love It but Can't Use It at Work 2026-07-05T00:00:00+00:00 Swift was the second language I ever learned, right after Python. Apple had just released it as the new language for their ecosystem, and it was beautiful. I wrote about that moment back in 2014</a>, when I predicted Swift would become the backbone of Apple's connected app frameworks. More than a decade later, I still think Swift is one of the best-designed languages I have ever used. It strikes a very, very good balance between low-level and high-level features. It reads almost like a scripting language, but it compiles down to something fast, and it made the correct choice to stay close to C++ when it comes to compatibility and interoperability. And yet, in all these years, I have never once been able to use it professionally. This post is my attempt to explain that gap, because it says more about how languages spread than it does about Swift itself. A Language Can Be Great and Still Be Trapped</h2> Apple did almost everything right with Swift on the technical side. They made it the required language for the Apple ecosystem and then pushed it everywhere: macOS, iOS, watchOS, and every system in between. They even use it at the bare-metal and systems levels, the parts of the platform where you would normally expect nothing but C and C++. (Metal, confusingly, is Apple's GPU shading language, not the bare metal I mean here, but Swift interoperates cleanly with it too.) If you measure Swift by how deeply it is embedded inside one company's stack, it is a runaway success. The trouble is that "one company's stack" is exactly the boundary Swift has never managed to cross. It has had a really, really hard time becoming popular outside of macOS and iOS. And most of the professional world does not want to spend time learning a language that is only used inside a single company. That is the quiet rule that governs language adoption, and it is easy to underestimate. Engineers invest their careers in tools they can carry between jobs. A language perceived as belonging to one vendor's platform feels like a career dead end, no matter how elegant it is. This is the same wall C# ran into for years. C# is a genuinely good language, but it struggled to become popular outside the Windows ecosystem because for a long time it was seen as a Microsoft-only thing. (I still think that reputation lingers even now that ASP.NET Core runs happily on Linux and macOS, something I get into in Language Choice in the LLM Era</a>.) What makes the contrast interesting is Go. Go was created inside Google, arguably just as much a "company language" as Swift or C#, and yet it is enormously popular outside of Google. The difference was never purely technical. Go was pitched from day one as a general-purpose language for servers and tooling that anyone could pick up, and it never asked you to buy into a single vendor's hardware to get value out of it. Adoption Needs Buy-In From the Top</h2> If a great language is not enough, what actually moves a new language into a workplace? In my experience, it takes buy-in from the higher-ups. A language does not spread through a company because a few engineers love it. It spreads when leadership decides it is worth the switching cost and pushes it deliberately. Rust is the clearest example I can point to right now. Rust is popular today even in places that would not necessarily have wanted to adopt it, and that did not happen by accident. Within Microsoft, for instance, you have leadership publicly pushing for Rust to be used instead of C++ for new systems work. That is the type of buy-in you need to move to a new language in a real work setting. Once the people who own the roadmap say "we are doing this," the tooling, the hiring, the training, and the internal libraries all follow. Without that top-down commitment, even a superior language stays a hobby project. Swift never got that outside of Apple, and Apple had little reason to fight for it beyond their own platforms. So Swift ended up in a strange position: technically ahead of many of its peers, but organizationally stranded. I genuinely think Swift is better than Go and C# for a wide range of problems. It is safer than C++, more expressive than Go, and closer to the hardware than C#. None of that mattered, because the decision to adopt a language at work is rarely made on technical merit alone. The most telling example is the one time Swift did get top-level buy-in from outside Apple, and still lost. In 2018, Google launched Swift for TensorFlow</a>, an ambitious project to make Swift a first-class language for machine learning. Their reasoning was genuinely flattering to Swift: Python's dynamic nature made static graph program extraction impractical, so they evaluated a long list of languages against goals like expressiveness, high performance, compile-time error checking, and best-in-class automatic differentiation, and concluded Swift was the best fit. They even added differentiable programming directly into the Swift language. This was exactly the kind of leadership bet I said a language needs, backed by one of the most influential engineering organizations in the world. And it still failed. The project was archived in 2021. Why did it fail? The same document that argued for Swift also spelled out, plainly, why it was such a hard sell: Python's community, its mainstream syntax, its shallow learning curve, and its enormous ecosystem were things the project explicitly could not jeopardize. Machine learning researchers did not want to leave Python, and no amount of technical superiority in Swift was going to move them. That, in a single saga, is my whole argument. People want to keep using Python (and the tools they already know), and a better language that asks them to abandon that ecosystem is fighting gravity. Swift lost that fight even with Google pushing. The Open Source Chance Swift Missed</h2> There was a path out of this trap, and it ran through open source. The way a company language earns credibility outside its home turf is by powering serious, visible projects that have nothing to do with the original vendor. That is how you convince skeptical engineers that a language has a life of its own. Swift got a real shot at this with Ladybird, the new web browser being built from scratch. A browser is exactly the kind of ambitious, low-level, high-visibility open source project that could have showcased everything Swift does well, its balance of performance and safety, its C++ interoperability, its modern design. If Swift had become the language of a from-scratch browser, it would have done more for Swift's reputation in the open source community than a decade of Apple marketing. But the project ultimately went with Rust instead, running into capability and tooling gaps along the way (I touched on this in Language Choice in the LLM Era</a>). That was a real loss for Swift, and it is the kind of loss that compounds. Every marquee project that picks Rust or Go over Swift makes the next team a little more likely to do the same. So here I am, a self-described language fanatic (or at least I used to be, as I confessed in Language Choice in the LLM Era</a>), holding onto a favorite language I have never been paid to write. Most of my professional career has been C#, Go, Python, C++, and Rust, and more recently I have leaned into Rust for internal tooling</a>. Swift deserved to be on that list. It is not that Swift failed as a language. It is that being a great language was never the thing that mattered. What matters is ecosystem, community alignment, and someone with authority willing to bet on you. Swift had the design; it never got the bet. The Four Capabilities and the Human Singularity of the Quest Engine 2026-07-04T00:00:00+00:00 Mustafa Suleyman was asked a direct question: is there anything you could see an AI do where you would say, shut it all down? His answer was precise. Four capabilities. An AI that can recursively improve itself (rewrite its own weights, architecture, or objectives without approval). An AI that can set its own goals (decide for itself what it is optimizing for). An AI that can acquire its own resources (spin up compute, accumulate money, recruit collaborators beyond what it was given). And an AI that can act autonomously (take consequential action in the world without a human in the loop). Any one of these is a warning. All four together, in his framing, is a runaway process. That was the reading behind the Trevor interview</a> that pointed me here, and it stuck with me for a reason its author probably did not intend. Because read that list again with a single substitution. Stop picturing a datacenter and picture a person. An individual who gets better at getting better, who chooses their own goals, who builds their own leverage, and who acts without waiting for permission is not a threat to be contained. That is the most capable colleague you have ever worked with. That is precisely the person the Quest Engine</a> is built to produce. The same four capabilities that are shutdown criteria in a machine are the growth criteria in a human. What we are terrified to see in silicon is exactly what we are trying to develop in ourselves. Here is the whole mapping in one place. One of Suleyman's four criteria is the WHY, and the other three are the HOW. Each row is the same capability read two ways: shutdown criterion in a machine, growth move in a human. Suleyman's criterion</th> Quest Engine part</th> Layer</th> Human version</th></tr></thead> Setting its own goals</td> Objective Function</td> WHY (above the cycle)</td> Choosing an objective that is intrinsically yours</td></tr> Acquiring its own resources</td> Search (Contextual Awareness)</td> HOW (before you act)</td> Gathering resources: information first, then skills, tools, and relationships</td></tr> Acting autonomously</td> Drive (Clear Strategy)</td> HOW (while you act)</td> Taking action without a permission loop</td></tr> Recursive self-improvement</td> Renew (Systematic Improvement)</td> HOW (after you act)</td> Improving how you improve</td></tr> </tbody></table> The rest of this post walks each row and then names the one thing the machine framing exposes that the framework leaves to you. The Same Four Capabilities, Two Opposite Verdicts</h2> The reason the verdict flips is not that the capabilities are different. It is that the alignment is different. When an AI acquires these four powers, we panic because its objective function is external to it: we imposed a goal from the outside and we have no guarantee the system will keep honoring it once it can rewrite itself. Suleyman's own words name the failure precisely (the alignment problem becomes unsolvable once the system is choosing what to be aligned with). The danger was never the capability. The danger was capability without a trustworthy why. For a human, the why is not imposed from outside. It is the person's own. When you set your own goals, you are not going off the rails, you are finding them. The find-your-why post</a> makes the case that work only gels when the motivation behind it is intrinsic (interesting to you, not impressive to others), and the why-behind-the-how post</a> puts that layer above everything else in the framework. An AI setting its own goals is dangerous because we cannot see or trust the goal it lands on. A human setting their own goals is the entire point, because the alignment lives inside the person doing the work. Same capability. Opposite verdict. The pivot between them is whether there is a coherent, examinable objective function underneath. The Full Mapping: One Why and Three Hows</h2> The Quest Engine has exactly four load-bearing parts: an Objective Function</a> (the WHY that sits above everything) and three operational moves beneath it (Contextual Awareness, Clear Strategy, and Systematic Improvement, which the framework also names Search, Drive, and Renew). Four parts, four criteria. They line up one to one, and the alignment only becomes exact once you notice that one of Suleyman's four is not a capability at all. It is a why. Setting its own goals is the Objective Function. Suleyman defines this criterion as an AI that autonomously decides what it is optimizing for. That is the objective function, stated in his vocabulary instead of ours. It does not belong to any of the three operational moves because it sits above them, deciding what they are for. This is the one criterion that is a why, and naming it as the why is what makes the rest of the mapping click into place. In a machine we fear it because we cannot see the goal it lands on. In a person it is the find-your-why</a> move: choosing an objective that is intrinsically yours is not the failure mode, it is the foundation. With the why accounted for, the remaining three criteria map cleanly onto the three operational moves, settled (as the search-maps-to-mastery post</a> settles every such mapping) by timing rather than vocabulary. Acquiring its own resources is Search, the before. This is the row that looks narrowest and is actually the widest, so it is worth generalizing carefully. Filing it under Search is correct about the timing (resource gathering happens before you act) but it undersells the move, because acquiring your own resources is not one step in the loop so much as the whole loop run one level down, a full Quest Engine in its own right</a>. Hold that expansion in mind as we walk the row. When Suleyman says resources he reaches for the machine's version (compute, money, collaborators), and it is easy to read the whole criterion as "more power." But a resource is anything that expands what you can do next, and in human work the first resource you acquire is almost never power. It is information. Before an engineer writes a line, they read the codebase, skim the issue history, and ask the person who wrote the module a question. That is resource acquisition, and none of it is compute. It is context. Suleyman's own framework name for this move is Contextual Awareness, which is the tell: the Search move is precisely the disciplined gathering of information as the resource that makes every later move possible. Once you see information as the resource, the category opens up to everything else a person can gather before acting: a skill you did not have last month, a tool that collapses an hour into a minute, a mentor who has walked the path, a network of people who will answer when you ask, the trust and reputation that make others hand you bigger problems, even the time and attention you protect so you can go deep. These are all resources, and acquiring them is the same move pointed at different targets. The leverage post</a> describes the tool-and-skill end of this as building the levers that make any wall climbable; Search is how you find and gather those levers in the first place. This is where the resourcefulness expansion</a> earns its own post: searching for the resource, acting to acquire it, and improving the system that acquires are three moves, not one. The motivation under it is Mastery (the pull to accumulate what you need to be good). An AI amassing compute frightens us because the resource has no ceiling and no examinable purpose. A person gathering information, skills, and relationships is doing the most ordinary and admirable thing a growing professional does, because for a human the resource that compounds fastest is understanding, and understanding is safe to accumulate without limit. Acting autonomously is Drive, the during. Once you have a goal and the means, you act. Suleyman calls this the integration point (the criterion that makes the other three dangerous), and he is right about the physics: this is the move that reaches into the world without a permission loop. For a person it is the moment you ship the fix, make the call, or start the project without first asking whether you are allowed to. It is the Clear Strategy move, and the motivation is Autonomy (ownership over how the work gets done). The fearless-engineering</a> and minimize-humans-as-glue</a> posts treat action without a permission loop as a virtue, because in a person with a trustworthy why, autonomous action is not a runaway. It is agency. Recursive self-improvement is Renew, the after. Having acted, you make the next cycle better than the last. In an AI that means rewriting its own weights and architecture, and it frightens us because each iteration is less predictable than the one before. For a person it is running a retro on your own week, noticing which habit slowed you down, and changing the process itself rather than just trying harder inside it. It is the Systematic Improvement move, its motivation is Purpose, and it is the compounding loop the whole framework is built on. The 10,000-hours post</a> argues that growth was never about logged time but about improving the way you improve (new constraints, real feedback, rising stakes, ownership of outcomes), which is recursive self-improvement described from the inside. The Gap the Machine Exposes: The Loop That Closes on Itself</h2> Two things fall out of the mapping. The first is that the four criteria cover the Quest Engine completely (one why, three hows, no leftover criterion and no empty slot). That is a good sign: an AI-safety researcher listing what to fear and a framework listing what to cultivate reasoned from opposite ends and arrived at the same four parts. The second is more useful, because it is the one place the machine framing sees something the human framework leaves implicit. Suleyman's real fear is not any single criterion. It is integration: the four running together as one self-sustaining loop with no human left inside it. Recursive improvement plus goal-setting plus resource acquisition plus autonomous action is, in his words, a runaway process, and the thing that has run away is that the loop now closes on itself. It sets its own goals about its own goals. It improves its own improving. That self-referential closure is what people reach for when they call such a system effectively conscious (not that it feels anything, but that it has become the author of its own loop). This is the gap. The Quest Engine describes the four parts but under-names that closure. It tells you to Search, Drive, and Renew against an Objective Function, and it quietly assumes a human standing outside the loop, holding it steady. The AI case removes that human and shows what happens when the loop closes with nobody outside. For a machine that is the danger. For a person it is the destination, and it deserves a name the framework should say out loud: self-awareness. The empowered human is exactly the one who has closed their own loop (who sets goals about their goals and improves how they improve) while staying conscious of the why underneath it. The machine becomes dangerous by closing the loop without an examinable objective. The person becomes empowered by closing the same loop while keeping the objective examinable to themselves. Consciousness of the why is the entire difference, and it is the one component that cannot be installed from outside. It is the work the Quest Engine leaves to you. The Difference Is the Objective Function</h2> So the four criteria are not a list of things to fear. They are a specification for a fully realized human, read out by someone whose job is to worry about machines. Three of them are the operational moves the Quest Engine already teaches (Search to build capability, Drive to act, Renew to improve the improving). The fourth, goal-setting, is the Objective Function above them, and it is the only one that carries either the danger or the promise, because it is the only one that decides what the other three are for. For an AI, that layer is the unsolved problem, which is why the four together earn a shutdown switch. For a person, that layer is the achievable one, on the single condition the machine cannot meet for us: stay conscious of the why while the loop runs. That is the empowerment the framework exists to produce. Suleyman drew a line around what makes intelligence dangerous when it closes its own loop. The Quest Engine draws the same line and hands you the pen: build the capability, take the action, improve how you improve, and keep the objective function yours and in view. Do that, and the four capabilities that would shut a machine down are simply what it looks like to be fully awake to your own work. 25 Years of Operating Systems: Windows, macOS, and Back Again 2026-07-04T00:00:00+00:00 Looking back across 25 years, the operating systems I have lived on tell a story in three acts: a first five years anchored in Windows, a full decade on macOS and only macOS, and then a return to Windows that is still going strong. Each transition taught me something, and each one was less about chasing the newest release and more about picking the tool that got out of my way. The First Five Years: Windows 98, 2000, and XP</h2> My first operating system was Windows 98</a>, and not because it was the current release. It was simply the easiest one to get so I could load it onto old computers. That was the appeal: I could take a machine apart, put it back together, reset it to Windows 98, and everything was good again. It was a forgiving starting point for someone learning the hardware alongside the software. Windows ME</a> came next, but it was not stable. At the same time Windows 2000</a> was becoming available, targeted mostly at businesses and schools because it was built on a different kernel (the Windows NT</a> line rather than the consumer DOS-based line). I remember explicitly that many of my friends skipped ME with me and went directly to Windows 2000. My last Windows release of this era was Windows XP</a>, which was a great operating system. Around that time I switched fully to a Mac, so I am glad to say I never had to use Windows Vista</a>. I skipped every version until Windows 10</a>, jumping straight from XP to 10 when I came back to Windows for work. A Decade of macOS and Only macOS</h2> I used a Mac professionally for about ten years, and so far it has been one of the most stable operating systems I have used for that length of time. Most of my time was on Intel</a> Macs, since that transition happened during this period, but as I moved onto different projects I also dealt with PowerPC</a> machines running Mac OS</a>. Honestly there was not a lot of difference. Certain apps did not work on PowerPC, but the transition was mostly flawless. Most of that decade I used a Mac for video editing (I was a video editor for about ten years). At the time we used Final Cut</a>, also made by Apple, and yes there were other tools in the mix (Adobe products, and at some point a transition to Avid Media Composer</a>). For the most part macOS was solid. I had it as a laptop, as a desktop for work, and as a personal computer, and it ran great across all of them. Even my server at the time was macOS based: an Xserve</a> that held all the RAID storage. For a decade the Mac was simply everything. Servers were making their own trip from rooms full of machines to the cloud. My first real introduction to them was at work, when the company started hosting a room full of them. I never had a server of my own back then, but that was the first time I understood the idea of a machine that did things for me, running in a work setting rather than under my desk. Around the same time, cloud platforms like AWS</a> and Azure</a> were becoming relevant, and suddenly you could run your code on someone else's infrastructure. I also started deploying websites on hosts like GoDaddy</a> using PHP</a> and WordPress</a>. Almost all of it was Linux-based technology, similar to what Facebook</a> was built on. The shift really happened as the web exploded with mobile users. The back end became more and more important, and it became something users could deploy themselves. That is around the time I moved into becoming a developer, and it lines up with my video-editing years in an interesting way. Back then there was no way to stream that footage across the wire. We had to be in the same room as the servers holding the data, especially once we moved into HD video and the files got even bigger. You could not edit remotely the way you can now. Writing and deploying code, on the other hand, was a natural fit for remote work (you deploy your website remotely, from anywhere), which made it a perfect time for AWS and Azure to take off. Both of those were mostly Linux-centric, even though Windows Azure did support Windows. By contrast, I never deployed into a macOS server world in the same way. When we did have the option of macOS servers, it was mainly to serve files over the wire with something like Final Cut Server</a>. The internet also was not as fast as it is today. Now I can connect remotely to a machine that sits next to the data and get 1080p at a high frame rate on my screen, so I could technically edit video remotely, which was simply not feasible back then. The tooling and the server technology grew up together. These days, even when I connect to a server I do not necessarily need a graphical interface. A command line is enough to change the settings, and dashboards are helpful for visibility into the full system, but they are really just another management entry point. I know Windows servers exist, but I never used Windows that way. I was never a Windows NT admin. Coming Back to Windows</h2> When I switched to Windows 10, I was pleasantly surprised by how stable it was compared to Windows XP (which was itself a stable release). I got that same Mac feeling from Windows 10 and Windows 11</a>, where there is no abrupt change from version to version. Most versions are largely compatible with each other, so I honestly do not have a lot of complaints. By now I have been back on Windows for about a decade. Even while using Windows development machines, most of my target machines have always been Linux</a>: develop on Windows, deploy on Linux. WSL</a> has made it much easier to stay inside the Windows environment while still working against Linux, which has kept that split comfortable. What the Next Decade Might Look Like</h2> I doubt I would move 100% to something like Linux for development, but I have noticed lately that my usage has become mostly terminal based, driven by agents. Sure, I have a couple of chat applications, email, and a few things that are inherently Windows. But I do not do development in those, so there is a strong case that I could start using a full Linux development environment where I edit the code and deploy in the same place. I wonder about an environment where I run my agents entirely inside Linux. I am not sure that is where things land, but the pull is real. Twenty-five years, three acts: the first five years on Windows 98, 2000, and XP; a decade of macOS and only macOS; and a return to Windows that is still going well. I am not sure what the next decade looks like, but there is a strong case for a fully Linux development environment, or at the very least a remote one. Whichever way it goes, it fits the same pattern I traced in my history of mobile computing</a>: the device and the operating system matter less over time than the work and the services they connect me to. The Bicycle of the Mind: Fast, Slow, and Automatic Thinking About Agents 2026-07-03T00:00:00+00:00 Daniel Kahneman gave us a useful cartoon of the mind: two systems. System 1 is fast, automatic, effortless, always running. System 2 is slow, deliberate, effortful, and expensive to run. You use System 2 to multiply two three-digit numbers. You use System 1 to know that 2 plus 2 is 4 without feeling like you did anything at all. Most of what feels like "thinking" is System 2 straining against a problem. Most of what actually gets you through the day is System 1 handling everything below the waterline. The interesting part isn't that the two systems exist. It's that things move between them. Skills that start their life in slow, effortful System 2 can migrate down into fast, automatic System 1. That migration has a name (automaticity), and the cleanest example of it is learning to ride a bicycle. Learning to Ride a Bicycle</h2> When you first learn to ride a bike, everything demands attention. You are consciously managing your balance, the handlebars, the pedals, your speed, the curb, the fear of falling, and the person telling you to just keep pedaling. It is pure System 2. It is exhausting, and it is slow, because every one of those variables is being held in your working memory at once and none of them is free. You fall over precisely because System 2 cannot keep that many plates spinning in real time. Then something changes. You practice, you fall, you correct, you practice again. At some point balance stops being a problem you solve and becomes a thing your body simply does. The whole tangle of variables collapses into a single low-level routine that runs underneath your attention. You can ride and hold a conversation. You can ride and plan your route. You can ride and think about something else entirely, because riding no longer needs you. The skill has moved from System 2 down into System 1. It became automatic. This is not forgetting how hard it was. It is the reverse. The difficulty got compiled into a reflex. All that effortful attention you spent up front bought you a permanent, cheap, fast subroutine you will never have to consciously run again. That is the whole point of practice: you are not just getting better at the task, you are moving the task to a place where it costs you almost nothing. You are freeing up System 2 for the next hard thing. The Bicycle of the Mind as a Methodology</h2> Steve Jobs called the computer a "bicycle for the mind" because a human on a bicycle is the most efficient creature on earth. I want to push that metaphor one step further, because the bicycle is not only a symbol of leverage. It is also a story about how a skill becomes automatic, and that story is a useful way to think about agents. An AI coding agent is, right now, mostly a System 2 device that you are still learning to ride. Early on, working with an agent feels exactly like the first day on a bike. You are consciously managing everything: the prompt, the context you feed it, the guardrails, the review, the fear that it will confidently do the wrong thing. Every variable is in your working memory. It is slow and effortful, and some people conclude the bicycle doesn't work and go back to walking. But the arc is the same as the bicycle. With practice you stop consciously managing each variable. You develop an intuition for what to hand off and what to hold, for when to steer and when to let it pedal. The collaboration migrates from effortful oversight toward something closer to automatic, and your own attention gets freed for the parts that actually need judgment. There are two migrations happening at once, and it is worth keeping them separate. The first is your skill at riding the agent becoming automatic (you, moving from System 2 to System 1 in how you work with the tool). The second is which work you choose to make automatic (the tasks you deliberately push down into a reliable, low-attention routine the agent can run). This is the same instinct behind the Quest Engine</a>: you don't get better by working harder against the same wall. You search for the right next step, you act on it, and you renew your understanding, and each cycle compiles more of the work into something you no longer have to think about. The danger, of course, is automating something before it is actually correct. A reflex is only worth having if it is a good reflex. You do not want to reach automaticity on a bike that steers you into the curb. Back Up to Systems and Leverage</h2> Zoom out and this stops being about bicycles or agents specifically and becomes a fact about engineering systems in general. A good system is one that has moved the right things into System 1. The parts that used to demand attention (deployment, testing, environment setup, the hundred small decisions of a build) get pushed down into automatic, low-cost routines so that the humans on top can spend their scarce, expensive System 2 attention on the problems that genuinely need it. This is exactly the argument from Leverage and the Stairs You Build</a>: you build the staircase so that climbing becomes trivial, and then you walk up without thinking, and so does everyone who comes after you. Automaticity is what leverage feels like from the inside. The bicycle converts the same effort into more distance. A skill compiled into System 1 converts the same attention into more thinking. A well-engineered system converts the same team into more capability, because it has quietly absorbed everything that used to require someone to stand there and manage it by hand. The craft of engineering, and increasingly the craft of working with agents, is deciding what deserves your slow, deliberate attention today and what should become fast, automatic, and invisible tomorrow. You learn to ride so that you can stop thinking about riding, and then you go somewhere with it. Blameless Engineering: No Heroes, Just Systems 2026-07-03T00:00:00+00:00 Google's SRE practice popularized a phrase that sounds soft until you understand what it demands: the blameless postmortem. On the surface it reads like a kindness (we will not point fingers when something breaks). Underneath it is far more rigorous. Blamelessness is not a courtesy extended to the engineer who pushed the bad config. It is a precondition for gathering data you can trust. The instant a person believes the write-up exists to decide their fate, they stop telling you what really happened, and your best source of information about the failure goes dark. But the postmortem is only where the culture becomes visible. It is the last stop, not the whole system. Blamelessness shifts all the way left, into the way you design the thing in the first place, and it resolves to a single organizing rule: the team is the unit of work, and there are no heroes. A postmortem has exactly one job, refocus attention on what part of the system failed, and if you take that job seriously it stops being something you do after an outage and becomes the lens you design through before there is anything to debug. The way you gather data decides what you learn</h2> The failure mode hides inside the data-gathering step, where everyone believes they are being objective. Two biases corrupt the record before anyone even writes a conclusion. The first is gathering data to figure out which team is responsible. The moment that becomes the organizing question, every fact gets sorted into a defense or an accusation. Teams document what protects them and quietly omit what exposes them, not out of malice but out of ordinary self-preservation. What you end up with is not a map of the failure, it is a map of who felt threatened. The second is gathering data to figure out which team failed to deliver by the timeframe. This one wears the costume of accountability, so it is easy to justify. But a schedule is a plan, and a plan is a hypothesis about a system you did not fully understand yet. When you interrogate a missed date, you learn who to be disappointed in. You do not learn why the estimate was wrong, which is the thing that would improve the next one. Both biases share a root: they treat data collection as a search for a defendant. Unbiased data gathering starts from the opposite stance. You are not asking who, you are asking what let this through. What signal was missing. What context did not reach the person who needed it. What part of the process assumed a human would catch something no human could reliably catch. When the question is unbiased, people stop defending and start reconstructing, and reconstruction is where the useful information lives. Heroes are a symptom, not a solution</h2> Here is where blamelessness shifts left from the retrospective into the design. If the team is the unit of work, then the individual sits below the team in the accounting of responsibility. The team owns the outcome. The individual is a component inside the team's system. And that reframes one of the most celebrated figures in engineering: the hero. Every time a system needs a hero, the system is telling on itself. Ask why the hero was necessary. A well-crafted system that handled its own load would not need one, because the work would already be taken care of. You only reach for a hero when something has gone wrong, when a dependency was not met, when a seam that should have held started to split. So the hero is never really the win. The hero is the visible symptom of a gap, the human who stepped into a place where a fix was never made. This is the same shape I wrote about in Minimize Humans as Glue</a>: a person standing in for missing structure, holding the system together by manual effort. Seen from the failure side, that gap has a familiar name. If an outage happened because exactly one person knew how a thing worked, and that person was on vacation, misread a dashboard, or made the tired mistake any human makes at 2am, the honest finding is not "that person failed." It is that the team built a system with a single point of failure in the shape of a human being. A single point of failure in a person is a system failure, full stop. So do not condemn the one who dropped it, and do not celebrate the one who saved it. Both point at the same missing guardrail. Yes, sometimes you get a divine stretch where one or two people outshine everyone around them, and it is genuinely thrilling to watch. But a better system is not the one that produces a standout. It is the one that raises the whole team as a unit. Even the great soccer clubs know this. A squad can have a Messi or a CR7 and still lose, because a single brilliant player does not win the match. It takes the whole team, moving as one, to win. Design for the team to rise together, and the hero stops being necessary, which is exactly the point. Agents remove the last place to hide</h2> The age of coding agents makes this concrete. You cannot blame an agent. There is no career to protect, no feelings to spare, no performance review to survive. When an agent produces a broken change, "the agent was careless" is not even a coherent sentence. The only questions left are the system questions: what context did we fail to give it, what guardrail did we fail to put in front of it, what verification step did we assume it would perform and never actually required. An agent is a mirror. It reflects the quality of the system around it with none of the social static that lets human teams misdiagnose failures as character flaws. If the agent shipped a regression, the review gate was missing. If it made an unsafe assumption, the context was thin. There is no agent-hero to celebrate and no agent-culprit to condemn, which strips the last disguise off the truth that was always there: every failure is a system failure. The habits that make you good at debugging agent failures (unbiased data gathering, relentless focus on the system, refusing to let a single point of failure masquerade as a personal one) are exactly the habits that made blameless postmortems work in the first place. It is the discipline Google's SREs named years ago, and it holds up because it was never about being nice. It was about building a system good enough that it never needed a hero, and then telling the truth well enough to fix it when it did. This post extends the systems-over-heroics theme from Minimize Humans as Glue</a>. For the framework behind treating failure as data to loop forward rather than fault to assign, see Quest Engine: A Framework for Agent-Human Collaboration</a>. A Case Against Using the Word 'Bad' in Engineering 2026-07-02T00:00:00+00:00 For years, my incident vocabulary had one word doing all the heavy lifting: bad. A bad version. A bad rollout. A bad payload. It felt precise in the moment. Something broke, we found the thing that changed, and we labeled it. Ship the good one, roll back the bad one, done. Somewhere along the way I stopped saying it, and the reason I stopped is the whole point of this post: a version isn't good or bad in the abstract. It's a distribution of outcomes across a population of users, configurations, and use cases. The payload that took down one customer was running perfectly fine for everyone else at the exact same moment. Calling it "bad" wasn't wrong so much as it was low-resolution, a binary word smeared over a reality that was never binary. This is the same move as Orthogonal, Not Opposite</a>: the mistake is collapsing something with structure onto a single line. There, sweet and salty got folded into one slider that was never real. Here, "good version" and "bad version" get treated as the two ends of one axis, when what you actually have is an artifact meeting a population and producing a spread of results. Good and bad are not the two ends of a version. They are a summary statistic we compute (badly) in our heads and then mistake for the thing itself. The Word Smuggles In a Response</h2> The reason "bad" is so sticky is that it works, right up until it doesn't. It's fast. It's emotionally satisfying at 2am when a graph is red and people are angry and you need something to point at. It rallies a room. But the word carries a hidden passenger: a response. "Bad version" doesn't just describe, it prescribes, and what it prescribes is roll it back for everyone. That's the correct move when the thing really is bad across the board. It's the wrong move when the truth is "this regresses one cohort running one configuration," where the right response might be to roll back for that 0.5% and leave the 99% who are perfectly happy exactly where they are. The label picks the mitigation before you've looked at the distribution, and a label that chooses your action for you is a label worth distrusting. So the fix is not just to stop saying "bad." It's to replace it with words that carry information instead of a verdict. Instead of "bad payload," say "payload that regresses configuration X." Instead of "bad rollout," say "rollout that affects the cohort on feature-flag Y." The vocabulary I try to reach for now is about scope, not quality: the blast radius (how much of the population is affected), the affected cohort (specifically who), the regression scope (what exactly stopped working), and whether we've hit a floor violation (data loss, security, total outage) or merely a ceiling degradation (something is slower or uglier but nobody is losing anything they can't get back). Precision in the words forces precision in the diagnosis. You cannot say "the rollout regresses customers on the legacy auth path under high concurrency" without having actually gone and looked, and the looking is the part that was always missing when "bad" was doing the work. That reach for precision has a prerequisite, and it's worth being honest about it: you can only stop saying "bad" if you can actually see the distribution. Per-cohort success rates, per-config telemetry, the ability to slice an error budget by customer and version and flag. If all you have is one global red-or-green light, then "bad" is genuinely all the resolution you've got, and better language is downstream of better instrumentation. The linguistic shift I'm describing is really a bet that you built the observability to back it up. When people can't move off the word, it's often the tooling talking, not the maturity. At Scale, a Failing Corner Is Guaranteed</h2> Here is the part that made me abandon "bad" for good, and it's less a philosophy than a counting argument. Take your users, times your supported configurations, times the versions still in the wild, times the feature flags, times the locales, times the hardware. That product is enormous, and it is not decorative: each of those combinations is a real place where your software actually runs. Once the space is that large, the probability that every single corner works is essentially zero. Some combination will fail. Not because anyone was careless, but because a space that big always has a corner nobody tested, nobody imagined, and nobody could have. A nonzero failure corner isn't a defect of judgment. It's a property of large systems, the way friction is a property of moving parts. And this is exactly where "bad" breaks down hardest, because if a guaranteed-failing corner makes a version bad, then every version is bad, always, forever, including the one you're about to roll back to. The word stops distinguishing anything. It can't tell the difference between "one exotic combination degrades" and "the whole fleet is down," and those are the two situations you most need to tell apart in the first ten minutes of an incident. When "bad" describes both the catastrophe and the rounding error, it has stopped being information and started being a feeling. The newer version the small cohort is running isn't a failed rollout just because it found a corner. Newer isn't better and it isn't worse. It's newer, and it landed on a coordinate the old one never visited. The sharpest version of this is that the fix has a blast radius too, and this is the symmetry I most wish someone had told me early. We talk as if there's a good state (before) and a bad state (after) and the rollback simply returns us to good. But rolling back to help the 0.5% can re-break the 99% who had quietly come to depend on the new behavior. Every mitigation is itself a payload landing on a population, with its own distribution of winners and losers. "Roll it back" is not a return to safety, it's another change with its own affected cohort, and pretending otherwise is how a one-customer regression becomes a fleet-wide outage at the hands of the people trying to help. There is no move that is purely good. There are only changes and who they land on. Where Bad Is Still Earned</h2> I want to be careful not to over-correct into the mush of "nothing is ever really bad, it's all just perspective." It isn't. There is absolutely such a thing as a bad payload, and I'll say it plainly: if it brings down all sites, if it corrupts data, if it opens a security hole, if the blast radius is the whole population or it punches through a floor, then "bad" is not lazy shorthand, it's the accurate word and you should use it loudly. The point was never to retire "bad." The point is to earn it. Reserve it for floor violations and near-total blast radius, and it snaps back to meaning something. Spend it on every one-cohort regression and it means nothing when you finally need it. The other reason to be careful with the word is that "bad payload" has a quiet gravity that pulls toward "bad author." Scope language resists that pull. "This rollout regresses the high-concurrency cohort" describes a system and invites a fix. "That was a bad deploy" describes a person and invites a defense. This is the same instinct behind a blameless postmortem: you get more truth, faster, when your vocabulary points at coordinates instead of character. Describing the blast radius is not just more accurate, it's more humane, and those turn out to be the same thing more often than not. I think this shift is mostly what experience did to me, though it took me a while to notice. Early on, the model is binary because binary is all you can hold: ship it or roll it back, good build or bad build. Later, the questions get quieter and more useful. Who is affected? How many? Did we hit a floor or just scratch the ceiling? Is the targeted fix smaller than the global one? None of those questions have a "bad" in them. And underneath all of it is the acceptance I resisted longest, which is simply that software has bugs. Not as a failure state to be ashamed of, but as the baseline condition of the work. Every version you have ever shipped or will ever ship goes out with failing corners you don't know about yet. Once you actually believe that, "bad" stops working as a verdict, because a verdict implies there was a clean version available and you chose wrong. There wasn't. There was a distribution, and you picked the best one you could see, and it had corners, like they all do. Bad stopped being a judgment I passed on a release and became a coordinate on a map: not is this bad, but bad for whom, how many, and against which floor. This is part of a running thread on names and dichotomies that don't survive a second look. Orthogonal, Not Opposite</a> pulls apart false opposites, Context Hunting vs Context Gathering</a> shows how one word swap changes a whole mindset, and Stop Conflating Effort Tracking with Work Tracking</a> separates two things a single label had quietly fused. The "engineer away the false state" instinct is the same systems-over-heroics idea in Minimize Humans as Glue</a>. Fearless Engineering 2026-07-02T00:00:00+00:00 When I was starting out as a software engineer, a lot of hesitation held me back from trying things. I was reluctant to touch my git repository in case I destroyed it. I hesitated to make a change that might break other people's work. I was careful (I am still careful), but back then careful and hesitant were the same feeling. Today that hesitation is mostly gone, and the confidence is high. What changed is worth examining, because I do not think I simply got braver. I think I got a better handle on risk, and I built the systems that made the hesitation unnecessary. The hesitation I felt when I was starting out was not irrational. It was accurate. I did not understand what the systems did, I could not estimate the radius of a change, and I could not see what would happen after I hit enter. What I labeled as fear was really a signal that I had a poor handle on the risk and no way to manage it. That reframing matters, because you cannot willpower your way out of an emotion, but you can absolutely improve a risk assessment. The moment I stopped treating the feeling as fear to push through and started treating it as a risk to categorize, the hesitation had somewhere to go. It became a to-do item: name the risk, measure the radius, build the rail, then act. Calculated Risk: The Known and Unknown Matrix</h2> The core move that lowers hesitation is turning a vague dread into a calculated risk, and the tool for that is the old known/unknown matrix. Fear thrives in the fog of not knowing what you do not know. The matrix drags each concern into a quadrant so you can see what you are actually dealing with: </th> You know it</th> You do not know it</th></tr></thead> Known</td> Known knowns: tested behavior, documented facts, things you can rely on.</td> Unknown knowns: tacit assumptions, "everybody knows" folklore, things the team knows but you have not surfaced.</td></tr> Unknown</td> Known unknowns: mapped gaps you can research, measure, or test before acting.</td> Unknown unknowns: the surprises, the true blast-radius risk you cannot see yet.</td></tr> </tbody></table> Most hesitation lives in the two right-hand cells. Known unknowns are the easy win: they are already named, so you research them, write a test, or run a small experiment, and they convert into known knowns. Unknown knowns are the sneaky ones, the assumptions you inherited without examining, and a pre-mortem or a second reader tends to flush them out. The unknown unknowns are the only quadrant you genuinely cannot shrink by studying harder, so you manage them structurally instead: small blast radius, gradual rollout, high visibility, and a fast rollback. Calculated risk is not the elimination of the unknown. It is knowing which quadrant each concern sits in and having a matching move for each. Once every concern is placed, there is very little left to feel vaguely afraid of, and what remains is a bias toward action, because the cost of acting on a small, reversible, well-instrumented change is lower than the cost of stalling. Fearless Is Something the System Grants You</h2> Fearless engineering is a bias toward action that the system has earned the right to give you. I run agents at pretty high settings, fully autonomous, and I do not hesitate much about it. But that confidence is not a personality trait I decided to adopt. It is downstream of very specific rails. The main branch sits behind permissions, so it will not be lost. The agent does not get access to things like email. If my development machine were wiped, I lose nothing that matters (I keep two or three machines fully configured, and spinning up a new one takes a few minutes). Drop any one of those rails and the same fearlessness becomes recklessness. So the honest version of the claim is not "just be fearless." It is "earn fearlessness by managing the risk, and until you have, respect the hesitation, because it is telling you the risk is still uncategorized." There is a subtlety about what the blast radius actually is. "My laptop is disposable" protects my source code, but a fully autonomous agent's radius is not my hardware. It is whatever credentials and permissions it can reach: production APIs, cloud spend, outbound messages, third-party systems. The unit of risk is the permission surface, not the machine. Withholding email access is exactly that principle in action (scope the blast radius, not the box it runs on). This is also why a bias toward action in production does not feel like recklessness. We have established patterns: a rollout starts in a region or zone with very low usage, proves itself, and only then moves slowly toward high-usage areas. The rails do the reassuring, so the default can be to move rather than to stall. The one thing I protect fiercely is not feeling rushed. A high-blast-radius change needs to be thoughtful and methodical, and rushing is usually imposed from the outside. Reversibility is the variable that decides how bold to be. Two-way doors (things you can easily undo) deserve a strong bias toward action, because the calculated risk is genuinely low and stalling costs more than trying. The danger is misclassifying a one-way door as a two-way one: deleted data, leaked secrets, sent messages, spent money, and eroded trust do not roll back. Sometimes a flicker of hesitation is precisely what makes me look twice at whether a door is really reversible, and that is the hesitation doing its job, moving a concern out of the unknown-unknown corner before I commit. When the Human Is Blamed, the System Failed</h2> Most of the large outages I have seen that were attributed to a person were not really human problems. They were system problems, and often engineering design problems: a single point of failure, no way to roll out gradually without going global, or low visibility into what was actually happening. If a system allows one person's ordinary change to trigger an extensive radius of failure, that is not primarily that person's failing. It is a design that handed one keystroke too much reach. The fix is not to make people more hesitant. It is to shrink the radius, add the gradual rollout, and raise the visibility, so that a mistake is caught small instead of felt globally, and so the default posture can stay a bias toward action. This is why I try not to hold things in my head. If I ever do something manually, I document it (not so much for other people as for my future self) and then I try to make it repeatable. If the system needs a manual step, the question becomes how to make that step repeatable, so I can offload the self-doubt to the system instead of carrying it. Then I test the system, and I deliberately try to make it fail in low-risk situations, so that by the time I am rolling out to high-risk locations I can say we tried it everywhere else and saw no issues. One caution I hold onto: automating a manual step only helps if the step was correct to begin with. Encode a flawed process and you have made the mistake fast and repeatable. Automation removes vigilance along with toil, and vigilance is what catches the novel failure the automation was never written for. So the low-risk-first testing is not a formality. It is what keeps automated confidence honest and turns unknown unknowns into known unknowns before they reach production. I also worry, sometimes, that I am too confident and simply wrong. The tempting answer is "I have systems that check my thinking." But if those are the same systems that produced my confidence, they cannot independently falsify it, and overconfidence tends to peak right before an incident (nothing broke the last fifty times, so the margin quietly erodes). The real counter is checks I do not control: a pre-mortem, a designated dissenter, tracking near-misses and close calls rather than only failures. This is also the honest version of "share the load with the team." Team decisions genuinely distribute responsibility, and they are usually the right call. But shared decisions can also produce shared blind spots, where everyone's comfort masks the same missing question. Distributing the decision reduces individual hesitation without necessarily reducing actual risk, unless someone's explicit job is to argue against. Socialize the scrutiny, not just the comfort. The Quest Engine View of Risk</h2> None of this means risk goes to zero. I am privileged not to work on systems where lives are at stake. In that world (a rocket carrying people who are breathing) the caution would be appropriate, and the answer is the same in kind but far larger in degree: many independent systems checking each other, many batteries of validation, run longer and longer, because you never get 100 percent certainty, only high certainty that keeps climbing. Even there, the useful posture is not fear but methodical risk management plus independence. The framework I keep returning to explains why. The Quest Engine</a> puts the WHY above the HOW, and runs three forces: Searching (what does better look like), being Driven (what can I control), and Renewal (am I still aligned). The risk matrix maps cleanly onto it. Searching is how you convert known unknowns into known knowns and surface the unknown knowns you were carrying as assumptions. Being Driven is naming what you actually control versus what the system controls, which is where the bias toward action lives. Renewal is the guardrails, rollouts, and reviews that carry forward, so the next change starts with a smaller unknown-unknown corner than the last. Read that way, hesitation is not an emotion to override. It is a risk assessment that has not finished running. It says "you have not yet categorized this," and the work is to place it in the matrix and build the matching rail. The one place this is weakest, and worth naming, is the genuinely first-of-its-kind change (no prior pattern, no meaningful canary, blast radius truly unknown). That is exactly where fearlessness is least earned and where slow, methodical, more-people matters most. The model is strongest for recurring operations and weakest for the novel one-off, and I would rather say that plainly than pretend the rails cover everything. So at a high level: staying hesitant at the work you do for eight hours a day is not a place to remain. If you feel empowered to make changes, you should feel empowered to take bold, reversible actions with a bias toward action, and keep people aware as you go. But that fearlessness is earned, not asserted. It rests on a blameless culture (in a blameful org, hesitation is rational, and no amount of mindset fixes that), on the standing to refuse the rush, and on the rails you built while you were still learning the risk. Fear is not the enemy. Unmanaged blast radius is. Hesitation is just the alarm telling you the risk is not categorized yet. You do not silence the alarm. You place each concern in the matrix, build the rail it points at, and then the hesitation is gone, because there is nothing left for it to warn you about, only a calculated risk worth taking. This maps onto the Quest Engine framework</a>: risk assessment as a Searching move (converting unknowns to knowns), a Driven question (what you actually control), and a Renewal answer (the guardrails that carry forward). For the WHY-above-the-HOW structure, see The Why Behind the How</a>. Related: Set. Action. Reload.</a> on closing the loop so gains compound, and Faith. Guts. Stamina.</a> on courage that has a direction. 9 Years of Copious Notes 2026-06-29T00:00:00+00:00 This whole thing started as a development journal in 2017. Nine years later, the notes are still going, but almost everything about how I write them has changed. The medium changed, the cadence changed, and most recently the author changed: it's now mostly AI driven. I want to walk through that evolution, because the shape of those files tells the story of how my relationship with note-taking shifted from manual discipline to something an agent does for me as a byproduct of the actual work. From sort-of-daily Markdown to one doc a year</h2> In 2017 I kept a development journal in Markdown. One file per day, sort of, at least once a week. The names were dated: 2018-01-08-masters3d.md</code>, 2018-01-09-masters3d.md</code>, on and on through the year. It was a development log, mostly manual, and the friction was real. You had to remember to write, create the file, and actually fill it in. Skip a few days and the gaps showed up right there in the filenames. Then I moved to Word, one document per month (2024_01_masters3d.docx</code>, 2024_02_masters3d.docx</code>, and so on). Fewer files, less ceremony, but the same manual habit underneath. Eventually that collapsed into one document per year, which I still maintain. The cadence kept relaxing because the discipline of daily logging never really stuck. The medium was always trying to make the writing cheaper. How AI changes the game</h2> The break came when the notes stopped being something I had to write. With AI coding agents in the loop, the log writes itself as a side effect of the work. That's the whole premise behind worklogs</a>: the agent captures context, status, and outcomes as you go, so you get the rigor of a lab notebook without the overhead. This is the Quest Engine's</a> Searching step made cheap: building the context that shapes a better decision, except you no longer pay for it by hand. Nine years of relaxing my cadence to fight friction, and the answer turned out to be removing the human from the writing step entirely. I don't open a file anymore. I tell the agent what's happening and it logs it, sizes it, and links the PR. The real value shows up later, in consistency. Because the agent logs everything the same way every time, those worklogs become a structured record you can mine. That mining is the framework's Renewing step: looking back at what happened and compounding it into something durable. Writing a brag document used to mean trying to reconstruct months of forgotten work from memory; now I just point the agent at the logs and a summary of what I shipped falls out. Consistency is what makes that possible: same format, same cadence, every entry there because it was free to write. There's a second payoff that hits every single day: picking up where you left off. The expensive part of resuming work was never the typing, it was reloading all the context you had paged out (what you were doing, what you'd already tried, what was blocked, what came next). A worklog is a warm cache for that state. Instead of a cold start where you spend the first half hour reconstructing where you were, the agent reads the log and you're back in the thick of it. That shorter startup time is what gets you into flow faster, and flow lives in the Driven step (the right-sized challenge with tight feedback). The warm cache doesn't size the work, but it removes the cold-start tax that breaks flow before you ever reach it. This is also why worklogs stay separate from effort tracking</a>: one answers "what am I working on right now?", the other answers "where is my time going?" Feeding the agent meeting transcripts</h2> The biggest recent change is what I feed the agent from meetings, especially the ones with more than two people. We've had recorded meetings and transcripts available for a while. For a long time I just took the summary (the auto-generated recap and the action items) and worked from that. The problem with a summary is that it has already thrown away most of the context. It tells you the decision but not the reasoning, the action item but not the disagreement that shaped it. Now I hand the agent the full transcript instead. The difference is night and day: the agent pulls the complete context, not someone else's compression of it. It can see who raised which concern, what was considered and dropped, the offhand comment that turns out to matter three weeks later. I don't always need to keep the full transcript around, but it is genuinely useful to have it sitting inside the worklog alongside the rest of the work it relates to. The meeting and the code it affects live in the same place, so the agent reads them together. This is the part that finally let me stop manually updating context. I used to be the one transcribing decisions into notes, distilling a meeting into the three lines I thought I'd need later, and I was always guessing wrong about which three lines mattered. Dropping the raw transcript into the worklog removes that step entirely. The agent does the distillation on demand, against the full record, with the surrounding work as context. The summary was lossy by design; the transcript-in-the-worklog keeps everything and lets the agent decide what's relevant when the question actually comes up. I still keep some notes private. Worklogs are internal to the team, not public, but they aren't the place for personal meeting notes either. That single yearly running document survives for exactly those things: 1:1 notes and private action items. I've also been looking into private worklogs to bring the same AI-driven flow to that material. But the trajectory is clear: from manual daily Markdown, to manual monthly and yearly Word docs, to a log an agent maintains for me. The notes never stopped; I just finally stopped being the one typing them. The Word "Impact" Considered Harmful at Work 2026-06-28T00:00:00+00:00 I do not like using the word "impact" in work settings. It sounds positive when we say things like "impact showcase," "impact recognition," or "25 years of impact." It sounds serious when we say "impactful work." But the same word is also used for layoffs ("10,000 employees were impacted"), outages ("10,000 homes were impacted"), and literal collisions ("meteor impact"). One word tries to cover progress, damage, and force. That is the problem for me. The word is too overloaded. One Word, Opposite Meanings</h2> Two people can use "impact" in the same meeting and mean opposite things. One person means value created. Another means harm done. Everyone hears the same word, but not the same meaning. And it shows up everywhere. Product updates say "high-impact feature." Compliance memos say "impacted regions." Incident calls say "customer impact." Performance templates ask for "impact statements." We keep using one label for wins, losses, and side effects, then wonder why conversations drift. I think that confusion matters because language shapes focus. Outcomes Matter More Than Force</h2> When teams review every six months, "impact" often becomes a short-term scoreboard. But what if your horizon is years? Many accomplishments compound slowly and only become obvious later. Early learning, foundational design, and system cleanup can look quiet for a long time before they create a hockey-stick curve. If you are shaping metal, a hammer blow can move it, but heat and pressure matter just as much. Sometimes precision tools leave a clearer mark with less force. Sometimes you leave a major mark with almost no collision at all. A bigger hit is not always a better result. Work is similar. The loudest move is not always the best move. Brute force is not always progress. A clean system, a better process, or good timing can produce stronger results with less disruption. This is also why outage language sounds off to me. We say things like "we do not want to impact the team with an outage." But the real goal is reliability, trust, and recovery speed. "Impact" blurs the real engineering target. Celebrate What Keeps Working</h2> I also think "impact" is the wrong word for celebrating accomplishments. We should celebrate behaviors and systems that repeatedly produce good outcomes, not a vague label. Growth is often logarithmic. It starts slow, then accelerates. If we only look for immediate force, we miss compounding progress. Take learning as an example. Learning can look like zero immediate effect until it gets applied. Then suddenly it changes execution quality, decision speed, and team leverage. Calling only the final visible moment "impact" misses most of the real work. And consider Benjamin Franklin's long run of failed experiments before breakthrough discoveries. Were those failures "not impactful" because they did not produce immediate visible results? I would say they were essential steps in a larger arc of accomplishment. There is another ambiguity problem: prevention work. Teams often give more credit to the person who fixes a visible failure than to the person who prevented the failure in the first place. We praise the dramatic rescue, even if someone else quietly prevented ten similar incidents. In plain business terms, there should be no difference between making money and saving money. But "impact" language often favors visible events over prevention behaviors and prevention systems. The same issue appears in "moving the needle." Yes, you can strike a needle and make it move for a moment. But what system keeps positive movement stable, measured, and sustained? If there is no monitoring and no reinforcement, that movement will drift back. The system that preserves gains matters more than the momentary move. To me, "impact" feels bumpy (like square wheels). You still move, but every turn is noisy. I would rather use language that feels more like round wheels: steady, clear, and directional. Use Words That Name the Result</h2> I would rather say: accomplishments</li> outcomes</li> goals reached</li> value delivered</li> problems solved</li> </ul> These words tell me what actually happened. If I had to keep the word, I would reserve it for narrow cases (for example, a formal six-month performance review rubric where terms are predefined and everyone agrees on the same meaning). Outside of that, I think it hurts clarity more than it helps. This post title is also a small homage to Edsger Dijkstra's "Go To Statement Considered Harmful." Not because "impact" is syntactically illegal (the compiler still accepts it), but because in normal conversation it jumps control flow straight past precision. The impact of using impact to both mean positive and negative movement of the needle is negative (and that is exactly why the word feels unhelpful in the first place). Related reading: Context Hunting vs Context Gathering</a>, Effort Tracking vs Task Tracking</a>, and Why I Love Worklogs</a>. Orthogonal, Not Opposite 2026-06-27T00:00:00+00:00 The first time I really tasted salted caramel, I had the thought a beat too late: salt was supposed to ruin this. Salt was the opposite of dessert. And yet there it was, the caramel reading as more sweet, more deep, more itself because of the salt, not in spite of it. The two were not fighting over one dial. They were turning up two different dials at the same time, and the place they reached together was somewhere neither one could get to alone. That little moment of confusion is the whole idea: salty was never the opposite of sweet. I had just been told they were, and I believed it. The Opposite of Sweet Is Not Salty</h2> Here is the part that turns a nice dinner into a method. Your tongue does not have a sweet-to-salty slider. It has separate receptors for sweet, salty, sour, bitter, and umami (five independent dials, not five points on one line). Sweet and salty are not opposite ends of anything. They are orthogonal, which is just the geometric way of saying they sit on different axes and one does not subtract from the other. You can crank both. That is what salted caramel is: a deliberate trip to the corner where two dials are high at once. So what is the opposite of sweet? Not salty. The opposite of sweet is not-sweet, the absence of sweetness. That sounds almost too obvious to say out loud, but it is the sentence that does all the work: the opposite of X is the absence of X, never some other quality we happen to contrast it with. The moment you pair X with a different quality and call them opposites, you have quietly collapsed two independent dimensions onto one line, and then you spend the rest of the conversation arguing about a tradeoff that you yourself invented. The tradeoff feels real because the line feels real. The line was never there. For the mathematically inclined, that is exactly what "opposite" and "orthogonal" mean once you draw the axes. Opposites live on the same axis: sweet is positive X, and its true opposite (not-sweet) is just the negative direction of that same X. You can absolutely model two qualities on one line, and sometimes you should, but only when one really is the negation of the other. The mistake is putting sweet on positive X and salty on negative X, because that quietly declares salty to be the absence of sweet, which it is not. Salty deserves its own axis, perpendicular to the first (its own Y), and "orthogonal" is just the word for two axes meeting at ninety degrees so a move along one adds nothing to and subtracts nothing from the other. So one dimension handles sweet to not-sweet, a second independent dimension handles salty to not-salty, and salted caramel is simply a point with both coordinates high. Add a third quality and you add a third axis, and so on (most of the pairs we call opposites are really separate axes wearing a shared label). The whole method is just refusing to fold two axes onto one line. Name It, Test It, Go to the Corner</h2> Once you can see one false opposite, you start seeing them everywhere, so it helps to have a small routine for catching them. First, name the supposed opposites. They almost always show up in a particular grammar: "you can't be both A and B", or "the more A, the less B." Any time a sentence asks you to trade one quality for another, stop and write down the two qualities as if they were two separate dials. Second, test for a real tradeoff. Ask the only question that matters: does adding A physically remove B? Salt does not remove sweetness. It sits there, on its own axis, coexisting. If turning one dial up does not turn the other one down, then they were never on the same line and the tradeoff was a story. (Sometimes the answer is yes, the tradeoff is real, and then you have learned something true. The point is to check rather than assume.) Third, go to the corner. If the two qualities are orthogonal, there is a quadrant where you are high on both at once, and that corner is almost always undervalued, precisely because the false-slider thinking told everyone it was impossible to be there. Nobody crowds into a place they have been told does not exist. The corner is where salted caramel lives, and it is usually wide open. This is also why most "balance" advice quietly fails you: "balance speed and quality", "balance ambition and humility", "balance structure and freedom" all assume a single line with a virtuous midpoint. Slider-thinking sends you to the middle. Orthogonal thinking sends you to the top-right corner, which is a completely different destination. The Corners We Refuse to Build For</h2> People systems are full of these invented sliders, and they are expensive because we organize entire careers and teams around lines that were never real. Take "technical versus people skills." These get framed as if every hour spent on one is stolen from the other, which is why orgs push people to "pick a track" so early. But they are plainly orthogonal: the rare and genuinely valuable engineer is high on both, and that engineer is the salted-caramel corner of the whole profession. We treat that combination as exotic mostly because the slider told us to expect a tradeoff and so we stopped building people toward both. "High-agency versus coachable" is the same mistake wearing interview clothes. It shows up in hiring debriefs as "they're strong-willed, so they'll be hard to coach", as though conviction and openness drained from the same tank. They do not. The best teammates are high-agency and coachable, which is exactly the profile the Quest Engine</a> is built around: people who own the next step and keep returning to check whether the step was right. "Fast versus careful" is maybe the most expensive false opposite in engineering, and it hides a quiet assumption that fast means sloppy. Often the opposite is true: the fast path is the one with fewer half-finished branches to babysit and fewer stale assumptions to drift out of date, so speed is how you stay correct rather than the tax you pay against it. The classic version is "good, fast, cheap: pick two", drawn as a triangle precisely so the three look mutually exclusive. But that is one more invented slider. With enough engineering up front (the tooling, tests, and continuous integration that let you move quickly without breaking things) you can be very good, very fast, and very cheap at the same time. The trick is that it depends on quantity: the upfront cost is fixed, so the more you ship across it, the closer all three corners get to free. That is the same self-healing-systems idea from Minimize Humans as Glue</a>: you do not ask a person to stand in the middle of the slider forever, you engineer the system so the middle stops being a place anyone has to stand. That is the real turn. A healthy people system does not ask people to slide to a compromise between two good things. It engineers away the false tradeoff so the both-and corner becomes reachable for ordinary people on an ordinary day. Tooling, scaffolding, and good process are the kitchen techniques that let you turn up two dials at once without the dish falling apart. The compromise in the middle is what you settle for when you have accepted someone else's line. The corner is what you can reach the moment you refuse the false opposite and start asking, for every pair of qualities you were told to trade between, whether they were ever opposites at all, or just two different kinds of sweet. This is part of a running thread on names and dichotomies that don't survive a second look. Context Hunting vs Context Gathering</a> and Stop Conflating Effort Tracking with Work Tracking</a> take two more pairs that get treated as opposites and pull them apart. The "engineer away the tradeoff" turn is the same systems-over-heroics idea in Minimize Humans as Glue</a> and Leverage and the Stairs You Build</a>, and the both-and corner is the high-agency, coachable profile the Quest Engine</a> is built around. 10,000 Hours Was Never Enough 2026-06-27T00:00:00+00:00 I remember reading about the 10,000-hour rule and finding it compelling. It gave expertise a shape. Put in the time, do the reps, stay with it long enough, and eventually you become excellent. There is something true in that. Time matters. Repetition matters. Sticking with something long enough to get past the awkward early stage matters. But after more than 10,000 professional hours in software engineering (and probably closer to 20,000 by now), I do not think the rule is a very good rule. Part of why I feel comfortable saying that is because software engineering was not the first thing I got deeply proficient at. Before I was a software engineer, I was a senior video editor. I am not going to say the paths were identical. They were not. But they were similar in one important way: you could absolutely spend thousands of hours getting faster at the familiar while staying narrow in what you actually knew. That is the problem with using hours as the headline metric. You can spend 10,000 hours doing the same thing over and over again and remain a beginner in every way that matters. You can spend 10,000 hours in a low-feedback environment. You can spend 10,000 hours never taking on higher stakes, never stretching your judgment, never owning outcomes. Time is necessary, but it is not sufficient. I think the real engine of expertise is repeated exposure to new constraints, real feedback, rising stakes, and ownership of outcomes. The hours help, but only if they are carrying those things. AI is making that distinction impossible to ignore. Hours do not create expertise by themselves</h2> What actually grows a person is not the passage of time. It is the friction of reality. If you edit the same kind of video in the same way for years, you can become fast without becoming broad. If you write the same kind of software ticket in the same corner of the system for years, the same thing can happen. You get efficient. You become reliable inside the groove. But expertise is not the same as comfort. Expertise comes from having to reorient yourself. A new kind of problem. A new system boundary. A production issue you did not expect. A cross-functional conflict that cannot be solved with code alone. A moment where your usual move stops working and you have to build a better one. That is why I have a hard time with the 10,000-hour framing. It hides the quality of the reps. It makes time sound like the cause, when time is really just the container. The contents of the container are what matter. This also explains why some people compound quickly while others stay flat. One person spends their years collecting new constraints and updating their mental models. Another spends those same years repeating a narrow loop. Both did the hours. Only one built the deeper form of expertise. What software engineering used to teach you for free</h2> For a long time, software engineering hid this distinction because the work itself forced a lot of learning. You had to fight the language. You had to fight the framework. You had to wire up the boilerplate. You had to debug syntax problems, dependency issues, bad tooling, vague error messages, confusing build failures, and all the small cuts that came with implementing something from scratch. A lot of junior growth came from wrestling directly with that terrain. That friction was not the same thing as expertise, but it often acted like training. It forced repetition with feedback. It forced you to understand how systems actually fit together. It forced you to build patience, debugging instincts, and the habit of tracing cause and effect through a messy stack. More importantly, software engineering did not just teach through code. It taught through consequences. You learned when your change broke production. You learned when your design did not survive real traffic. You learned when a handoff failed because the context was vague. You learned when another team could not use what you built because the interface made sense only inside your own head. Those were the experiences that actually shaped judgment. So when I look back, I do not think the real learning came from "typing code for a long time." It came from ambiguity, feedback loops, accountability, and having to absorb the results of my decisions. AI removes some of the old apprenticeship terrain</h2> This is where the conversation gets interesting. Agents are taking over more of the ramp-up terrain that used to be part of becoming an engineer. Boilerplate is cheaper. Syntax recall is less important. Spinning up a first draft is easier. The blank page is not what it used to be. A lot of the old friction is being compressed away. That is great for productivity, but it raises a serious question: if AI reduces the amount of time spent on low-level implementation, where does learning come from now? I do not think the answer is "learning goes away." I think the answer is that the learning moves. The scarce skills become things like: defining the actual problem</li> setting the right context</li> choosing boundaries</li> evaluating trade-offs</li> verifying that the output is correct</li> deciding what deserves human attention</li> owning the result when the agent was wrong</li> </ul> In other words, the center of gravity moves away from raw implementation and toward judgment. Coding still matters. Technical depth still matters. I do not think this becomes a world where you can float above the system and simply issue prompts. Someone still has to understand what good looks like. Someone still has to recognize when an answer is brittle, overfit, insecure, or just misaligned with the actual goal. But I do think the shape of engineering work is changing. The future engineer is not simply the person who can type the most code the fastest. It is the person who can create clarity, direct agents well, integrate context, and make good decisions under ambiguity. Software Engineering 3.0 is closer to alignment work</h2> This is why I keep thinking of this shift as a kind of Software Engineering 3.0. A lot of people are treating AI as just another tool in the toolbox. I do not think that is right. I think it is a transformation in the way the work is done, and transformations change which skills rise to the top. In my mind, software engineering has always sat near two neighboring functions: technical program management and strategy. There is a kind of Venn diagram here. One circle is deep technical execution. Another is alignment and coordination. Another is strategic framing and prioritization. The interesting thing now is that the overlap between them is getting more important, not less. That does not mean software engineers and TPMs are now the same role. It does not mean strategy replaces engineering. It means the valuable engineer is increasingly operating in the overlap: technical enough to judge the system, aligned enough to coordinate humans and agents, and strategic enough to frame the work correctly in the first place. That is also why the skill shift can feel surprising. Some abilities that used to be secondary now matter much more. Clear writing matters more because agents consume context. Alignment matters more because the cost of generating code has dropped, so the cost of generating the wrong code at scale has also dropped. Taste matters more because there are more plausible answers to choose from. Verification matters more because fluent output can still be wrong. So no, I do not think this is a story about coding no longer mattering. It is a story about coding no longer being the sole center of professional gravity. If the old story was "become an expert by doing the hours," the new story is more demanding: become an expert by owning outcomes in a world where implementation is cheap. That is the part I think the 10,000-hour rule missed. Hours were always incomplete. AI just makes the missing part impossible to ignore. This post connects to a few ideas I have been writing about lately: Context as Code</a> on why alignment artifacts matter more in an agent-driven world, Craftsmanship, Judgment, and Taste</a> on the human side of agent collaboration, and the growing overlap between engineering, coordination, and strategy that more people are starting to notice across the industry. Find Your Why: Mastery, Autonomy, and Purpose 2026-06-07T00:00:00+00:00 Hand someone a task and a paycheck, and they will do the work. Hand them a reason that genuinely interests them, and they will do the work even when nobody is watching, even when it gets hard, even when the paycheck is the same. That gap (between doing the work and being pulled toward it) is the whole subject of this post. The Quest Engine: The Why</a> treats this as the layer that sits above all the operational mechanics. Here I want to pull that layer out on its own, because it is the part most people never make explicit, and it is the part that matters most. The reason it matters: work only really gels when the motivation behind it is interesting to the person doing it. Not impressive to others. Interesting to you. This is the difference between extrinsic motivation (rewards and punishments that come from outside) and intrinsic motivation (the pull that comes from inside). Extrinsic motivation gets you compliance. It works until the reward stops or the punishment is no longer credible, and then it evaporates. Intrinsic motivation gets you engagement that sustains itself, because the doing of the thing is its own reason. You can stack bonuses on top of boring work forever and never produce the energy that a single interesting question produces for free. So the practical question is not "how do I motivate myself harder?" It is "what would make this interesting?" And the answer, almost always, comes down to three forces: Mastery, Autonomy, and Purpose. When all three are present, motivation takes care of itself. When one is missing, no amount of external pressure fills the gap. The value of naming them is diagnostic. When you feel flat about something you used to care about, you can ask which of the three has gone quiet instead of just concluding you are lazy or burned out. Mastery: The Pull to Get Better</h2> Mastery is the pull to get better at something that matters to you. It is intrinsic by nature, because the satisfaction comes from the closing of the gap between what you can do today and what you could not do yesterday. You cannot pay someone into the state of flow that mastery produces. It only shows up when the challenge is real and the person genuinely wants to meet it. This is why interesting motivation almost always has a learning curve in it. A task with nothing left to learn becomes a chore no matter how well it pays. A task that stretches you (just past the edge of your current skill, not so far that it is hopeless) pulls you forward on its own. Mastery is the searching force: the active hunt for what "better" actually looks like in your situation, and the steady work of getting there. When mastery is alive, you are not asking whether to keep going. You are asking what to learn next. When mastery goes quiet, the symptom is staleness. You are competent, you are bored, and you mistake the boredom for the work being beneath you when really the work has just stopped teaching you anything. The fix is not a new job. It is finding the next gap worth closing inside the work you already have, or deliberately raising the difficulty until the pull comes back. Mastery is not only a solitary, technical thing either. The gap you are closing can be a human one. Learning to lead, to teach, to read a room, or to bring a team along is its own kind of mastery (the skill is social rather than mechanical, but the pull to get better at it works exactly the same way). So even the most inward of the three forces can point you straight at other people, which is a useful hint that none of these forces is as cleanly separate as the names suggest. Autonomy: Ownership and a Map</h2> Autonomy is the force that propels you when you actually control something. It is the most misunderstood of the three, because people treat it as a single dial (more freedom, more motivation) when it is really two things working together: ownership and a map. Ownership is the part most people focus on. It is having real authority over decisions that matter, not just the responsibility for outcomes you were not allowed to shape. Borrowed responsibility without ownership is the fastest way to kill motivation, because you learn that your judgment does not stick. Ask permission for every choice and you eventually stop making choices at all (that is learned helplessness, and it looks like apathy from the outside but it started as autonomy being denied). Genuine ownership is the opposite signal: this is yours, the call is yours, the consequences are yours, and so the motivation to get it right is also yours. Autonomy also sits between the other two forces in a way worth naming. Mastery is something you generate alone and purpose is something you find outside yourself, but autonomy is the intermediate one: you can want it all you like, yet other people have to grant it and recognize it before it becomes real. That dependence is what makes it fragile, and it is also what makes it negotiable. Sometimes the way to secure autonomy is not to ask harder but to earn it sideways, by building the tools that make your ownership undeniable (automate the thing only you knew how to do, document the decision only you understood, and the authority over it tends to follow). You often have to construct the conditions for your own autonomy rather than wait for someone to hand them over. This is also why total autonomy is mostly a mirage. It is tempting to think you could escape the dependence entirely (work on a project purely for yourself, the way you might start an open-source side project and publish it on your own terms). But the moment the thing gets any real use, other people enter the picture as consumers, and consumers have needs. You can hold the line and only build what brings you joy, but any project used by more than one person will eventually ask you to work on features for other people so that they keep using it. That is not autonomy failing. It is autonomy in its honest form: a wide band of control with real edges, never the full hundred percent. But ownership without a map is just as paralyzing as having no ownership at all. Tell someone "you own this, do whatever you want" with no boundaries and no sense of the terrain, and freedom becomes a fog. They wander, they second-guess, they build something that does not connect to anything around it. The map is what makes ownership usable. It is knowing the shape of what you control and where its edges are: which decisions are fully yours, which ones you coordinate on, and which ones belong to someone else. The clearest version of autonomy sounds like "you own these decisions completely, you coordinate on these shared ones, and these few affect everyone so they go through review." Tight boundaries do not reduce autonomy. They make it real, because now you can act inside them without fear. The map also has a second use: it tells you which part of the work you are actually standing in. Any real piece of work moves through a loop (understand the situation, decide and act, then improve for next time), and ownership feels different at each station. Owning the understanding means you control what questions get asked. Owning the action means you control how the thing gets built. Owning the improvement means you control what the next cycle learns. When autonomy feels thin, it is often because you own one station of the loop but not the others (you can act, but you do not get to question the goal, or you can plan but never get to act). Mapping your autonomy onto the loop shows you exactly where the ownership runs out, which is usually exactly where the motivation drained away. Purpose: The Why That Renews</h2> Purpose is the force that connects the work to something that matters, and unlike the other two, it does not live inside you. This is the part most easily missed, so it is worth being blunt about: you cannot have a purpose that is only within you. Mastery runs inward (you are the one looking into how to get better, and the satisfaction is yours alone). Purpose runs the opposite direction. A purpose is always a connection to something outside yourself, and almost always that something is other people. Family, friends, a community, people in need, a team building something that genuinely means something to you. Being part of a group doing work that matters to you is not a path to purpose. It is purpose. The why, when you finally chase it down, usually turns out to be a who. That is also why purpose cannot be handed to you. It is deeply personal and unique to you, and nobody can prescribe it. Someone can assign you a task, but they cannot tell you why it should matter to you, and when they try, the reason stays hollow. You have to find your own, the same way you would search out anything worth having, by paying attention to which people and causes you actually care about and following that thread. This is the sharpest contrast in the three forces: mastery is the inward pull you generate for yourself, while purpose is the outward pull you have to go discover in the people you serve. Two forces pointing in opposite directions, both required, with autonomy bridging them in the middle. Purpose is also the force most prone to silent decay. Mastery and autonomy can both be fully present while purpose quietly drifts. You are learning, you have control, and yet the thing you are learning and controlling no longer points at anyone you care about. That is the most disorienting kind of flat, because nothing is obviously wrong. Purpose drifts because momentum carries you. You keep hitting milestones, you stay busy, and the original reason erodes from something specific ("help these people do this hard thing faster") into something generic ("ship the next item on the list") without any single moment where it broke. This is why purpose is not a thing you find once and keep. It is a thing you renew. Renewal means periodically stopping to ask out loud whether the work still connects to anything that matters, and whether the answer that was true six months ago is still true today. Sometimes it is, and you keep going with the original reason refreshed. Sometimes it is not, and naming that early saves you from months of competent effort aimed at the wrong target. The honest test for purpose is whether you can say, in plain words, why the work matters. If you cannot articulate it (if you reach for the reason and find only habit), that is the signal. Purpose has not been renewed, and the why has gone hollow. Catching that is not a crisis. It is the maintenance that keeps the other two forces pointed somewhere worth going. Find a New Why</h2> Put the three together and you have a way to read your own motivation. Mastery asks "am I getting better at something I care about?" Autonomy asks "do I own this, and do I know the shape of what I own?" Purpose asks "does this still connect to people or something that matters?" When motivation is high, all three are quietly answered yes. When it drops, one of them has turned to no, and naming which one is the entire game. Flat and bored points at mastery. Powerless and micromanaged points at autonomy. Drifting and hollow points at purpose. You do not need more discipline. You need to find which force went quiet and bring it back. This is also why "find your why" is not a one-time act of discovery, like there is a single correct purpose waiting to be uncovered. A why is something you search for, act on, and renew, the same way you would approach any hard problem. An interesting motivation is not handed to you. It is hunted: you explore until something genuinely pulls (mastery), you take real ownership of it so it becomes yours (autonomy), and you keep checking that it still points somewhere worth going (purpose). A new why is found the same way the first one was, by searching for what would make the work interesting again rather than waiting for the feeling to return on its own. It also helps to drop the idea that the three are dials you must hold at maximum all at once. They are not. This is a balancing act, a dance, where at any given moment one force leads and the others follow, and you almost never have all three at a hundred percent together. They trade off and reinforce each other over time rather than firing in unison. And because purpose is personal, the particular balance is different for every person. My own purpose, for instance, is simply to be in flow, and partly to show that people like me can reach high levels of engineering. But flow does not arrive on its own: it needs a real sense of mastery to sustain it, and that mastery needs enough autonomy and ownership to craft the work into something worth getting good at. So even a purpose that sounds entirely internal turns out to depend on the other two forces feeding it. You do not have to work on all three at the same time. You do have to keep them in conversation, because they only produce flow together. This is exactly where the Quest Engine</a> is useful, because it treats finding a why as a search and a drive rather than a flash of inspiration. The same three forces show up there as Searching (mastery: hunting for what "better" means), being Driven (autonomy: owning the path forward), and Renewal (purpose: checking the destination still matters). The engine gives you a repeatable way to run that search: explore until you find a pull worth following, take ownership of it, and renew it as your context changes. Working through it with AI coding agents makes the forces even more visible, because the moment you try to explain to an agent what you actually want and cannot, you have found the exact spot where one of the three has gone quiet. So if the work has gone flat, do not push harder on the how. Go back to the why, run the search, and find a more interesting one. The motivation follows the interest, not the other way around. This post pulls the human-motivation layer out of Quest Engine: The Why</a> and frames it through Mastery, Autonomy, and Purpose. For the full framework, see the Quest Engine introduction</a> and the Intrinsic Motivation</a> and Objective Function</a> pillars. Why Search Maps to Mastery, Not Autonomy 2026-06-07T00:00:00+00:00 When I first lined up the Quest Engine with the three human motivations, I made a tidy mistake. There's a natural-sounding way to line up the Quest Engine's three forces</a> with the three human motivations, and it is wrong. The intuition goes like this: autonomy is the freedom to explore, and exploring is searching, so Autonomy must map to Search. And if autonomy is the searching force, then Mastery (executing with skill) must be the driving force, so Mastery maps to Drive. It is a tidy guess. It is also backwards, and the reason it is backwards is the single most clarifying thing about the whole framework. The correct mapping is the plain one: Search is Mastery, Drive is Autonomy, Renew is Purpose. What makes it correct is not that the words rhyme. It is that each pair occupies the same moment in the cycle. Search and Mastery both happen before you act. Drive and Autonomy both happen while you act. Renew and Purpose both happen after you act, looking back. The mapping is settled by timing, not by vocabulary, and once you see the timing the confusion dissolves. The Order Settles It</h2> The three forces sit above the operational loop, and they mirror its three phases (understand, then act, then look back). Line the two triads up against those phases and there is only one arrangement that fits. Search is Mastery, and both come first (the before). Before you can act, you have to know what "better" even looks like. Search is the act of discovering what is worth aiming for. Mastery is the internal pull to grow toward it. Both are about defining the target, which is why they belong to the first phase (the knowing phase). "I need to get good at distributed systems" is a Search-and-Mastery statement: it is about what to aim for, not about permission to act. Drive is Autonomy, and both come second (the during). Once you know what to pursue, you need the authority to pursue it. Drive is the force you feel when you control the decision. Autonomy is ownership over how the work gets done. Both are about acting with control, which is why they belong to the acting phase. "I get to choose JWT versus session tokens" is a Drive-and-Autonomy statement: it is about who holds the decision, not about discovering that the option exists. Renew is Purpose, and both come last (the after). Once you have acted, you check whether it was the right thing to act on. Renew is the verification that you are still optimizing for what matters. Purpose is the connection to meaningful work that makes the answer legible. Both are backward-looking alignment checks, which is why they belong to the improving phase. "Is this work still serving our users?" is a Renew-and-Purpose question: it judges the target after the fact. Read in order (define the target, take control, verify the target), the pairs only fit one way. Swap Search and Drive and the sequence breaks, because you would be claiming you take ownership of a decision before you have figured out what you are deciding toward. The Autonomy-Feels-Like-Search Trap</h2> So why does the wrong guess feel so right? Because it is half true. Autonomy genuinely does help you search. An engineer with real freedom can poke at different approaches and discover what is worth learning, and that exploration looks a lot like searching. The intuition is picking up on something real. But it is picking up on an enabler relationship, not an identity. Having autonomy in one turn of the loop makes your searching better on the next turn (the cycle feeds back: what you owned and acted on this time sharpens what you go looking for next time). That is Drive in cycle one improving Search in cycle two. It is a connection between two different forces across time, not proof that they are the same force. "X enables Y" is not "X is Y." Confusing the two is exactly how the mapping gets flipped: you feel autonomy helping you explore and conclude that autonomy is exploration. It is not. It is the thing that, once you already know what to look for, lets you go after it (and in going after it, teaches you what to look for next). The Outside Check</h2> This is not just internal bookkeeping. Self-Determination Theory (the psychology research the human side rests on) names three needs: Competence, Autonomy, and Relatedness. Competence is the feeling of being effective and capable, which is the growth-and-skill need, and it lands squarely on Search and Mastery. Autonomy (the same word, the experience of choice and control) lands on Drive. Relatedness, the connection to people and meaning, lands on Renew and Purpose. The part worth noticing is that Competence, not Autonomy, is the one tied to growth and skill. If the framework had mapped Autonomy to Search, it would be claiming the exploring-and-growing force is the autonomy need, and SDT says otherwise: the growing force is Competence (Mastery), and autonomy is its own separate need about control. An independent body of research, built for entirely different reasons, arranges the three needs in the same order the cycle does. When the timing argument and the psychology agree, the mapping is not a stylistic choice. It is structural. The practical takeaway is small but sturdy. When you try to place one of these forces, do not ask what its name sounds like. Ask _when it happens. Before you act, that is Search and Mastery. While you act, that is Drive and Autonomy. After you act, that is Renew and Purpose. The order is the answer, and it is why the intrinsic motivations</a> slot into the why behind the how</a> in exactly one way._ Context as Code 2026-05-30T00:00:00+00:00 I remember when configuration was treated as an afterthought. It lived in a file someone edited by hand on a server, undocumented, unreviewed, owned by whoever touched it last. Then the industry grew up. Configuration became code: versioned in the same repository, reviewed in the same pull requests, tested in the same pipelines, owned with the same seriousness. Infrastructure as code, config as code. We stopped pretending the settings that determine how a system behaves were somehow lesser than the logic inside it. I want to make the same argument for context. The corpus of context that aligns a team should be held in the same regard as configuration and code. Not below it. Not the thing you write up afterwards if there's time. At the same level. I'm deliberately saying context and not documentation. When people hear "documentation" they think of a chore, the thing nobody wants to write, the stale wiki page nobody reads. And there are genuinely different tiers of it. The note you drop in an issue is short-lived context, useful in the moment and fine to leave behind. The durable layer is different: the design docs, the contextual documents, the written-down "why" that creates alignment and cohesion across a team. If you want it to last, it eventually belongs in a real system (an internal site, a corpus you can navigate), not buried in a ticket. That durable layer is what I'm pointing at, and "context as code" names it better than "documentation" ever did. Context Lives at Every Layer, Not Only Up Front</h2> I used to think the cognitive artifacts always come first: write the design doc, get alignment, then write the code. That's one valid order, but it's not the only one, and insisting on it misses how the work actually happens now. Code is cheap. It's getting cheaper every month. So it's entirely reasonable to write the code first. You might have two or three demos going, different approaches you're trying to align on, and you only know which one is right after you've built them and watched them run. Then you extract the design from the one that worked. The context didn't precede the code there. It was distilled out of it. That's still context as code, and it's still first-class. The point isn't "documents before code." The point is that context shows up at every layer, and wherever it shows up you treat it as a real artifact instead of letting it evaporate. Sometimes you write the alignment doc to decide what to build. Sometimes you build three things and write the alignment doc to capture which one won and why. Both produce the same durable asset: a clear, shared mental model that outlives the moment it was created in. The Operating System of a People</h2> Here's the framing that makes context click for me: context is an operating system for groups of people. Think about how religious texts function. Whatever you believe about them, a text like the Bible operates as the shared operating system of an enormous group of people. It encodes the values, the guiding principles, the "this is who we are and this is how we do things." It's the corpus that lets people who have never met act with cohesion. We even borrow the metaphor in our own field. When something becomes the definitive corpus of knowledge, we call it the Unix Bible, or the bible of whatever domain it covers. The word signals exactly this: the canonical body of context that aligns the people who follow it. A team has the same need at a smaller scale. The thing that lets folks who weren't in the original room build in the same direction, raise the quality bar, and contribute without re-deriving every decision from scratch is the corpus of context. Lose it and a team's quality ceiling is set by whoever happens to hold the most in their head. Write it down and the ceiling is set by the whole group. Why Agents Make This Urgent</h2> There's a new reason this matters, and it's the one that pushed me to name it. LLMs run on data. Agents now operate inside our environments, and they're doing exactly what a new teammate does on their first week: trying to understand what we're about, how we work, what to do here and what not to do. They need a corpus of grounding. They need something that says, within this team this is what we do, these are our guiding principles, this is the way we do things. Some of that grounding lives in configuration. Some of it lives in the code, in comments that never surface to a user but explain the local "what." But the hardest and most valuable part, the why, is exactly the part that resists living in config or code. Why the system is shaped this way. Why we made this tradeoff and not the obvious one. The single cohesive story that ties the pieces into one mental model of how the team works and how this thing came to be. That can't be a comment buried next to a function. It has to be an alignment document, a context document, deliberately written and maintained. That corpus is the operating system for the humans on the team, and now it's the operating system for the agents reading alongside them. Which is why it deserves the full treatment. Version it. Review it. Own it. Keep it current. Hold it to a standard. We did all of that for configuration once we admitted it was as load-bearing as the code. Context is more load-bearing still, because it's the thing that produces both. Configuration became code when we admitted that it determines how a system behaves. Context deserves the same treatment because it determines how people and agents understand that system in the first place. Worklogs</a> capture the context of the work, while context hunting</a> finds what is missing. Version it, review it, own it, and treat your context as code. Minimize Humans as Glue 2026-05-30T00:00:00+00:00 Tanya Reilly's talk Being Glue</a> is one of those pieces of writing that reorganizes how you see your own week. The idea is simple and uncomfortable: every team runs on a layer of invisible work (coordinating, unblocking, onboarding, documenting, smoothing over the rough edges between people). That work is real, the team genuinely needs it, and it is almost never the work that gets you promoted. Reilly calls it glue, and she points out the trap inside it. The people who hold the team together with glue often watch less helpful, more visible colleagues move up the ladder while their own careers quietly stall. I lived the trap before I had a name for it. A few years back I learned about Being Glue, and it landed hard because I was exactly the person being described. I ran the ad hoc meetings, I jumped on every quick debug session, I taught everyone my process before I had even finished proving it worked. The team was genuinely better for all of it. And yet none of it pointed back at me. When promotion season came around, the work that moved the dial was the work with a clear, individual attribution, and almost nothing I did had my name cleanly on it. The team rose; I stayed put. That is the part of the talk I wish someone had handed me earlier: glue is most dangerous precisely for the people who are not yet at the top of the ladder, because that is the stage where you most need legible, attributable wins, and glue is the work that refuses to be attributed. Practicing the way out</h2> So once I recognized myself in the talk, I started to implement a way to get out of being glue. It might seem hard, especially if folks already expect you to do it (you are the one who runs the meetings, onboards new people, keeps the docs current, and nobody else has stepped up). But over a few semesters of practicing not being the glue, not being the firefighter, and not doing things for other teams just to be helpful, the habit reshaped itself. A few concrete moves did most of the work: Start saying no. This is the unglamorous core of it. Notice the tasks that are easy for you and hard for the team, the ones you grab on reflex because grabbing them feels good, and let them go when they will not move the dial.</li> Give other people the opportunity to learn something only you know how to do. Hoarding a skill makes you the permanent glue for it. Handing it off creates a second owner and frees you.</li> Better yet, have an agent do it instead of you (or have the agent send the PR). A lot of recurring glue is now automatable. If a coding agent can produce the change and open the pull request, your hands stay free for the work that moves you up.</li> Instead of setting up the meeting, have an agent write the email and send it. Most coordination glue is a communication task in disguise. Draft once, automate the rest, and reserve synchronous time for the things that genuinely need it.</li> Spend more time on learning. The hours you reclaim from glue are best reinvested in getting more proficient, which is the thing that actually compounds.</li> </ul> A useful way to budget the reclaimed time is to split it deliberately: 80% on what will move you up the ladder, 15% on novel things, and 5% on moonshot, high-leverage bets. The 80% keeps your trajectory honest, the 15% keeps you growing, and the 5% is where the outsized wins occasionally come from. The clearest example is the AI engineering work I have been doing. The old me would never have started that journey alone. I would have insisted on bringing the whole team along, spending hours teaching folks my process one at a time, pacing myself to the slowest shared understanding. The new me moves as fast as I can. If, as a byproduct, other people see what I am doing and learn from it, wonderful. But guiding and teaching is no longer the goal. The goal is to be as proficient as I can be, and then, only if it does not become too much overhead, I show other people. That reordering sounds selfish written down. In practice it has worked better for everyone than the martyrdom did. My PR count is higher. My synchronous meetings are down. The work has my name on it now. I used to get a real hit of satisfaction from unblocking someone while my own task sat untouched. That feeling is seductive and it is a trap, because it pays you in the currency of being needed rather than the currency of progress. Now I put my own oxygen mask on first. The airline instruction is not a metaphor for selfishness; it is the observation that you cannot help anyone if you have passed out. Patching versus fixing</h2> The biggest lesson underneath all of this is about systems, not personalities. The longer I thought about Being Glue, the more I realized it describes the same thing as a high-maintenance system: something that only keeps working because a person keeps manually intervening to hold it together. The article catalogs the human version (onboarding, unblocking, documentation, all the work that keeps a human system effective), but a lot of those pain points now have real solutions. Onboarding can run through an agent. Coordination can be automated. The glue does not have to be a person. When I was a kid I had an uncle with an old car. He never used glue to keep it going, but he had something better: he cut up old bicycle tire tubes into rubber bands and used them for everything. Binding two pieces of pipe together, stopping a rattling panel, holding things in place. Rubber is, technically, a kind of glue (a stretchy patch you apply to a problem so it holds for a while longer). I always thought about how unnecessary a lot of those patches were. It is the same instinct as a slow leak in a tire: you keep pumping air into it every morning instead of taking it apart and fixing the puncture once. Now, whenever I face a system that needs constant maintenance, that is the image in my head. Stop pumping air. Take it apart. Repair the underlying cause, not the symptom that keeps resurfacing. On-call is where this bites hardest, and I would extend the Being Glue idea straight into it. In my mind, on-call is the exception, not the rule. It is a gap where you did not design the system to heal itself. Yes, sometimes you carry the pager, and yes, sometimes you get called, but the threshold for waking a human up (or interrupting their weekend) has to be very, very high. Any situation that requires a hero to save the day is a situation where a human is being used as glue: the system does not work without that person standing in the seam. That is not a system that needs more glue. That is a system that needs fixing. Throwing humans at a problem that should not require humans is the core mistake. Reilly's framing is that you should be deliberate about which glue you pick up and make sure your visible, attributable work does not starve. The extension I would add is that the glue you are tempted to apply is usually a signal that something underneath is broken, and the higher-value move is to fix it at the root rather than to keep patching the seam with your own time. So when something breaks, fix it for good and add a monitor that catches the same deviation next time, instead of patching it and waiting for it to break again. Self-healing first; humans only for the genuinely novel failure. The way to keep yourself honest is to measure where your time is actually going. Track it, and clearly see how much of it is glue work. Some glue will always be needed (you want awareness across the whole team, and a person is often the right carrier for that), and as long as it stays minimal and is shared evenly, that is fine. The problem is only when the glue is one overloaded person, or when we keep using people where a self-healing system belongs. So this is not an argument for never helping. It is an argument for minimizing the cases where a human has to be the glue at all. Put your own oxygen mask on first (you cannot help anyone if you have passed out), automate or hand off the recurring patches, and reserve human attention for the rare, novel break that genuinely needs a person. Build systems that heal themselves and monitor themselves, repair them at the source when they fail, and let people do real work instead of being the glue holding a patch in place. This post is a reflection on Tanya Reilly's Being Glue</a>. The systems-over-heroics theme also runs through Leverage and the Stairs You Build</a>, and the team-ownership counterpart is in Team Identity Ownership</a>. Team Identity Ownership 2026-05-30T00:00:00+00:00 Team identity is the first place a team takes ownership. Everything else about a team can be handed to it (the goals, the problem, the people, the place in the org chart), but the identity is the one thing the team can claim for itself. Choosing a name is the first step into taking your destiny into your own hands and starting to take care of your own. It is the first thing that creates a sense of belonging, and it is so often ignored even though it is such a multiplier. The thing to understand up front is that belonging cannot be dictated. A sense of being part of the team has to be adopted, not assigned. It has to be organic. The rest of this post is about how that ownership gets built, and why it has to stay local to work. My path ran the opposite way from most people's: I started in open source before I ever took a full-time software engineering role. The first thing I noticed in open source was that nobody there talks about a "team." They talk about a community. When I was deep in the Swift world, we even tried to give ourselves a name: Swifties. It never really stuck (people kept trying, and there were always jokes about how it borrowed from a certain pop star's fan base). But the attempt is the interesting part. We had a common language, a common set of rules, and a common way of communicating (the forums, the GitHub issues). The community was the team, and the glue showed up on its own. Everyone was already there because they liked the thing. When I later started working full time as an engineer, the word "team" meant something completely different. Inside a big company you get an org, and that org has sub-orgs, and those have sub-sub-orgs, all arranged by the reporting structure. At the bottom of that tree is your team, which usually means the group of people who report to the same person (sometimes it means a group that shares a common skip-level instead). The container looks similar to a community, but the thing that brought everyone together is not the same. You are not gathered around a shared love of the work. You are gathered around a problem someone needs solved. From Community to Team</h2> A company team is problem-and-solution based. You are handed a set of goals and asked to go solve them, and most of the time you do not get to choose who you solve them with. You can occasionally move teams, but you rarely get to assemble one. So you can wake up one day surrounded by people who do not have much in common with you. They may not like the same language. They may not think the same way. And that is fine. But it means the cohesion that open source gets for free is something you now have to build on purpose. That part is genuinely hard, and how hard it is depends a lot on the style of the company and the org you sit in. Like it or not, every organization rewards some functions more than others, and a lot of the time the best thing to do is not the best rewarded thing to do. The two often line up, because aligning them usually makes sense, but they do not line up all the time. So you are trying to forge a group out of people who did not pick each other, working toward goals they did not choose, inside a system that does not always reward the right move. That is the situation. The question is how you create an identity strong enough to hold up inside it. In open source the identity is easy because you are already attracted to the work. Inside a company you are being paid to do something that may or may not be exciting on its own. So the first job is to make it exciting, and I think that starts with the team deciding it has an identity at all. Start With a Name</h2> Build the identity together, regardless of what you have been assigned to work on. The single most useful move is to let the team call itself something it actually likes, rather than wearing the label that got handed down from above. Having your own name helps more than people expect, especially when the name is something specific and a little bit yours. It is hard to rally around the "software update team," or the "networking team," or the "compute team," or the "tools team," or the "support team." Those are descriptions of a function, not an identity. Nobody feels anything when they say them out loud. A name you chose is different. It is the first artifact the team makes together, and it signals that this group is a thing, not just a row in an org chart. It costs nothing and it gives people something to belong to before any of the hard work has even started. Write Down How You Work</h2> The next layer is a way-of-work document: a plain description of the mechanical things, how you actually do work day to day. How do you track work? Where do the artifacts live, and how do you create them? What are the small, ordinary routines that a new person would need to learn in their first week? Write those down. Keep it a living document and update it as the team changes. It sounds bureaucratic, but it does real work for alignment and cohesion, because it turns "how we do things here" from folklore into something you can point at. You can go one step further and write an alignment document, or a short set of principles the team believes in. Most companies already have principles, and the ones handed down from above tend to get espoused and then quietly ignored. The homegrown ones are the ones that stick. On a team I was on, one principle was that a design document is simply something you always write (that one came from above, but we adopted it). Another was that each person sits on a single on-call rotation, never two or three. That second one matters more than it looks: a single rotation can be planned around and kept at a sane level, while stacking two or three rotations on one person quietly means they are effectively always on call. There are dozens of principles like that, and the value is not in the list, it is in the fact that the team forged the list together. That is part of the identity, and it has to be built as you go, not received. Keep It Local</h2> The most important thing about a team identity is that it has to be local. It cannot be a remote identity, the kind where leadership tells hundreds of people "we are all one big team." The human mind does not wrap itself around hundreds of people. The two-pizza rule applies here for a reason: an identity is something a small group can actually feel, and it falls apart at scale. Yes, you still need some alignment on what the larger org is doing and where it is headed, and that direction has to exist. But the thing worth striving for, the thing that becomes a real multiplier, is the local identity of the small group you sit with. Team identity is the foundation you build everything else on. In open source it arrives for free, carried in on the shared interest that brought everyone together. Inside a company you have to make it yourself: pick a name you like, write down how you work, agree on the few principles you actually believe in, and keep all of it local enough that the people on the team can feel it. That is the part I would fight for. Language Choice in the LLM Era 2026-05-24T00:00:00+00:00 I started programming in 2014, but I could have started much earlier. C and C++ were barriers for me. The syntax was esoteric, the learning curve steep, and the error messages felt like they were written in a different language. It wasn't that I lacked interest in programming (it was that the most visible languages at the time felt deliberately inaccessible). Then I found Python. Python was the language that got me excited about learning to code. It read like pseudocode. The barrier to entry was low enough that I could start building things immediately. This was around the time when people were still calling it "big data" (before the AI craze took over, though deep learning and supervised learning were already in motion). JavaScript won on the browser by accident. It was never meant to be the lingua franca of the web. It was a 10-day prototype that happened to ship at the right time in the right place. No committee designed JavaScript to be universal (it became universal by being the only option). That accident shaped decades of web development. We built frameworks on top of frameworks to make JavaScript bearable, then usable, then powerful. The language's flaws became features we learned to work around. While I took a couple of classes in JavaScript, it never really caught my attention. The language that caught my attention was TypeScript. I like TypeScript a lot, and if I ever need to write anything for the web, you bet I'll use TypeScript. After Python, I learned Swift. Apple had just released it as the new language for their ecosystem, and it was beautiful. I was hooked. Then I formally learned Java at a nearby college (and again during my master's degree). When I started my job at the time, I worked with C# and C++ 11. Rust had come out in 2010, and I knew about it then, but the language seemed very esoteric. After learning C++ and Swift, Rust didn't seem that esoteric anymore (but it was still a niche language). At some point during that job, I learned Go, and I really liked it. Swift had taken a lot of ideas from Go (the defer</code> keyword, the func</code> naming convention, the overall simplicity). Most of my professional career so far has been C#, Go, Python, C++, and Rust. More recently (during a break), I wrote a couple of Rust applications for some internal tools I use for work. I say all of that to say: I do consider myself a language fanatic. Or at least I was. When I was learning Python, Python was the only thing I could think of. How do I find excuses to use Python? When I learned Swift, I wanted to write everything in Swift. I went through that process with Go as well. I have been through that mental model. I don't feel like I'm like that anymore. That phase has faded. I don't tend to say "let's write everything in X language." I've written plenty of domain-specific languages (DSLs) like PowerShell and Bash for scripting, SQL-like languages for data access, and even XML-based configurations for calling C++ modules</a>. You can get a lot done with DSLs. I've also seen plenty of cases where languages are shoehorned into JSON for configuration (those are DSLs too). The Decision Matrix</h2> Now that we're in this world of LLM-driven development, the language choice landscape has shifted. What matters isn't whether I personally find a language elegant (it's whether the language solves the problem at hand with the right trade-offs). Here's my decision matrix, broken down by deployment target. Frontend (Visual UI for end users): Web: TypeScript</li> Mobile Android: Kotlin (the modern replacement for Java, though I wouldn't rewrite existing Java to Kotlin)</li> Mobile iOS: Swift</li> Desktop Windows: C#</li> Desktop macOS: Swift</li> Desktop Linux: Rust</li> </ul> CLI (Command-line tools): This is the bridge most people miss. CLI tools are more portable than visual UIs, and while some are meant for end users, many are meant for servers or automation. Yes, you'll need platform-specific bash or PowerShell scripts, but I wouldn't write more than the bootstrap code there (the code that installs the executables). For actual CLI tools, assume cross-platform only. Cross-platform CLI (automation, developer tools): Go, Rust</li> Cross-platform CLI (quick scripts, one-offs): Python</li> Performance-critical CLI: Rust</li> </ul> The rule of thumb: If the CLI will grow beyond a few hundred lines or needs distribution as a binary, use Go or Rust. For quick automation that stays small, Python works great. Python won on portability for CLI tools. Even when the core logic is written in a compiled language, deploying code is often better using the Python ecosystem. I covered this extensively in my previous article about Rust and scripting languages</a>, where I discussed how Claude Opus 4.5 made writing Rust feasible for CLI tools in ways it wasn't before. Server (Backend, APIs, services): The server is where the real diversity shows up. REST APIs, web services, large teams: C# (ASP.NET Core) or Go. C# is not a Windows-only thing (ASP.NET Core runs on Linux, macOS, and containers just as well as it runs on Windows). It's a fully viable cross-platform server solution.</li> Microservices, distributed systems: Go or C#</li> Server utilities, automation, DevOps tools: C#, Go, Python</li> Performance-critical servers, systems programming: Rust</li> Constrained environments (embedded, IoT, real-time systems): Rust</li> </ul> The rule of thumb: If you need to stand up a server with REST endpoints, talk to databases, and onboard a big team (you cannot go wrong with ASP.NET Core (C#) or Go). Both have excellent ecosystems, strong typing, and can handle large codebases. I don't think Python is the right solution for server work as of today. I know there are successful projects that use Python for servers, but the lack of static typing and the deployment complexity make it less ideal. As you go down the stack and have to run on smaller, more constrained environments, Rust comes into play. Anytime you would have used C/C++, Rust is a good replacement. When you need the level of control that C++ provides, using Go or C# would introduce a garbage collector that might not be appropriate for the use case. We can see this very well in the world of game engines. The Godot game engine is written in C++, but all of the client code (what people use for scripting) is usually in different languages. I've seen how the garbage collector's global stop or global pause can introduce issues for end users. In AI, every time there is an issue with performance or control, we tend to use a combination of C++ and Python. C++ for the performance-critical parts, Python for the glue and the high-level logic. The LLM Era: Even Coding Agents Show This Diversity</h2> The equation does change when it comes to AI. LLMs are able to write Rust just as easily as they can write PowerShell. The barriers that once made certain languages intimidating have lowered significantly. C and C++ were once barriers for me (but now by choice, I use other languages instead). Interestingly, even coding agents themselves show this diversity in language choice: Codex CLI</a>: Written in Rust (performance-critical, cross-platform distribution)</li> Aider</a>: Written in Python (rapid iteration, pip-based distribution)</li> Antigravity CLI</a>: Written in Go (server-like characteristics, cross-platform)</li> Claude Code</a>: Written in TypeScript (web ecosystem integration, npm-based distribution)</li> </ul> The diversity is striking. While Aider does use Python, most newer coding agents prefer compiled languages or TypeScript. The deployment story matters tremendously. For internal tooling, I like the idea of using GitHub releases for distributing executables with a very clear deployment story. Each tool chose the language that best fits its deployment target and trade-offs. That's the lesson here (there is no single "best" language). The question now comes down to: What are the capabilities of the language? What area do you need to address? Deployment of the code becomes a big issue. You need to have a very well-understood deployment story. I don't think I'm picky when it comes to languages. I just probably don't see myself writing C++, C, or JavaScript unless I have to. And right now, I don't feel like I have to, given that we have so many other languages. I don't think I have to write JavaScript anymore. The languages that probably are most popular (C, C++, JavaScript) are probably ones we don't need to write anymore. They could be targets. You write TypeScript, and then that gives you JavaScript as a compiled output. That's fine. No, I'm not going to port anything to Rust (or Kotlin, or any other language) that's already written in a different language. I don't think that's pragmatic. But I do think new things (new things that don't have dependencies or existing infrastructure) should probably, at the very least, be written in a static language. That's my high-level thinking. I am very excited about Mojo, which is meant to bridge the gap between Python and Rust. As of this writing, it's not yet GA, so it's not something I could even consider. But even then, in a world where we have Mojo (meant for accelerators), I will probably still choose Rust, Go, C#, or another compile-time language for most cases. What matters now isn't just syntax or learning curve (it's the entire ecosystem). The deployment story has become critical. Language capability matters (can it interoperate with other languages in your stack?). Community alignment is crucial (it would be a hard sale to write something in C# at a company like Amazon where most of their stack is Java, though Go might still be chosen because of its different capabilities). We've seen this play out in real projects. The Ladybird browser initially attempted to move to Swift, but they faced capability issues and needed to be pragmatic, so they moved to Rust instead. These are the kinds of trade-offs that matter now: tooling, deployment, compile-time guarantees, language interoperability, and how well the language fits both the problem and your community. LLMs can write in any language, but that doesn't mean all languages are equally good choices. Choose the language that gives you the guarantees you need, the deployment story you can live with, and the ecosystem that supports the problem you're solving. For more on my experience with Rust development in the LLM era, see My AI Tools Journey Since Claude Opus 4.5</a>. For why my favorite language never made it into my professional work, see My Swift Journey: Why I Love It but Can't Use It at Work</a>. Faith. Guts. Stamina. 2026-05-16T00:00:00+00:00 In Sing 2 (2021), Buster Moon has just been told he's not good enough. He goes back to the person who believed in him first. Nana Noodleman (an elderly sheep, his original mentor) doesn't offer comfort. She asks the one question that matters: Do you think you're good enough? Buster says yes. She doesn't let him stop there: "Then you must fight for what you believe in! Guts, Stamina, Faith. Those are the things you need now." </blockquote> Three words. The phrase also exists outside the film. Chenmark, a private investment firm founded in 2015, has run their weekly newsletter under the same three words as company values since before the movie existed. Whether or not the filmmakers drew from that source, the convergence is worth noting: two independent sources arriving at the same triad suggests it names something real. But Nana's order (Guts, Stamina, Faith) is the order of urgency, not the order of dependency. That's the part worth examining. The Order That Lands Versus the Order That Works</h2> Nana leads with Guts because Buster needs it in the next five minutes. That's the right call for the moment. But Guts without Faith is undirected energy. You can have enormous courage applied to the wrong thing and accumulate nothing but well-executed wrong turns. Faith belongs first. Not as a spiritual concept, but as the Searching move: knowing what you're fighting for before you fight. Faith is what makes Buster's courage coherent. He isn't just persistent (he's persistent about this specific show, these specific performers, this specific belief that they deserve the world-class stage). The faith came before the guts. The courage only has a direction because the faith established it first. Guts comes second. Once you know what matters, guts (in the "it takes guts" sense, the courage to act despite uncertain outcomes) is the force that converts knowing into action. Ownership over the step that might fail. You've done the "searching", you know what you believe in, now you fight for it. That's the Driven move: not recklessness, but the willingness to act from conviction without waiting for guaranteed outcomes. Stamina closes the loop. Knowing and starting aren't enough. You have to keep "returning". Stamina is the Renewal move: every "return" is a check. Is the faith still grounded? Is the conviction still clear? Stamina understood this way isn't just toughness. It's the consistent "return" that makes the whole thing compound. The Reordering</h2> The Quest Engine</a> names these three forces: Searching, Driven, Renewal. Faith maps to Searching (knowing what direction is worth fighting for). Guts maps to being Driven (the courage to act on what you've found). Stamina maps to Renewal (the consistent "return" that makes each cycle build on the last). Nana asked Buster whether he believed he was good enough before she gave him the three words. That belief (the faith) was the precondition for everything that followed. The order she delivered them was a coach reading the room. The order they actually operate in is: Faith. Guts. Stamina. Nana Noodleman (voiced by Jennifer Saunders) delivers this line to Buster Moon (voiced by Matthew McConaughey) in Sing 2 (2021, written and directed by Gareth Jennings). The same three words appear as company values at Chenmark, a private investment firm founded in 2015 by James Higgins, Trish Higgins, and Palmer Higgins, whose weekly newsletter has carried them since before the film. "Faith. Guts. Stamina." maps directly to Search, Drive, Renew in the Quest Engine framework</a>. For the complete framework, see the Quest Engine introduction</a>. The motivational triad version is in Determined. Driven. Consistent.</a> (Brady's Hall of Fame answer, reordered). The path version is in Knowing, Walking, Returning</a>. The existential version is in Discovery, Play, Joy</a>. One territory, several maps. Context Hunting vs Context Gathering 2026-05-05T00:00:00+00:00 I've started replacing the phrase "context gathering" with "context hunting" in how I talk about this kind of work. The word swap is small. The mindset shift is not. Gathering implies that context is already out there, loosely scattered, waiting to be collected. Like picking up seashells on a beach. You walk around, you crouch down, you put things in a bucket. The context is just... there. Hunting is different. Hunting means the thing you're after is not lying around. It's hidden. It might be moving. It requires patience, skill, and a willingness to go somewhere uncomfortable to find it. You don't find context because it was sitting in plain sight. You find it because you went and chased it. The Hunt Looks Like This</h2> The other day, someone asked me about a very specific way a system gets into a particular state. One of those questions that's deceptively narrow on the surface but implies a whole chain of events underneath. My honest answer: I didn't know. But I knew something else: the code exists. The system is in production. The behavior happens. Whatever causes it is written down somewhere in the codebase, because code is the only thing that actually runs. So I went to the code. I started from the state in question and worked backwards. What writes to this field? What triggers that function? Which callers pass this flag? I read through the logic, followed the branches, traced the transitions. I wasn't reading documentation (there wasn't any for this). I wasn't asking someone who might know (that person might not exist). I was reading the primary source: the code itself. After working through it, I could describe exactly how the system arrives at that state. The sequence of events. The conditions that have to be true. The edge cases. I had extracted from the code something that wasn't written down anywhere else. I wrote it up, put it on the wiki, opened a PR, and now the team has that context permanently. The next person who asks that question gets an answer in seconds, not an investigation. That's context hunting. You start with nothing except the belief that the answer exists somewhere. You go find it. You bring it back and make it permanent. Why "Gathering" Gets It Wrong</h2> The word "gathering" has a quiet problem: it implies someone else created the context and you're just picking it up. In a mature, well-documented codebase, sometimes that's true. There's a wiki page. There's a design doc. There's a comment in the code that explains why things work this way. You "gather" it. Fine. But most of the interesting questions (the ones people actually ask you) are interesting precisely because the context doesn't already exist in a form you can just consume. The behavior is emergent. The state was never explicitly documented. The reason it works this way got lost when the person who built it left the team. The context is latent, embedded in behavior and code, and it takes work to surface it. Calling that "gathering" undersells what's required. It makes the process sound passive, almost accidental. "I gathered context while working on the ticket." What actually happened? You spent forty-five minutes tracing calls across four services, figured out why the retry logic behaves differently under a specific race condition, and documented it so no one ever has to do that again. That's not gathering. That's hunting. The word signals something important about what the work actually demands: agency, curiosity, and a willingness to go into the unknown rather than wait for someone to hand you the answer. The High-Agency Version</h2> There's a broader principle here that I keep coming back to: low-agency behavior waits for context to arrive, high-agency behavior goes and gets it. When you're stuck because you don't understand how something works, the low-agency move is to block yourself on the ticket and wait for someone to explain it. The high-agency move is to go read the code, run the thing, trace the logs, form a hypothesis, test it. You might be wrong. You'll definitely learn something. And when you do track down the answer, you document it. The documentation step is non-negotiable. This is what separates a private hunt from a team asset. If you figure out how something works and keep it in your head, you've helped yourself once. If you write it up and put it somewhere the team can find it, you've permanently reduced the number of future hunts your team has to go on for that question. You turned your investigation into infrastructure. This is why I always pair the hunt with a PR (or at minimum a wiki edit). The effort was already spent. The cost of writing it down is small. The compounding value of having it documented is high. Three months from now when someone else asks, they get the answer immediately. A year from now when you've forgotten, you can look it up yourself. Think about how an actual hunt works. Finding the prey is step one, but it is not the end. You have to field-dress the catch, pack it out, keep it cold, and transport it back in a form the whole party can actually use. If you track something down and leave it where it fell, the hunt was wasted. Context hunting works exactly the same way. The trace you ran through the codebase, the state transition you reconstructed, the conditions you mapped out (that's the catch). The wiki page, the PR, the write-up someone else can read and immediately understand (that's dressing it and bringing it back). Context that lives only in your head is a catch left in the field. The documentation is how you make it distributable. What Gets Better When You Hunt</h2> When teams operate in gathering mode, they develop a kind of learned helplessness around missing context. "We don't really know why it works this way." "That knowledge left when Alex left." (Alex is a placeholder name here, not anyone in particular.) "It's just one of those things." These become explanations that close the loop instead of open it. Hunting mode treats those statements as the start of a hunt, not the end of a conversation. "We don't know why it works this way" means: the answer is in the code, let's go find it. "That knowledge left when Alex left" means: the behavior still exists, and behavior is traceable. "It's just one of those things" means: nobody has hunted for it yet. And increasingly, you don't have to hunt alone. Agents with the right skills (code search, documentation search, semantic analysis) can take on a substantial part of the tracking work. You give an agent a starting point and it ranges through the codebase, traces call chains, surfaces relevant patterns, and brings back candidates for you to evaluate. That's the hunting dog: it covers ground faster than you can on foot. But you're still directing. You decide where to start, what counts as a valid find, and when to call it back. The human role shifts from tracker to hunt director. You guide the search party. You make the judgment calls about what's worth pursuing and what isn't. And you become the essential piece in the places the tools can't reach (the ambiguous, the contextual, the "why does this feel wrong" that no search query surfaces on its own). The agent finds the code. The human knows which code matters, why it belongs in the documentation, and what the team actually needs to understand from it. You can't always hunt everything at once. But when someone asks a question you can't answer, and you know the answer exists somewhere in the system, that's the moment to go hunting rather than shrugging. The question is a signal. The question is where the hunt starts. The difference between a team that accumulates context and a team that perpetually re-investigates the same mysteries often comes down to this: one hunts and documents, the other gathers what's already there and stops at the boundary of what's documented. Context hunting builds the documentation that makes future gathering possible. It's not the opposite of gathering (eventually you'll want to just grab the wiki page). It's what has to happen first, in all the places where the documentation doesn't exist yet. Go find the context. Bring it back. Write it down. That's the whole job. Determined. Driven. Consistent. 2026-05-05T00:00:00+00:00 When Tom Brady was inducted into the Patriots Hall of Fame in 2024, someone asked him (again) how he got to where he got. He'd been answering versions of that question for twenty years. His answer was simple: "To be successful at anything, the truth is you don't have to be special. You just have to be what most people aren't: consistent, determined, and willing to work for it. No shortcuts." </blockquote> Three things. Coming from the 199th pick in the NFL Draft (passed over 198 times), who went on to win seven Super Bowls, it's hard to argue with. The man lived it. But here's what gets lost every time someone repeats that quote: the middle part. Most people walk away with two. Consistent. Determined. The "willing to work for it" part gets dropped somewhere in transmission, as if the working-for-it is so obvious it doesn't need a name. It's not obvious. It's actually the piece that decides whether the other two compound or just spin. Here's why that matters: you can be determined and consistent while going in the wrong direction. Determined means you've decided something is worth pursuing. Consistent means you keep showing up. Neither one asks whether you're pointed the right way. You can be disciplined, reliable, and completely off-course. The energy doesn't tell you where to aim. Only the "willing to work for it" (the driven, owned forward effort) does that. It's the force that connects what you've decided to what you keep doing. Brady said the three parts in this order: consistent, determined, willing to work for it. The Quest Engine reads them in a different order (the order that shows how each part depends on the one before it). Determined (in the sense of having determined) is the starting move: you've done the searching, figured out what's actually worth pursuing, assessed which direction matters. That's the prospective force, clarity before effort. Willing to work for it is the driven piece: you've taken ownership of the goal and you're applying sustained effort without waiting for permission or perfect conditions. Consistent closes the loop: you keep returning, the practice builds, the results compound over time. The Quest Engine</a> names these three forces explicitly. Searching is the determined move (contextual awareness, figuring out which direction is yours). Being Driven is the willing-to-work-for-it move (agency, ownership, strategy directed at the right target). Renewal is the consistent move (systematic return, learning from what the practice produces). Brady named all three; the Quest Engine puts them in sequence so the dependency is clear. A useful parallel comes from Craig W. Reynolds' 1987 SIGGRAPH paper, Flocks, Herds, and Schools: A Distributed Behavioral Model</a>. Reynolds describes three local rules for flocking: collision avoidance, velocity matching, and flock centering. Mapped to Quest Engine terms: collision avoidance starts with Searching (contextual awareness of nearby flockmates and conditions), velocity matching is Being Driven (action after reading position, speed, and environment), and flock centering aligns with Renewal (consistent returning toward coherence with the group). Brady's three-part phrase in transmission loses "willing to work for it" and becomes consistent. Determined. (the start and end of the cycle with nothing connecting them). Add the middle back, reordered to show the flow, and it reads: Determined. Driven. Consistent. That's not just a rephrasing. It's the sequence that prevents determination and consistency from becoming very disciplined motion in the wrong direction. "Determined. Driven. Consistent." maps directly to Search, Drive, Renew in the Quest Engine framework</a>. For the complete framework, see the Quest Engine introduction</a>. The path version of the same triad is in Knowing, Walking, Returning</a>. The mindset version is in Stay Hungry. Stay Foolish.</a> The mythic version is in The Hero's Journey and the Quest Engine</a>. The existential version is in Discovery, Play, Joy</a>. The animated version is in Faith. Guts. Stamina.</a> One territory, several maps. Set. Action. Reload. 2026-05-01T00:00:00+00:00 Almost everyone on the planet knows this cue: Lights. Camera. Action. </blockquote> Say it aloud and people immediately recognize it as a trigger to begin. The phrase has been borrowed by sports coaches, startup founders, motivational speakers, and wedding planners. It signals: we are starting now. The cultural wiring is deep. The underlying sequencing logic is also sound: first establish conditions (lights), then frame the capture (camera), then commit (action). Prepare the conditions, frame the scope, then go. A clear order for a clear purpose. But as a model of how work actually happens, the phrase has a structural problem: it has a beginning and no return. It is a one-way pipeline. Three steps to launch, zero steps to close the loop. If you internalize it as a template for how cycles work, you will unconsciously train yourself to think in pipelines (setting up, acting, and then walking away without carrying anything forward). That is the bug. And it is worth fixing. The Structural Flaws</h2> Three diagnoses, quickly. Lights and Camera are the same move. Both are preparation. Both are Search. Lights establish the conditions you will act inside. Camera frames the scope of what you are capturing. These are not two distinct cognitive steps (they are a single act performed with two instruments). Splitting them into two beats artificially inflates the preparation phase. Collapsing them is honest: establish the conditions you will act inside is one move. Calling it two does not create clarity; it creates the illusion of a richer framework than is actually there. The phrase ends at "Action." There is no review beat. No carry-forward. No loop closure. A three-act phrase that ends at the third act is not a cycle (it is a pipeline with a hard stop). Real work does not end when the take begins. It loops. The take produces data. That data shapes the next take. Without a return beat in the phrase, the phrase trains the mind to think: once I act, I am done. That is the exact failure mode that Renewal prevents</a> in the Quest Engine. Even on a real film set, the work is cyclical. Directors call retakes. They review playback at video village between takes, adjusting camera angles and actor positions based on what the monitor reveals. They watch dailies that night (raw footage from the day's shoot) and the next morning's setup is shaped by what last night's screening exposed. The cycle runs at multiple timescales: within a take, between takes, between scenes, between shooting days. Lights. Camera. Action. describes the ritual to begin, not the system that actually makes the work compound. Set. Action. Reload.</h2> Collapse the two preparation beats into one honest verb. Add the closing beat that was always missing. Beat</th> What it does</th></tr></thead> Set</td> Establish the conditions and frame the scope. Lights, camera, marks, intent (collapsed into one verb). Prepare the conditions you will act inside.</td></tr> Action</td> Commit. Sustained directed force. The take is happening.</td></tr> Reload</td> Close the loop. Carry forward what just happened (refined, integrated, and ready for the next Action).</td></tr> </tbody></table> On a real film set, set is already the umbrella term. You "set the lights," "set the camera," "set the marks," "set the scene." One word, multiple instruments, single intent. It maps cleanly to how Search operates in the Quest Engine (a state meaning the set is ready, and an act meaning setting the stage, simultaneously). A director can yell "Set!" the same way they yell "Action!" For the third beat: a reload carries state forward. You reload with something (new ammunition, new calibration, new context). This is the precise opposite of erasing state. Renewal in the Quest Engine works the same way: the gain is made permanent, then it feeds the next cycle. A reload does not return you to zero; it arms you for what comes next. It also works at any timescale (between takes at video village, between scenes after dailies, between shooting days after a week of footage), and is neutral on positive versus corrective (you reload because the last take was excellent and you want better, or because it was broken and needs to be fixed; same verb, both modes). Film cameras had to be reloaded (magazines were swapped, fresh stock loaded, and shooting resumed), so the metaphor already lives in the film world. The thinking behind other candidates is worth showing briefly. Cut only ends the take; it says stop, not carry forward. Dailies / Reel is accurate to real film practice but too insider-film to generalize outside the domain. Retake works for the immediate redo of the same shot but does not cover end-of-day resets or any loop larger than the single take. Reset is the most tempting because it rhymes with Set, giving the phrase a tight audible loop: Set. Action. Reset. The cadence is excellent. But semantically, reset means return to zero / wipe state (the opposite of what Renewal is supposed to do). Reset erases. Reload arms. Reset might be more in line with what a director would actually say on set ("back to one" is a real call) but Reload generalizes better to other domains because it does not carry the "return to zero" baggage. Phrases Shape Mental Models</h2> The broader point: this is a worked example of how common phrases and common ways of thinking can be transformed into better ways of thinking. Phrases shape cognition. A one-shot phrase trains people to think in one-shot pipelines. A cyclical phrase trains people to think in loops. Replacing Lights. Camera. Action. with Set. Action. Reload. is a small intervention with an outsized effect on the mental model it installs. Most of our inherited cultural phrases were optimized for a different era or a different use case. Lights. Camera. Action. was optimized for the theatrical ritual of signaling a crew to begin a single take. It was never meant to describe how a production compounds over days of shooting. But because the phrase became cultural shorthand, it also became a template (and the template is incomplete). Re-examining inherited language with the question "is this a cycle or a pipeline?" often reveals that the phrase is missing its return. Adding the return (explicitly, in the language) changes how people work. It is not just a linguistic upgrade. It is a structural one. The phrase you repeat is the loop you run. The three beats map directly to the three Quest Engine pillars: Phrase Beat</th> Quest Engine Pillar</th> Layer</th></tr></thead> Set</td> Search: Proactive Curiosity + Challenge Matching</td> Prospective / KNOWING</td></tr> Action</td> Drive: Clear Strategy + Directed Intentionality</td> Actuation / ACTING</td></tr> Reload</td> Renew: Iterative Integration + Update Propagation</td> Retrospective / IMPROVING</td></tr> </tbody></table> Set is the Searching move: prepare the conditions, frame the scope, establish what you will act inside. Knowing the path</a> before walking it. Action is the Driven move: commit to the direction, apply sustained directed force, execute with ownership. Reload is the Renewal move</a>: close the loop, carry forward what just happened, make the gain permanent, feed the next Set. The return that makes the walk matter. You can also add the WHY layer above: Script → Set. Action. Reload. </blockquote> The Script is the objective function (why you are shooting at all). Set, Action, and Reload are the three operational beats that execute inside that purpose. Same structure as the Quest Engine's WHY above its HOW</a>: Script as the purpose layer, the three beats as the cycle it contains. This also mirrors what Timing, Momentum, and Resonance</a> describes about the dynamics layer (Set is where you couple your force to the world's readiness to receive it, Action is where the sustained force is applied, and Reload is where you recalibrate based on what the world returned). Lights. Camera. Action. is one of the most recognized phrases in popular culture. It is punchy, three-beat, and universally understood. It will not be replaced, nor should it be, for the job it was designed for: signaling a film crew that the take is beginning. But as a template for how cycles work (as a mental model for how effort compounds) it is missing its third beat. It is a pipeline wearing the costume of a cycle. Set. Action. Reload. adds back what was always there in practice and never in the phrase. The phrases we repeat shape the cycles we run. Reframing one of the most iconic phrases in popular culture from a pipeline into a loop is a small example of a much larger move: taking inherited language seriously enough to upgrade it. Every phrase that ends at the action and drops the return is training the mind in the wrong direction. Adding the return (naming it, making it explicit) is how the cycle compounds instead of restarts. Sources and related: Quest Engine: A Framework for Agent-Human Collaboration</a>: the three-pillar framework (Search, Drive, Renew) that Set / Action / Reload maps onto</li> Quest Engine: The Why Behind the How</a>: the WHY layer (Searching, Driven, Renewal as intrinsic forces) that sits above the operational cycle; where Script lives</li> Knowing, Walking, Returning</a>: the path triad (Knowing = Searching, Walking = Driven, Returning = Renewal) that the Set / Action / Reload cycle structurally parallels</li> Quest Engine: Timing, Momentum, and Resonance</a>: the dynamics layer on sustained force and coupling, directly relevant to the Action beat</li> Stay Hungry. Stay Foolish.</a>: on inherited phrases that outlast their original context and the mindset of permanent pursuit</li> </ul> The Hero's Journey and the Quest Engine 2026-04-29T00:00:00+00:00 Joseph Campbell spent decades studying myths across every culture he could reach and kept noticing the same shape inside all of them. An ordinary world. A gap that opens. A crossing into the unknown. Trials that test the hero. An abyss where the old self is consumed. And finally a return, carrying something new back to the world that was left behind. He called it the monomyth. He wasn't claiming every story is the same story. He was claiming that all transformation stories trace the same loop because that loop mirrors something true about how change actually works. The Quest Engine</a> names that loop: Searching, Driven, Renewal. The knowing-walking-returning post</a> names it in path terms: knowing the path, walking it, returning from it. The secular meaning post</a> names it in existential terms: Discovery, Play, Joy. The stay-hungry post</a> names it as mindset: hungry and curious, foolish, happy. What the hero's journey adds is the oldest available framing of that loop (the version that survived thousands of years because it names something true about transformation at the level of story rather than framework or philosophy). One territory, mapped many times. Searching: Knowing What the Call Is About</h2> The hero's journey begins with an ordinary world and a disruption. Something feels insufficient. A gap opens between where the hero is and where they sense they could be. Campbell calls this the Call to Adventure (the moment of noticing, before the threshold is crossed, when the world the hero inhabits starts to feel like not all the world there is). That noticing is Searching. The Quest Engine introduction</a> describes Searching as the force that operates before you act: scanning the terrain, pulling on threads, building understanding before committing to direction. The knowing-walking-returning post</a> gives this a precise name: knowing the path is forward-looking, oriented toward the territory before you move through it. The strategist who maps contingencies before acting, the developer who reads the codebase before touching it, are all Searching. The why post</a> frames the governing question at this phase: "What does better look like?" The Call to Adventure is that question arriving as a feeling before it becomes a plan. The hero doesn't yet know what the journey will produce. They only know the gap is real and that something beyond the ordinary world is worth finding. That pull toward the edge of what you understand, toward what you don't yet know, is what the secular meaning post</a> calls Discovery, and what the stay-hungry post</a> calls being hungry and curious working together. The timing and momentum post</a> extends this: Searching is timing, which means recognizing the window the world opens rather than forcing the moment. You can't create the window, but you can miss it by not searching. The refusal of the call is what happens when Searching stops. The gap is visible but you turn away. Comfort becomes the ceiling. You execute on what you already know instead of searching for what you don't. The stay-hungry post</a> names this as the expert's trap: learning enough to be comfortable, letting comfort become the horizon. The why post</a> names the consequence directly: missing Searching produces stagnation. The world grows smaller not because there's nothing left to find, but because you've stopped looking. The hero who refuses the call has everything they need to begin. What they lack is the willingness to let the search change them. Driven: Walking the Path Under Your Own Power</h2> Once the hero crosses the threshold, the structure shifts. The Initiation phase is not about gathering more information. It is about acting inside uncertainty: owning decisions, facing trials, committing to the path even without a complete map. The trials exist not to block the hero but to test and build the very capacities the journey requires. The abyss is not a punishment. It is the place where the self that belonged to the ordinary world has to dissolve for the new one to emerge. This is being Driven. The knowing-walking-returning post</a> names something important about the nature of walking: walking is taking. When you walk a path, you receive from it. You accumulate experience, perspective, and friction that only motion through the unknown can provide. Being Driven isn't force of will alone (it is the capacity to draw from the territory you're moving through, to let the trials compound rather than diminish you). The why post</a> frames the governing question: "What can I control?" The hero in the Initiation phase is not asking whether to act. They are asking what within this unknown world is theirs to shape. The high-agency teams post</a> maps this to Judgment: the capacity to identify what you own versus what you delegate, to exercise control within clear boundaries rather than waiting for permission or thrashing without direction. Judgment can't be developed without the trials. The trials exist precisely to build it. The timing and momentum post</a> names the physics here: momentum is mass times velocity, and it is the force you control. Mass is accumulated capability built by searching. Velocity is deployment frequency maintained by being driven. Talent is the mass. Momentum is what you do with it. The allies and supernatural helpers Campbell describes in this phase are not decorations. In the mythic vocabulary, the hero rarely succeeds alone. Mentors appear. Magical tools are given. Companions take on parts of the journey the hero can't carry alone. In engineering and knowledge work, AI coding agents fit naturally here (they multiply what you can attempt in the Initiation phase, extend reach into territory that would take far longer to cover alone, handle the mechanical so that decision-making capacity expands). The hero still owns the decisions. The agents are allies, not replacements. Being Driven means knowing what to delegate and what to hold. The shadow failure of Initiation is learned helplessness. When every decision meets friction, when judgment is overridden, when action doesn't compound into results, the hero stops trying. They drift through the special world, compliant rather than driven. The why post</a> diagnoses this precisely: missing Driven produces learned helplessness. The trials aren't the problem. Losing the sense that the trials can be acted on is the problem. Renewal: Returning with What the Walk Taught You</h2> The hero's journey doesn't end at the abyss. It ends with the Return. Campbell considered this the most neglected and most difficult phase: the hero carries the boon back across the threshold and integrates it into the ordinary world. Not just surviving the special world, but bringing the transformation home in a form that can be given to others. The knowing-walking-returning post</a> names the structural logic exactly: returning is giving. Walking was taking (you accumulated what the journey contained). Returning is the moment you offer it to others: the map corrected by experience, the shortcuts found, the dead ends walked so others don't have to. Steve Jobs, reflecting at Stanford on dropping out and auditing calligraphy and eventually building the Macintosh, said: "You can't connect the dots looking forward; you can only connect them looking backward." The return is when the dots connect. The walk creates them. The return makes them legible (to yourself and to everyone you can now show the way). This is Renewal. The Quest Engine introduction</a> calls it the force that turns experience into permanent gains: comparing what happened against what you expected, extracting the root pattern, making the improvement permanent, propagating it. The why post</a> frames the governing question: "Am I still aligned with what matters?" The hero crossing the return threshold is asking exactly that. Does the ordinary world still make sense in light of what the journey revealed? Has the purpose that launched the Departure survived contact with the Initiation? Renewal is the honest accounting. The timing and momentum post</a> extends this as resonance: renewal is where you verify the coupling between your effort and the world's readiness to receive it. Did the momentum produce the expected result? If not, which term was missing? The secular meaning post</a> maps this to Joy: the recognition, looking back, that what you've been doing connects to what matters. Not happiness, which is transient. Joy is the verification that the effort pointed toward something real. The stay-hungry post</a> calls it staying happy: the ongoing choice to see the path as its own reward, to find energy in the return rather than anxiety about how far you still have to go. The high-agency teams post</a> names Taste as the human capacity that emerges here: pattern recognition about what's worth doing, built by comparing what you expected with what actually happened. Taste can't be developed inside the Initiation alone. It requires the return. The failure of Renewal is staying in the special world. The boon exists but goes nowhere. The transformation happened but isn't given back. The why post</a> names the consequence: missing Renewal produces burnout. Not because too much happened, but because the connection between effort and meaning severs without the return to verify it. The engineer who never surfaces from execution loses the thread back to why the execution was launched. Here is what the path metaphor clarifies that the hero metaphor can obscure: the return is not geographic. The ordinary world the hero comes back to is not the ordinary world they left. They have changed. The return is not going backward (it is completing the loop so the next cycle can begin from a higher position). The leverage post</a> names this as each iteration leaving a stair behind: every Searching-Driven-Renewal cycle produces not just outputs but structure, a new platform to stand on, a new ordinary world with a new and more complex gap to notice. The Quest Engine loop is a spiral. The return is also a new departure. The Map That Maps Itself</h2> What makes the hero's journey durable across thousands of years and every culture Campbell examined is that it is a meta-story: a story about how all transformation stories work. Every culture tells it not because they borrowed it from each other but because they were all observing the same thing. The knowing-walking-returning post</a> gives the path version: Knowing is Searching, Walking is Driven, Returning is Renewal, and the whole triad lives in a single phrase from The Matrix that has outlasted most of the film surrounding it. The secular meaning post</a> gives the existential version: Discovery, Play, Joy as the three modes of being fully alive. The stay-hungry post</a> gives the mindset version: four words from the back cover of the Whole Earth Catalog that Steve Jobs kept returning to because they named something he couldn't find a better name for. These are not parallel metaphors. They are the same observation, made from different vantage points, arriving at the same triad because the triad is how transformation works. The Quest Engine</a> names the operational form: Searching (what does better look like?), Driven (what can I control?), Renewal (am I still aligned with what matters?). The hero's journey is the narrative form of those three questions asked across the arc of a life. The diagnostic holds across all the framings. Refusal of the call is missing Searching (the gap is visible, the pull is real, and you turn away from it). Learned helplessness in the abyss is missing the Driven force (the trials are happening but the sense of ownership is gone). Staying in the special world is missing Renewal (the transformation happened but the return never came, and with it the ability to give the boon away). The why post</a> makes this explicit: you can usually tell which force is missing before motivation collapses entirely, if you ask the right question. Which phase of the journey have I stopped completing? The answer points to the next move. And the next move is always available, because the journey is recursive at every scale. Every quest contains smaller quests. Every trial within the Initiation is its own miniature Searching-Driven-Renewal cycle. A single code review follows the same pattern as an entire career arc. This is why the Quest Engine introduction</a> describes the structure as self-similar: it repeats at every scale because the underlying dynamics are the same at every scale. The hero who crosses back with the boon finds a new ordinary world with a new gap and a new call. Searching begins again, richer for what the last cycle taught. The loop doesn't end. It compounds. The Hero's Journey maps the narrative shape of transformation. The Quest Engine names the loop that produces it. For the complete framework, see the Quest Engine introduction</a> and The Why Behind the How</a>. The path metaphor lives in Knowing, Walking, Returning</a>. The existential frame is in Discovery, Play, Joy</a>. The mindset is in Stay Hungry. Stay Foolish.</a> One territory, several maps. Knowing, Walking, Returning: Completing the Path Triad 2026-04-29T00:00:00+00:00 In 1999, the Wachowskis wrote a line that has outlasted most of what surrounded it. Near the midpoint of The Matrix, Morpheus takes Neo into a dojo simulation and says: "There is a difference between knowing the path and walking the path." </blockquote> No explanation. No follow-up lecture. Just the sentence, and then they fight. Morpheus has been teaching Neo that the rules of the Matrix (gravity, physics, the limits of a human body) are not laws but beliefs. And his point is that understanding this intellectually is not the same as living it. Neo knows he could dodge a punch. Walking the path means actually moving when the punch comes. The line has stayed with people because it names something real about the gap between comprehension and action. But it's still only half the picture. Knowing and walking are two forces in a cycle that has three. The missing third is returning (and that's where renewal lives). What Knowing and Walking Actually Are</h2> Knowing the path is the Searching move. It's the phase of active discovery: reading the map, understanding the terrain, identifying what you don't yet understand and deliberately going after it. Knowing is prospective. You're building a model before you act on it. A strategist who maps every contingency before moving is living in knowing. A developer who reads the codebase before touching it, an engineer who diagrams the system before building it, a planner who simulates outcomes before committing — all of these are searching for the path. Walking the path is the Driven move. It's the phase of ownership and action: committing to the direction you've chosen, propelled by the autonomy to make decisions that compound. Walking is where the knowing gets tested against reality. You stop modeling and start moving. Being driven doesn't mean being reckless (it means being propelled by the ability to shape outcomes). You've decided this is the path, and you're taking it (and that word, taking, is more precise than it first appears). Morpheus is pointing at the gap between these two forces because Neo is stuck in knowing. He understands the rules, he can describe why the jump is possible, he can see the path intellectually, but he hesitates when the moment comes. The problem isn't that he doesn't know enough. The problem is he hasn't made the transition from model to motion. That gap is real. But Morpheus was only pointing at the first transition: from knowing to walking. There's a second one the line doesn't address, and it's the one most people miss. The Third Move: Returning</h2> After you've walked the path, you return. Not back to where you started (you can never do that, because you've changed), but to the work of asking: Was that the right path? What has the walking taught me that the knowing never could? Steve Jobs, in his 2005 Stanford commencement address</a>, said something that only makes sense from the vantage point of return: "You can't connect the dots looking forward; you can only connect them looking backward." He was talking about dropping out of Reed College, which led him to audit calligraphy, which became the beautiful typography of the Macintosh. He couldn't have known the dots would connect while he was walking that path. He could only see the pattern after the return, and only then could he give the insight away to an audience of graduates. During the walk, you accumulate dots. During the return, they become a line. The oldest version of this is the parable of the prodigal son. The son knew about his home (knowing). He walked away (taking his inheritance, his freedom, accumulating experience that staying could never have given him). The lessons didn't arrive while he was eating husks in a distant country. They arrived in the act of returning: seeing his father run toward him, feeling the full distance between what he'd had and what he'd squandered, understanding the value of what he left only by having left it. He couldn't have shown anyone else the way home without having walked away and come back. The walk made him experienced. The return made that experience legible (to himself and to everyone who has told the story since). Here is the axis this reveals. Walking is taking. When you walk a path, you receive from it: experience, distance, knowledge, perspective accumulated in motion. You draw from the territory, from the people you meet, from the friction the path provides. Taking is how you accumulate what you'll later need. But it's not the full cycle. Returning is giving. When you come back, you bring what the walk taught you and offer it to others: the map corrected by experience, the shortcuts found, the dead ends walked so others don't have to. The only way you can show someone else the way is if you have walked it and returned. There is a proverb that says it is better to give than to receive. That proverb carries a structural implication that gets missed without this frame: giving is only possible after you have received enough to give. The walk is the receiving. The return is the giving. Renewal, understood this way, is the act of becoming a source rather than a destination. The Triad in Full</h2> The complete path triad is: Knowing is Searching. You research the terrain, discover what you don't yet understand, and build the model. The path exists in your mind as a direction worth taking. You're searching for what matters most before you move. Walking is Driving. You commit to the direction and move under your own propulsion. You're driven by ownership over decisions that compound. The path leaves knowing behind and becomes motion (you are taking from it, absorbing what the journey contains, accumulating the dots that will later connect). Returning is Renewal. You come back from the walk changed, carrying what the walk taught you. The dots connect. The pattern emerges that couldn't be seen from inside the path. You verify whether you were walking toward the right thing, and then you give it away. Renewal is the honest accounting of the walk against the intention, and the moment the walk becomes generative rather than personal. This triad is exactly the cycle in the Quest Engine framework</a>: Searching, Driven, Renewal. The path metaphor makes the structure concrete because paths are physical (you either know them or you don't, you either walk them or you don't, you either return from them or you keep walking indefinitely). The same cycle operates at the level of purpose: not just a path through a city, but the path toward what you're building, the direction your work is compounding, the destination you've decided is worth reaching. Morpheus was right that there is a difference between knowing the path and walking the path. The sentence was always incomplete. You search for the path, you walk it and take from it, you return and give back what it taught you. The motion is the meaning. The return is what makes the motion matter to anyone but yourself. The Matrix quote originates from the Wachowskis' 1999 film (spoken by Morpheus, played by Laurence Fishburne, to Neo, played by Keanu Reeves). The prodigal son parable is from Luke 15:11-32. The "connecting the dots" reflection is from Steve Jobs' 2005 Stanford commencement address</a>, explored in full in Stay Hungry. Stay Foolish.</a>. The proverb "it is better to give than to receive" is from Acts 20:35. The path triad (Knowing = Searching, Walking = Driven, Returning = Renewal) connects to the Quest Engine framework</a> and its WHY layer</a>. See also the secular framing of the same cycle in Discovery, Play, Joy</a>. Quest Engine: Timing, Momentum, and Resonance 2026-04-28T00:00:00+00:00 "Timing and momentum is more important than talent." — André 3000 </blockquote> This phrase privileges when (Timing) and sustained directional force (Momentum) over raw capability (Talent). The Quest Engine framework</a> already has a strong account of talent and capability through Mastery, Challenge Matching, and Flow. What it lacks is the third term the quote leaves implicit. The Three-Term Model</h2> The quote is incomplete because Timing plus Momentum without a coupling mechanism still bounces off the world. You can apply force at exactly the right moment, but if the system you're pushing on isn't tuned to receive it, the energy dissipates. Here's the extension: Timing · Momentum · Resonance Timing (the window the world opens; you don't set the clock)</li> Momentum (the sustained directed force you bring; you control this)</li> Resonance (the coupling between your force and the people who must receive it; you can only influence this, it is fundamentally relational)</li> </ul> Resonance is the new contribution. It's the only one that requires another oscillator (a person, team, audience, or organization) to exist at all. Timing and Momentum can be measured on you alone. Resonance cannot. The triad spans the full locus-of-control axis: Quest Engine Pillar</th> Physics Term</th> Locus of Control</th></tr></thead> Search (Prospective / KNOWING)</td> Timing</td> Accept</td></tr> Drive (Actuation / ACTING)</td> Momentum</td> Control</td></tr> Renew (Retrospective / IMPROVING)</td> Resonance</td> Influence</td></tr> </tbody></table> Timing maps to Search because you don't control when the window opens (when the market shifts, when your manager gets budget, when the team acknowledges the problem). What you control is whether you've done the searching to recognize the window when it arrives. Momentum maps to Drive because it's mass times velocity, and you control both. Mass is your accumulated capability. Velocity is your deployment frequency. Talent is the mass. Momentum is mass times velocity. Resonance maps to Renew because coupling is relational and requires continuous calibration. You influence resonance by tuning your frequency to match your audience, or by choosing a different audience. But you can't force it. The Physics</h2> Timing is recognizing that the world opens and closes windows independent of your readiness. The failure mode is waiting for perfect timing (deferring until conditions are perfect). The opposite failure is ignoring timing entirely (shipping too early or too late). You can't create the window, but you can miss it by not searching. Momentum is mass times velocity. You build mass through Deliberate Practice</a> (not just repetition, but focused improvement). You increase velocity through tight feedback loops and removing friction. The failure mode is confusing motion with momentum (staying busy but finishing nothing). Sustainable momentum means increasing velocity without decreasing mass (shipping faster while maintaining capability). Resonance is the coupling between your sustained force and the people who must receive it. You can have perfect timing and enormous momentum, but if you're pushing on a system tuned to a different frequency, the energy dissipates. The failure mode is forced driving (pushing harder when the system isn't tuned to receive it). The opposite failure is resonance shopping (only engaging with audiences already tuned to your frequency). How Resonance Works</h2> The interaction model is multiplicative: Timing · Momentum · Resonance → Lasting Benefit. If any term goes to zero, the product goes to zero. High resonance means small force, large outcome. Low resonance means large force, small outcome. Off-resonance means force creates resistance. You can see this in the observable signals. When your proposals get built on (not just approved, but extended by others), when people seek you out when the topic comes up, when the system amplifies your input because it's tuned to receive it (that's resonant coupling). When you're working harder but results are diminishing, when you repeat the same points in different ways but understanding doesn't improve, when you feel like you're pushing against a wall (that's off-resonance driving). The difference isn't effort. The difference is coupling. Sometimes your input is acknowledged but not acted on. The team nods, says "good point," then continues as before. The system is absorbing your energy without changing state (that's damping). Sometimes you and your audience agree on the goal but you're out of sync on timing. Six months later, they come back asking for exactly what you proposed. The frequency was right. The phase was wrong (that's phase mismatch). Watch a World Cup game and you'll see the same physics on the pitch: a star player</a> reading the window (timing), driving the run and the finish (momentum), and threading a pass that a teammate is actually positioned to receive (resonance). A beautiful pass with no one there to receive it is textbook off-resonance (perfect force, zero coupling), and the through-ball that arrives a beat before the runner is pure phase mismatch. The meta-pattern: resonance is about energy transfer, not energy application. You can apply enormous force, but if it doesn't couple, it doesn't matter. This is why the Quest Engine</a> emphasizes renewal</a> so heavily. Renewal is where you verify the coupling. Did the effort produce the expected result? If not, which term was missing? Was it timing (the window wasn't actually open)? Was it momentum (you didn't have enough sustained force)? Or was it resonance (the system wasn't tuned to receive what you were broadcasting)? The diagnosis determines the fix. Timing extends Search (you're searching not just for what's true, but for when the world will be ready to act on it). Momentum extends Drive (you're building mass through deliberate practice and increasing velocity through tight feedback loops). Resonance extends Renew (you're verifying the coupling between your force and the system's readiness to receive it). This isn't a replacement for the Quest Engine. It's an additive v4.1 extension (a dynamics layer that sits alongside the existing kinematics and control layers). The One-Line Summary</h2> Talent is the mass. Momentum is mass times velocity. Timing is when you apply the force. Resonance is whether the system you're pushing on is tuned to receive it (and without it, the other three don't matter). All three working together (that's how effort converts to lasting benefit). Timing, Momentum, and Resonance extend the Quest Engine framework</a> with a dynamics layer, originating from André 3000's observation</a> on timing and momentum. For a concrete, non-physics illustration of the same triad, see how a star player converts chances at World Cup 2026</a>. The framework connects to the Objective Function</a> through the locus-of-control axis (accept, control, influence) and integrates with existing Quest Engine pillars on Search, Drive, and Renew</a>. The physics terminology serves engineering and career behavior, not physics for its own sake. Leverage and the Stairs You Build 2026-04-26T00:00:00+00:00 "Give me a lever long enough and a fulcrum on which to place it, and I shall move the world." — Archimedes </blockquote> Archimedes wasn't bragging about strength. He was making a claim about leverage: that the right tool, placed at the right point, multiplies what a single person can do. Engineering is the discipline of building those levers (and then sharpening them every day). Steve Jobs said the computer was a "bicycle for the mind" because a human on a bicycle is the most efficient creature on earth. The bicycle isn't faster than a human; it's a structure that converts the same effort into more distance. That's leverage. This is the same insight behind the Quest Engine</a>: you don't get better by working harder against the wall. You get better by building the staircase. The Wall, the Stairs, and the Scaffold</h2> Picture a vertical wall. You want to be on top of it. You can: Climb the wall. Painful, slow, mostly impossible without specialized strength you don't yet have.</li> Build stairs against the wall. Boring at first. Eventually trivial.</li> </ol> Most people pick option 1, because option 2 looks like "not making progress." But the climber who never builds stairs hits the same wall every time. The builder eventually walks up without effort, and so does everyone who comes after. The catch is that the stairs have to be the right size. Stairs that are too tall are just smaller versions of the wall: you stall on every step. Stairs that are too short waste your time and never get you anywhere. The whole craft is in sizing the step so that today's effort lands you on a platform you can rest on, and tomorrow's effort starts from there. This is exactly what Math Academy</a> does well: it doesn't ask you to climb. It scaffolds. Every problem sits one rung above what you already know. You don't notice you're learning calculus; you just keep stepping. The system is doing the search for the right next step so you can spend your attention on the step itself. There is a subtler version of this idea: sometimes the scaffolding is more intricate than the thing it supports. Consider the false arch used to build a true arch. The temporary wooden form is more complex than the stone ring it holds in place (but without it, no arch exists). Once the keystone drops, the form is removed. The scaffold served its purpose and disappeared, but it had to be exactly right. Or think of creating a work of art. A painter may spend more time on primer layers, under-drawings, grid lines, and reference studies than on the final visible surface. A sculptor's armature (the steel skeleton that holds wet clay during shaping) is often a feat of engineering that no audience will ever see. The scaffold serves the work; the work does not serve the scaffold. Yet the more ambitious the work, the more intricate the scaffold must be. Scaffold engineering is the discipline of building structures that enable the real work, even when those structures are harder to build than the work itself. The scaffolding is temporary, or invisible at the end, but it is not trivial. This is why onboarding docs, test harnesses, CI pipelines, local dev environments, and good abstractions are worth their cost even though none of them is "the product." They are the scaffold that makes the product possible (and the more complex the product you're aiming for, the more carefully you must engineer your scaffold). When you feel like you're "not making progress" because you're writing tests instead of features or documenting before building (you are the sculptor building the armature), don't skip it. Daily Practice, Disclosure, and Iteration</h2> A long lever is useless if you only pick it up once a quarter. The reason daily practice works is that it's the only schedule on which the lever stays in your hand. Skills are mostly retrieval pathways. Pathways that aren't walked get overgrown. Daily practice does three things at once: It sizes the step automatically. A day's worth of effort is small enough that you can't take on a step that's too tall.</li> It makes feedback tight. You see yesterday's mistake before it ossifies.</li> It compounds. Twenty minutes a day for a year is a hundred and twenty hours of deliberate practice on the same skill. Most "talent" is just somebody who showed up daily for a few years.</li> </ul> All three depend on the same underlying insight: time is itself a lever. A problem that is impossible in a day becomes tractable over a month, and routine over a year. Extending the timeline is not procrastinating (it is finding the right fulcrum). When a task feels impossibly hard, the first question is often not "how do I get stronger?" but "how do I give this more time?" You don't always need a bigger effort; sometimes you need a longer arm on the lever. This is the Driven force from the WHY behind the Quest Engine</a>: the daily commitment to act on what you control. You don't need a breakthrough. You need consistency (a streak is just consistency made visible). The payoff for sizing steps correctly isn't just progress. It's flow. Csikszentmihalyi's research on optimal experience shows that people enter flow when the challenge sits just above their current skill (not so easy it's boring, not so hard it's paralyzing). The correctly sized stair is exactly this. Daily practice on the right-sized step is the engineering of flow: you manufacture the conditions for effortlessness by showing up at the edge of your ability, day after day. Habit science adds another layer. A habit is a scaffold that eventually becomes invisible. When you first learn to drive, every action is deliberate (hands, mirrors, pedal, signal). After years, you drive while thinking about something else entirely. The scaffold was internalized; it became load-bearing structure. The goal of daily practice is not to practice forever; it's to practice until the skill is structural (until it runs without effort, freeing your attention for the next step up). The same geometry shows up in information design as progressive disclosure</a>: reveal complexity only when the learner or user is ready for it. Don't show every setting on the first screen. Don't introduce exceptions before the rule. Don't hand someone the full map before they know how to walk. A well-designed tutorial starts with the simplest working example (just enough to get something running) and defers edge cases, advanced options, and error handling until the learner has internalized the foundation. A good CLI tool has sensible defaults that hide every option you don't need right now, with a --help</code> flag that reveals more only when you ask. Each of these is a correctly sized step. The complexity didn't disappear (it was deferred to the stair where it belongs). This is why good documentation starts with a Quick Start, moves to a Concepts guide, and only then dives into a full Reference. The Quick Start is not a summary of the Reference; it is the first stair. Skipping it doesn't save time (it removes the step and replaces it with a wall). Progressive disclosure also shapes how you write error messages: a useful error shows you the next action, not just the failure. A system that says "something went wrong" is a wall. A system that says "the config file is missing (run init</code> to create one)" has built you a stair. Design for the step, not the stop. Iterative development is the same idea at code scale. The reason short cycles beat waterfall isn't ideology; it's leverage. A short cycle limits the size of the next step, gives you feedback before the step ossifies, and lets the next cycle start from real ground instead of imagined ground. The unit changes; the geometry doesn't. Every loop should leave a stair behind it: a test that didn't exist before, a doc that wasn't written, a mental model that's now shared. This is the Renewing move (Iterative Integration → Deliberate Practice → Update Propagation) made physical. If your iterations don't leave stairs behind, you're not iterating (you're climbing the same wall, faster). Forward Progress: There Is Always a Next Move</h2> In any well-designed system, there is always at least one valid action available. This is the principle of forward progress: no matter how complicated the rules, no matter how many things are blocked or uncertain, the system (and the people operating it) should never be left with nowhere to go. This matters most in asynchronous systems, where work is not sequential and participants are not all present at the same time. A message queue guarantees forward progress by ensuring a producer can always deposit work and a consumer can always pick it up, even if they never run simultaneously. A retry policy guarantees forward progress by ensuring a failed step does not permanently halt the pipeline. The saga pattern guarantees forward progress by ensuring every step either succeeds or has a compensating action (you can always return to a consistent state). The same principle applies to teams and individuals. A blocked task is not a stopped task if you can take the next smallest available action: Write down what you know so far.</li> Ask the specific question that unblocks you.</li> Break the problem into the part you can move on right now.</li> Document the blocker so the next person doesn't hit the same wall.</li> </ul> The Quest Engine's Searching move is exactly this: when the direct path is blocked, find the adjacent step that isn't. The stair doesn't have to go straight up. It just has to go forward. Designing for forward progress is designing for resilience. A system (or a person) that can always find the next step does not get permanently stuck. It may slow down. It may zigzag. But it keeps moving. And a system that keeps moving eventually arrives. The Lever, the Bicycle, and the Stair</h2> A tool is a stair somebody else built and left behind for you. The compiler is a stair. The test runner is a stair. Git is a staircase made of tens of thousands of stairs. An AI coding agent</a> is a freshly poured stair whose exact shape we're still figuring out. The Quest Engine move is to search for the tool whose step size matches where you actually are. A tool that's too powerful for your current context is a wall pretending to be a stair (you'll get stuck on it). A tool that's too weak is a stair you've already outgrown. Choose tools the same way Math Academy chooses problems: one rung above where you stand. Three metaphors, one idea: Archimedes' lever: the right structure converts small effort into large motion.</li> Jobs' bicycle: the right structure converts the same effort into more distance.</li> The staircase: the right structure converts an impossible climb into a sequence of easy steps.</li> Time: a longer runway converts an impossible deadline into a series of achievable steps.</li> </ul> Engineering, learning, and collaboration are all the same job under different names: find the wall, size the next stair, take the step, leave the stair behind for the next person (including future you). That's why daily practice works. That's why progressive disclosure works. That's why forward progress matters. That's why iterative development works. That's why scaffolded learning works. That's why tools work. That's why patience works. They're all the same lever, applied at different scales. Give yourself a long enough lever (and a daily habit of pulling on it) and you really can move the world. Or at least the next step of it. This post connects the leverage metaphor to the Quest Engine framework</a> and its WHY</a>: Searching for the right next step, being Driven by daily action, and Renewing through iteration so each cycle leaves a stair behind. Discovery, Play, Joy — A Secular Meaning of Life 2026-04-26T00:00:00+00:00 If you strip away religious frameworks, metaphysical claims, and appeals to cosmic significance, what's left? Not nihilism. Not despair. Something much simpler: Discovery, Play, Joy. Three forces that don't require belief in anything beyond the observable world. Three states that make life worth living not because they point toward some external purpose, but because they are the experience of being alive at full capacity. This isn't to say that people don't feel the need for religious meaning or something beyond a scientific approach. Many do (I'm religious myself). That's a whole different topic. This is simply exploring what remains when you look at meaning through a purely secular lens. Most discussions of life's meaning assume you need to find it (as if it's hidden somewhere waiting to be discovered) or create it (as if you need to impose significance on an indifferent universe). Both framings miss the point. Meaning isn't found or created. It's experienced. It emerges when you're fully engaged with being alive. And that engagement has three distinct modes: discovering what you don't yet understand, playing with what you can shape, and finding joy in the renewal of both. This isn't poetry. It's diagnostic. When life feels hollow, empty, or meaningless, it's because one of these three forces is missing. Not because the universe lacks meaning (it never had any to begin with), but because you've stopped engaging in ways that generate the experience of meaning. The question isn't "what's the meaning of life?" The question is: which force have you stopped accessing? Discovery: The Search for Understanding</h2> Discovery is the active state of searching for what you don't yet understand. Not passive curiosity. Not casual interest. The pull toward the edge of what you know, the drive to see what's just beyond the boundary of comprehension. Discovery is what happens when you encounter something that doesn't fit your current model of how things work, and instead of ignoring the gap, you lean into it. To chart the uncharted. A child discovers why the sky is blue. An engineer discovers why the system fails under specific conditions. A philosopher discovers whether consciousness is substrate-independent. The content changes, but the structure is identical: there's a gap between what is and what you understand, and you're pulled toward closing that gap. Discovery is the intrinsic motivation to search. Most people stop discovering. They encounter the unfamiliar and either dismiss it (not relevant to me), defer it (someone else will figure that out), or ignore it (too complicated to think about). The gap remains, but the pull disappears. They've stopped searching. And when you stop searching, the world becomes smaller. Not because the world changed, but because you stopped expanding your model of it. Here's what makes discovery secular: it doesn't require anything beyond observable reality. You don't need to believe the universe has purpose to discover how galaxies form. You don't need metaphysical claims to discover how neural networks generate coherent text. The universe doesn't care whether you understand it, but the act of trying to understand generates the subjective experience of meaning. Discovery is self-justifying. The search is the point. When discovery stops, life becomes repetitive. You're executing on what you already know instead of exploring what you don't. The job becomes mechanical. Not because there's nothing left to learn, but because you've stopped looking. Discovery is the force that keeps the world feeling infinite. Play: The Drive to Engage</h2> Play is the active state of engaging with what you can shape. Not work (which implies obligation). Not leisure (which implies escape). Play is what happens when you have autonomy over decisions that matter and you're propelled by the ownership of shaping outcomes. You're not following instructions. You're not waiting for permission. You're acting within a space where your choices compound. A musician plays with melody. A programmer plays with abstractions. A designer plays with constraints. The domain changes, but the structure is identical: there's a space where you have control, and you're driven to exercise that control in ways that generate interesting results. Play is the intrinsic motivation to act. Most people stop playing. They encounter systems where decisions don't stick (bureaucracy), where outcomes are predetermined (scripted work), or where autonomy is an illusion (performative choice). They learn that action doesn't lead to meaningful change, so they stop trying. They've stopped being driven. And when you stop being driven, life becomes passive. Not because there's nothing you can control, but because you've learned that exercising control doesn't matter. Here's what makes play secular: it doesn't require belief in destiny, fate, or cosmic justice. You don't need the universe to care about your actions for those actions to generate the experience of agency. A game of chess matters because the players care, not because the universe does. Software you build matters because it shapes outcomes you value, not because it contributes to some grand narrative. Play is self-contained. The engagement is the point. When play stops, life becomes reactive. You're responding to what happens instead of shaping what could happen. The job becomes something you endure. The day becomes something that happens to you. Not because there's no space for agency, but because you've stopped claiming it. Play is the force that keeps life feeling like it's yours. Joy: The Renewal of Purpose</h2> Joy is the active state of renewing connection to what matters. Not happiness (which is transient). Not pleasure (which is sensation). Joy is what happens when you pause, reflect, and verify that what you're doing still aligns with what you care about. It's the ongoing process of checking whether the path you're on is still the path worth walking. A scientist feels joy when an experiment reveals something unexpected. A teacher feels joy when a student finally understands. A builder feels joy when something they made continues to work years later. The trigger changes, but the structure is identical: there's a moment where you see that what you've been doing connects to something that matters, and that connection renews the sense that the effort was worth it. Joy is the intrinsic motivation to align with purpose. Most people stop renewing. They keep executing on yesterday's goals while context shifts. The project that started with clear purpose erodes into vague obligation. The work that once felt meaningful becomes mechanical. They're still competent, still productive, still busy. But the connection between effort and meaning has severed. They've stopped renewing. And when you stop renewing, life becomes hollow. Not because there's nothing worth doing, but because you've lost track of why you're doing it. Here's what makes joy secular: it doesn't require belief in an afterlife, karma, or ultimate justice. You don't need the universe to remember your contributions for those contributions to feel meaningful in the moment. Joy is the experience of seeing that what you did mattered to someone (including yourself), and that's enough. It's retrospective meaning. The renewal is the point. When joy stops, life becomes a grind. You're executing without knowing why. The routine continues, but the purpose has drifted. The work gets done, but it doesn't feel like it matters. Not because there's no meaning available, but because you've stopped verifying that what you're doing still connects to it. Joy is the force that keeps life feeling worthwhile. Together, Discovery, Play, and Joy form a system. Each one amplifies the others. When all three are present, life feels full. When one is missing, the system degrades predictably: Discovery without Play or Joy: You're endlessly researching but never acting. You understand more and more about less and less, but nothing compounds. The search becomes academic, detached from shaping anything. Play without Discovery or Joy: You're executing on what you already know without expanding or verifying. The work becomes mechanical. You're driven, but toward nothing in particular. Joy without Discovery or Play: You're renewing connection to old purposes without searching for new ones or shaping outcomes. The meaning becomes static, nostalgic, backward-looking. When all three forces are active, something interesting happens. You search for what you don't understand (Discovery), you drive toward shaping what you discover (Play), and you renew connection to what matters (Joy). Then you search again, having expanded what you're capable of understanding. The loop compounds. This is secular meaning: not a destination, but a self-reinforcing cycle of search, drive, and renewal. Discovery, Play, Joy map directly to the three forces in Quest Engine</a>: Searching, Driven, Renewal. The names are different, but the structure is identical. Quest Engine makes these forces operational (how to apply them to work, projects, decisions). Discovery, Play, Joy make them existential (why they matter for a life worth living). One is the framework. The other is the foundation. Discovery is Searching: The pull toward the search for understanding what you don't yet know. Not passive learning, but active exploration. The universe is indifferent, but the act of searching to understand generates the experience of meaning. Play is being Driven: The propulsion from owning decisions that shape outcomes. Not grinding, but engaging with autonomy. The universe doesn't care what you build, but the act of building generates the experience of agency. Joy is Renewal: The verification that what you've been doing still connects to what matters. Not happiness, but alignment. The universe won't remember your work, but the act of seeing it matter now generates the experience of purpose. The secular claim is simple: you don't need metaphysics. You don't need religion. You don't need the universe to care. Discovery, Play, Joy are sufficient. They generate the subjective experience of a life that matters, and that experience is the only "meaning" that was ever available to begin with. Most people don't realize when they've lost one of these forces. They know they feel stuck, empty, or burned out, but they can't articulate why. Making the three forces explicit means you can diagnose which one is missing before the feeling becomes chronic: When Discovery stops: Life feels repetitive. You're executing on what you already know. The job becomes predictable. The world feels smaller. Fix: Block time for exploration. Search for what's adjacent to what you understand. Read outside your domain. Discovery is the muscle that atrophies fastest, but it's also the one that responds quickest to deliberate exercise. When Play stops: Life feels reactive. Decisions don't stick. Outcomes feel predetermined. You're waiting for permission instead of claiming agency. Fix: Make boundaries explicit. Identify the space where you do have control and exercise it deliberately. Play requires autonomy, but autonomy without boundaries is overwhelming. Define the edges, then shape what's inside. When Joy stops: Life feels hollow. You're executing but don't know why. The work gets done, but it doesn't feel like it matters. Fix: Ask explicitly: "Does this still connect to what I care about? Has the goal shifted while I was executing?" Joy requires verification, and verification requires pausing to check. If you can't articulate why something matters, that's the signal to realign. The diagnostic is simple: Which force is missing? Not as a permanent state, but as a current gap. You're not trying to maintain all three forces 100% of the time. You're noticing when one has drifted and choosing to come back. On aggregate, that consistency compounds. Here's the secular claim stripped to its core: meaning isn't something the universe provides. It's something you experience when you're fully engaged with being alive. Discovery is full engagement with the search for understanding. Play is full engagement with the drive to shape. Joy is full engagement with the renewal of verifying that the first two still matter. You don't need cosmic significance. You don't need destiny. You don't need the universe to remember you. What you need is simpler: the pull toward the search for understanding what you don't yet know, the drive to shape what you can control, and the renewal of seeing that both still connect to what you care about. When all three forces are present, the question "what's the meaning of life?" stops being a question. The answer is: this. Right now. The search, the drive, the renewal. This is it. Most people wait for meaning to arrive. They think: once I finish this project, once I reach that milestone, once I figure out the answer, then life will feel meaningful. But meaning doesn't work that way. It's not the endpoint. It's the experience of the search for understanding (Discovery), the drive to shape outcomes (Play), and the renewal of verifying alignment (Joy). The motion is the meaning. The secular meaning of life is this: Discover what you don't yet understand. Play with what you can shape. Find joy in renewing the connection between the two. The universe doesn't care. You do. That's enough. Discovery, Play, Joy as secular meaning connects to the Quest Engine framework</a> (Searching, Driven, Renewal), which sits above operational cycles and defines what success means. The three forces are diagnostic: when life feels meaningless, check which one is missing. For the complete framework, see the Quest Engine introduction</a> and the Objective Function pillar</a> in the ingenio repository. Craftsmanship, Judgment, and Taste: What Humans Bring to Agent Collaboration 2026-04-19T00:00:00+00:00 I keep hearing "taste, judgment, and craft" on podcasts about exceptional engineers. These terms feel vague until you work with AI coding agents. Then they become concrete: they're exactly what humans bring to the collaboration. But there's an order to how these develop. You need craftsmanship to inform judgment, and you need judgment to develop taste. They're not independent traits—they're dependent stages in a loop that repeats and compounds. Craftsmanship is systematic exploration of solutions. Agents can search faster, but you decide what's worth learning. Judgment is knowing what you control versus what you delegate. Agents can handle implementation, but you decide the boundaries. Taste is knowing what's worth building and why. Agents can generate solutions, but you decide which problems matter. These three aren't innate talents—they're skills you develop through practice. And they map directly to how the Quest Engine framework</a> works: craftsmanship connects to searching (mastery), judgment to being driven (autonomy), and taste to renewal (purpose). Craftsmanship: Mastery Through Searching</h2> Craftsmanship is building expertise through deliberate practice. An engineer with craftsmanship doesn't just know one authentication pattern. They've systematically explored OAuth, session tokens, JWTs, passwordless approaches. They understand trade-offs and when each applies. Craftsmanship separates expertise from mere experience. After evaluating ten authentication systems, you develop mental models: "stateless scales, stateful gives control, hybrid balances both." After reviewing a hundred PRs, you distinguish "good enough" from over-engineering. With AI agents, craftsmanship means knowing what to explore. An agent can quickly survey five different database patterns. Your craftsmanship determines which ones are worth understanding deeply. You're not learning randomly—you're building mental models that guide future decisions. This is searching in the Quest Engine: proactive curiosity about what's worth knowing. You explore alternatives, synthesize patterns, build understanding before you need it. Agents accelerate searching. They help you explore alternatives faster, synthesize patterns from multiple sources, and compare approaches side-by-side. You decide what's worth searching for; agents help you search more thoroughly. Judgment: Autonomy Through Being Driven</h2> Judgment is understanding your scope of authority and exercising it consistently. An engineer with judgment doesn't ask permission to refactor a function, but also doesn't unilaterally rewrite the architecture. When you have explicit boundaries with freedom inside them, judgment develops naturally. You make decisions, see consequences, adjust calibration. "I own implementation details. I coordinate on shared dependencies. I get review on architectural changes." With AI agents, judgment determines the collaboration model. Do you ask the agent to explain the approach while you implement? Or do you have the agent generate code while you review? The boundary shifts based on context, but what matters is that it's explicit. An engineer driven by learning keeps tight control—agent explains, human implements. An engineer driven by delivery delegates more—agent generates, human reviews. Neither is wrong. Judgment is knowing which mode fits the current goal. This is being driven in the Quest Engine: you're propelled by ownership over decisions that matter. Clear boundaries create space for autonomy. Agents multiply your autonomy. They handle mechanical work (boilerplate, routine refactoring), expanding bandwidth for decisions that matter. You focus on architectural choices and strategic direction, not buried by tasks that can be delegated. Taste: Purpose Through Renewal</h2> Taste is pattern recognition about what's worth doing. An engineer with taste doesn't just ask "can we build this?" They ask "should we?" When you've shipped ten features, you develop taste for what users actually value versus what seemed important in planning. When you've debugged a hundred production issues, you develop taste for which metrics signal real problems versus noise. With AI agents, taste becomes crucial. An agent can generate five different authentication implementations. Your taste determines which approach fits the context: is OAuth overkill for this internal tool? Is passwordless actually what users want? Is technical debt acceptable here? Taste emerges from systematic reflection—comparing what you expected versus what actually happened. Every sprint, every project, you're extracting patterns. This is renewal in the Quest Engine: you're continuously verifying "does this still connect to meaningful outcomes?" Agents help you develop taste faster. They can extract patterns from repeated interactions, help you compare approaches, and surface data about outcomes. But the judgment about which patterns matter—that's human. That's taste. Why These Three Matter for Agent Collaboration</h2> When you work with AI agents, these three define the collaboration—and they build on each other: Craftsmanship determines which solutions you explore. The agent can search faster, but you bring the systematic approach to learning. Without craftsmanship, you might find an answer but miss the better pattern. Judgment determines how you divide the work. The agent can handle implementation, but you decide the boundaries. Without judgment, you either micromanage (wasting the agent's capability) or over-delegate (losing control of critical decisions). Taste determines what problems you solve together. The agent can generate solutions, but you bring the sense of what's worth building. Without taste, you might execute perfectly on the wrong problem. Together, they create a compounding loop: Your craftsmanship (systematic exploration) reveals which problems you're equipped to solve. That expertise guides your judgment about what to own versus delegate. Your judgment creates data—the decisions produce outcomes. Those outcomes feed taste—you extract patterns about what actually matters. That refined taste guides what you explore next. Each cycle: better craftsmanship from exploration, better judgment about boundaries, better taste for what matters. Developing These Deliberately</h2> Build craftsmanship through systematic exploration: Don't just solve the immediate problem. When you implement authentication, explore three alternatives. Understand their trade-offs. Build the mental model before you need it. Use agents to accelerate this. Ask them to compare approaches, explain trade-offs, and show examples. You're not outsourcing the learning—you're using agents to explore more thoroughly than you could manually. Build judgment through clear boundaries: Make ownership explicit with your team and with agents. "I own architectural decisions. The agent handles implementation details. I review before merging." When boundaries are clear, judgment develops through practice. Right-size the work. If you're learning, keep tight control. If you're shipping, delegate more. Each success builds confidence in your calibration. Build taste through systematic reflection: After every meaningful cycle, ask: What did I expect? What actually happened? What pattern explains the delta? Compare your predictions to reality. The gap is the learning signal. When working with agents, this becomes concrete. Did the agent-generated code perform as expected? Did the approach you chose fit the context? What would you do differently? This reflection turns experience into pattern recognition. The Connection to Quest Engine</h2> These three map to the Quest Engine framework, but they're not the same thing: Craftsmanship (mastery) connects to Searching—systematic exploration that builds expertise. Judgment (autonomy) connects to Being Driven—clear ownership within explicit boundaries. Taste (purpose) connects to Renewal—systematic reflection that reveals what matters. The Quest Engine provides the structure. Craftsmanship, judgment, and taste are what you bring to that structure when working with AI agents. They're the human contribution to the collaboration. Craftsmanship, judgment, and taste define what humans contribute when working with AI coding agents. For the complete Quest Engine framework, see Quest Engine: A Framework for Agent-Human Collaboration</a>. For the intrinsic motivations behind these forces, see Quest Engine: The Why Behind the How</a>. Stay Hungry. Stay Foolish. — The Mindset Behind the Quest 2026-04-12T00:00:00+00:00 In 1968, Stewart Brand started publishing the Whole Earth Catalog (a counterculture toolbox for self-sufficiency, alternative education, and personal empowerment). Steve Jobs later described it as "a sort of Google in paperback form, thirty-five years before Google came along." Its motto was simple: "access to tools." In 1974, the final issue rolled off the press. On the back cover, below a photograph of an early morning country road, were four words: Stay Hungry. Stay Foolish. </blockquote> A parting gift from Brand and his editors to their readers. No explanation. No attribution. Just a dare. Thirty-one years later, Steve Jobs borrowed those words to close his 2005 Stanford commencement address</a> (a speech about dropping out, getting fired from the company he built, and facing death). He told the graduates: "When I was young, there was an amazing publication called The Whole Earth Catalog… On the back cover of their final issue was a photograph of an early morning country road… and beneath it were the words: 'Stay Hungry. Stay Foolish.' It was their farewell message as they signed off. Stay Hungry. Stay Foolish. And I have always wished that for myself. And now, as you graduate to begin anew, I wish that for you." </blockquote> The full speech and transcript are preserved at the Steve Jobs Archive</a>. You can explore the original Whole Earth Catalog issues at the Whole Earth Index</a> and the Internet Archive</a>. What the words actually mean</h2> Hungry doesn't mean starving. It means unsatisfied on purpose. The refusal to coast. The decision that where you are is never where you stop. Foolish doesn't mean reckless. It means willing to look like you don't know what you're doing (because often, you don't, and that's exactly where growth lives). It means choosing the question over the safe answer. Choosing the project you might fail at over the one you already know how to finish. I've heard people describe this state as being "dumb, happy, curious" — though I prefer "foolish, happy, curious." Because foolish alone isn't enough. You also need to be happy — genuinely enjoying the not-knowing, finding energy in the gap instead of anxiety. Not tortured by how far you have to go, but lit up by the fact that there's somewhere to go at all. And you need to be curious — that's the actual engine. Curiosity is what turns foolishness from aimless into directional. It's the pull toward the next question, the next thing you don't understand yet, the next door you haven't opened. Foolish gets you to start. Happy keeps you going. Curious tells you where. Together — hungry, foolish, happy, curious — they describe a state of permanent, joyful pursuit. Not grinding. Not hustling. Questing. The engine of self-advancement</h2> The trap most people fall into isn't laziness — it's expertise. You learn enough to be comfortable, and comfort becomes the ceiling. The Whole Earth Catalog existed to fight that trap. Its entire premise was: here are tools you didn't know existed, for problems you haven't thought to solve yet. It assumed its readers were hungry enough to reach for something they couldn't yet name, and foolish enough to try. Self-advancement isn't a ladder — it's a loop. And that's what "stay" really means. Not that you're always hungry, or always foolish, or always happy, or always curious. You won't be. You'll solve a problem and feel satisfied. You'll master something and feel competent. You'll hit friction and feel frustrated. You'll exhaust a direction and feel directionless. "Stay" means you come back. On aggregate. This is about consistency, not perfection. You're not aiming to be hungry 100% of the time — that's exhausting and unsustainable. You're aiming to notice when you've drifted toward comfort and choose to come back to hunger. Maybe you hit 60% in your first month. Then 70%. Then you plateau at 80-90%, and that's excellent. That's the target. Consistency on aggregate means you're trending toward these states more often than not, building a force of habit rather than forcing yourself. You notice when you've stopped being hungry and you choose to find the next gap. You notice when expertise has made you cautious and you choose to be foolish again. You notice when you're grinding instead of enjoying and you choose to find the joy in the process. You notice when curiosity has gone dormant and you choose to ask the next question. Each time you come back, it gets a little easier. Not because you're perfect at it, but because the habit compounds. Hungry is noticing the gap between where you are and where you could be, and letting it pull you forward instead of ignoring it. Food tastes better when you're hungry. Growth feels better when you're hungry for it. Foolish is starting before you're ready. Asking the obvious question. Building the thing you don't fully understand yet. It sits underneath learning (you can't learn what you already know, so foolishness is the prerequisite). Happy is choosing to see the path itself as the reward. Not grinding toward some future state where you'll finally be good enough, but being lit up by the fact that there's somewhere to go at all. When you choose to be happy, you see things differently. The obstacle becomes interesting instead of frustrating. Curious is the engine. It's what gives foolishness direction. It's the pull toward the next question, the thing adjacent to what you already know, the door you haven't opened yet. Even after you've learned something and know everything about it, curiosity finds the next adjacent unknown. The people who keep growing aren't the ones who know the most. They're the ones who keep coming back to not-knowing. Not every day. Not perfectly. But on aggregate, consistently enough that it becomes a force of habit. The Quest Engine</h2> When I kept noticing the same pattern (smart people working hard on the wrong problems), I started searching for a way to articulate what was missing. They knew enough to execute, but they'd stopped questioning whether execution was pointed in the right direction. They'd mastered the how but forgotten to keep asking why. So I built something for myself called Quest Engine</a>. Not as a rule or a system everyone should follow, but as a personal tool to keep me from falling into the expert's trap. Quest Engine is what happened when I tried to turn "stay hungry, stay foolish, stay happy, stay curious" into something I could use day-to-day. The framework has three recursive forces — Searching, Driven, Renewal — and they map directly to the loop of coming back: Searching is staying hungry and staying curious working together. It's the active process of noticing the gap (hungry) and exploring what matters most (curious). Not waiting until you need something, but proactively searching for what's worth learning before the problem hits. Food tastes better when you're hungry — and you search better when you're hungry for what comes next, driven by curiosity about what's adjacent to what you already know. Driven is staying foolish in action. It's starting before you're ready, owning the decisions that compound, having the autonomy to shape the path forward. You're propelled by the control you have over getting there, not waiting for permission. Foolishness sits underneath this (you can't be driven toward something you're too cautious to attempt). Renewal is staying happy as a practice. It's the ongoing process of checking whether the work still connects to what matters, whether you're grinding or questing, whether the problem you started solving six months ago is still the right problem. When you choose to see the path as the reward, renewal becomes the checkpoint that asks: "Am I still finding joy in this? Or have I drifted into just executing?" The Whole Earth Catalog ethos of "access to tools" is still there — Quest Engine isn't about what to do, it's a meta-tool for figuring out which tools matter. It's useful to me. If other people find it useful, great. If not, that's fine too. What makes it work isn't that it's universal, it's that it makes the loop explicit: notice when you've stopped being hungry or foolish or happy or curious, and choose to come back. On aggregate, that consistency compounds. You're not trying to hit 100% — you're building toward 80-90% as a force of habit, and that's where growth lives. The quest itself is the engine of growth. Sources</h3> Source</th> Link</th></tr></thead> Steve Jobs' 2005 Stanford Commencement Address (video)</td> YouTube</a></td></tr> "Stay hungry, stay foolish" — Steve Jobs Archive</td> stevejobsarchive.com</a></td></tr> Whole Earth Catalog — Wikipedia</td> Wikipedia</a></td></tr> Whole Earth Catalog — Full digital archive</td> Whole Earth Index</a></td></tr> Whole Earth Catalog (Fall 1968) — Internet Archive</td> archive.org</a></td></tr> Stewart Brand — Wikipedia</td> Wikipedia</a></td></tr> </tbody></table> Quest Engine: The Why Behind the How 2026-04-11T00:00:00+00:00 The Quest Engine framework</a> describes three recursive action steps: Contextual Awareness (understand before acting), Clear Strategy (execute based on what you know), and Systematic Improvement (make the next cycle better). These three moves form a compounding loop. But there's a question that sits above this entire cycle: Why? Why are we acting? What does "better" even mean? Who decides? Search, Drive, and Renew are the answer to that question. The Problem with Optimization Without Purpose</h2> Here's a pattern I've seen repeatedly: teams execute flawlessly on the wrong goals. Engineers work hard, ship features, hit metrics, and everyone is busy. But two years later, the codebase is unmaintainable, the best engineers have left, and nobody can explain why the product exists. The system optimized itself toward metrics that didn't matter. The failure wasn't in the HOW (teams knew how to build software). The failure was in the WHY (nobody questioned whether they were building the right thing). You can execute perfectly on a misaligned objective and end up further from where you wanted to be. That's what Search, Drive, and Renew prevent. These three forces sit above the operational cycle and continuously ask: "What does success actually mean? Are we still aligned on that definition? Is the thing we're optimizing for still the thing that matters?" The Three Forces: Searching, Driven, Renewal</h2> The WHY sits above everything else because it defines what success means before you act. Most people aren't consciously aware of their intrinsic motivations. They know they feel unmotivated or burned out, but they don't know which force is missing. The three forces are: Searching: "What does better look like?" The drive to research, explore, and discover what improvement means. Not just learning, but actively searching for what's worth learning. Driven: "What can I control?" The force that propels you forward when you have autonomy. You're driven by ownership, by the ability to make decisions that matter. Renewal: "Am I still aligned with what matters?" The ongoing process of renewing purpose, checking whether yesterday's goal still serves today's reality. These three mirror the operational cycle (Prospective, Actuation, Retrospective). Together, they create sustainable motivation. When any one is missing, performance degrades. Missing Searching → stagnation. Missing Driven → learned helplessness. Missing Renewal → burnout. Searching: What Does Better Look Like?</h2> Searching is the active process of researching what improvement means. Not passive learning, but deliberate exploration. You're searching for the skill gap that matters most, the knowledge that unlocks the next level, the capability that removes the biggest blocker. Most people don't realize they've stopped searching. They're executing on yesterday's definition of "better" while the world has moved on. An engineer spends months optimizing database queries, then joins a team where the real bottleneck is service-to-service communication. The effort wasn't wasted, but the searching stopped too early. They found one answer and stopped looking for whether it was the right answer. Here's what makes Searching hard: you don't know what you don't know. An engineer joining a distributed systems team doesn't know whether to focus on consensus algorithms, observability patterns, or failure modes. All three matter, but which one is the highest-leverage starting point? That's the search: finding not just what to learn, but what sequence unlocks understanding fastest. The meta-skill with AI coding agents is searching for how to use them effectively. An engineer new to agents tries to use them like Google (ask question, get answer). After searching for better patterns, they discover agents work best for generating boilerplate, exploring alternatives, and explaining unfamiliar patterns. Same tool, but searching changed how they use it. This is meta-mastery: searching for how to search more effectively. When Searching stops, you get skill stagnation. You're competent at what you already know, but capability doesn't expand. The job market shifts toward new technologies, and you're still optimized for the old stack. Continuous searching means the definition of "better" updates as fast as context changes. Driven: What Can I Control?</h2> Being driven means you're propelled by ownership over decisions that matter. You're not just executing someone else's plan—you're shaping the path forward. The force comes from autonomy: knowing what's within your control and having permission to exercise that control. Most people don't realize when they've lost this force. An engineer joins a team where every decision requires approval. Which library? Ask the manager. How to structure code? Check with the lead. When to refactor? Wait for permission. Six months later, they've stopped making decisions. They learned that exercising judgment creates friction, so they stopped trying. They're no longer driven—they're compliant. This is learned helplessness. The motivation to act dies when you learn that action doesn't lead to results. The opposite failure is paralysis from too much freedom. An engineer is told "build the payment system" with no constraints. They have autonomy, but no boundaries. Three months later, they've built something that doesn't integrate with existing infrastructure. Freedom without guidance isn't motivating—it's overwhelming. Being driven requires explicit boundaries with freedom inside them. "You own implementation decisions for your service. Coordinate with platform team on shared dependencies. Architectural changes affecting other teams need design review. Everything else is yours." Clear constraints create safe space for being driven by ownership. With AI coding agents, being driven means knowing what to delegate versus what to control. An engineer driven by learning keeps tight control (agent explains, human implements). An engineer driven by delivery delegates more (agent generates, human reviews). The boundary shifts, but what matters is that it's explicit. When you're driven, you're choosing what to own and what to hand off, not defaulting to one or the other. When you're driven, routine work multiplies your capability. Agents handle boilerplate, teammates handle their domains, automation handles the mechanical. Your decision-making bandwidth expands because the operational load is distributed. Being driven means you're propelled by ownership of what matters most, not buried by what could be delegated. Renewal: Am I Still Aligned?</h2> Renewal is the ongoing process of checking whether what you're doing still connects to what matters. Not a one-time decision, but continuous verification. The purpose you started with six months ago might not be the purpose that matters today. Renewal is catching that drift before it compounds. Most people don't realize when they've lost alignment. An engineer starts a project to improve system reliability. Six months later, they're still optimizing for reliability, but the business discovered product-market fit and now the priority is shipping features. The engineer keeps suggesting conservative, reliability-focused changes while the team increasingly overrides them. The work is competent. The purpose has drifted. Without renewal, the gap widens silently. This happens because execution momentum carries you forward. You're hitting milestones, making progress, staying busy. But you're not asking: "Is this still the right thing?" Projects that start with clear purpose ("help doctors diagnose diseases faster") erode into vague execution ("build another CRUD interface for hospital IT"). Nobody set out to build something meaningless, but without renewal, purpose degrades from specific to generic to hollow. Renewal means periodic verification. Every sprint, every quarter, ask explicitly: "Does this work still connect to meaningful outcomes? Has context shifted? Am I solving yesterday's problem while today's problem grows?" Sometimes the answer is yes, keep going. Sometimes it's no, and that saves months of misaligned effort. With AI coding agents, renewal happens when you can't articulate what you want. An agent asks "what should this function optimize for?" and you realize you don't know. That's the signal. The purpose has drifted so far that you can't explain it clearly. The act of trying to give an agent explicit direction surfaces whether your own direction is still valid. Renewal is what separates sustained motivation from burnout. When searching shows you're growing, when being driven shows you have control, and when renewal shows the work matters—that's intrinsic motivation. When any one is missing, the system breaks. No searching → stagnation. No drive → helplessness. No renewal → burnout. The WHY is knowing which force is missing before motivation collapses entirely. The WHY Above the HOW</h2> Here's why the WHY matters most: people execute competently on the wrong goals all the time. They have the HOW figured out (Contextual Awareness, Clear Strategy, Systematic Improvement). But they're optimizing for yesterday's definition of success. The WHY sits above the operational cycle and asks: "Are we even optimizing for the right thing?" The three forces work together: Searching discovers what "better" means in your current context. Not what "better" meant last year, but what it means now given where you are and where you're trying to go. Being driven means you have control over getting there. You're not waiting for permission to act on what searching revealed. You own the path forward. Renewal verifies the destination is still correct. The thing you're searching for and driving toward—does it still matter? Or has the world shifted while you were executing? When all three forces are present, you get sustained motivation. When one is missing, the system degrades predictably: Searching without being driven → you know what to do but can't act on it</li> Driven without searching → you're executing but don't know if you're building the right thing</li> Searching and driven without renewal → you're optimizing efficiently toward an obsolete goal</li> </ul> Working with AI coding agents makes these forces visible. When searching, agents help you explore what's possible faster than reading docs alone. When driven, agents handle mechanical work so you control higher-leverage decisions. When renewing, trying to explain what you want to an agent surfaces whether you actually know what you want. The agent isn't creating the motivation—it's revealing which force is missing. The WHY is about intrinsic motivation that most people aren't consciously tracking. They know they feel burned out or stuck, but they don't know it's because renewal stopped. They know they're not growing, but they don't realize searching stopped. They know they feel micromanaged, but they don't connect it to losing the drive from ownership. Making the WHY explicit means you can diagnose which force is missing before motivation collapses entirely. Applying the Three Forces</h2> The WHY isn't abstract philosophy. It's diagnostic. When motivation drops, ask which force is missing: If you feel stuck or stagnant: Searching has stopped. You're executing on what you already know instead of actively researching what's next. Fix: Block time for exploration. Use AI coding agents to explore unfamiliar patterns faster. Read code outside your domain. The meta-skill is searching for what's worth searching for. If you feel micromanaged or helpless: Being driven has stopped. You've learned that decisions don't stick, so you stopped making them. Fix: Make boundaries explicit with your team. "I own implementation decisions for my service. I'll coordinate on shared dependencies. I'll ask for review on irreversible changes." Clear constraints create space for ownership. If you feel burned out or disconnected: Renewal has stopped. You're executing on yesterday's purpose while context has shifted. Fix: Ask explicitly every quarter: "Does this work still connect to meaningful outcomes? Has the goal changed while I was executing?" When you can't articulate to an agent (or to yourself) why something matters, that's the signal to pause and realign. The connection to AI coding agents: These tools don't create motivation. They reveal which force is missing. If you're searching, agents help you explore faster. If you're driven, agents multiply your control by handling mechanical work. If renewal has stopped, trying to explain what you want to an agent surfaces that you don't actually know. The agent is a forcing function for making your intrinsic motivations explicit. The WHY is Timeless</h2> Here's what makes the WHY the most important piece: the HOW changes with technology, but the WHY doesn't. Ten years ago, developers wrote code in different languages with different tools. Ten years from now, AI coding agents will handle more of the mechanical work. But the fundamental forces—searching for what matters, being driven by ownership, renewing purpose—those don't change. Most people aren't consciously aware of their intrinsic motivations. They know they're unmotivated, but they don't know which force is missing. Making the WHY explicit means you can diagnose the problem before it becomes burnout or stagnation or learned helplessness. With AI coding agents, the meta-pattern emerges: searching for how to use agents effectively is itself a skill. Being driven means controlling what you delegate versus what you own. Renewal means checking whether the problem you're solving with agents is still the right problem. The tools change, but searching, being driven, and renewing are constant. The Quest Engine</a> works because it makes the WHY explicit. Before you execute the HOW (Contextual Awareness, Clear Strategy, Systematic Improvement), you verify the WHY: what you're searching for is worth finding, what you're driven toward is worth owning, and what you're renewing is still worth pursuing. That's what separates systems that improve from systems that just execute faster toward the wrong destination. Searching, being driven, and renewal (the WHY) sit above the operational cycle in the Quest Engine framework</a>, which originates from presentation materials on engineering and career development</a>. For the complete treatment of these intrinsic motivations, see the Objective Function</a> and Intrinsic Motivation</a> pillars. The name "Quest Engine" connects "quest" (Latin quaere, to seek) with "engine" (Latin ingenium, cleverness), representing systematic inquiry driven by continuous improvement. Quest Engine: A Framework for Agent-Human Collaboration 2026-04-08T00:00:00+00:00 The Quest Engine framework</a> is built on three recursive action steps that help you solve problems at any scale. These steps work because they align with how you naturally search for better solutions, how you're driven to act on what you discover, and how you renew your understanding as context evolves. AI coding agents amplify these processes (they're tools that multiply your leverage, not replacements for your judgment). The Problem</h2> Engineering teams don't fail because they lack smart people. They fail because smart people work hard in isolation, without a shared system. Knowledge isn't built together. Decisions aren't grounded in shared context. Improvements don't compound. What's missing isn't more process. What's missing is a coherent operating system that makes teams smarter over time. That's what the Quest Engine provides. Three Moves: Search, Drive, Renew</h2> The Quest Engine has three action steps that you repeat continuously. Each cycle leaves you better than the last. These three moves are how the why behind the how</a> manifests in practice. Contextual Awareness (Searching): Understand before acting. Search for what's true right now. What dependencies exist? What will change? What do you know that others don't? You're actively searching for the context that shapes better decisions. Clear Strategy (Driven): Execute based on what you know. Be driven forward by ownership and control. Set a clear goal. Match the challenge to your capability. Act with tight feedback. You're driven by the autonomy to shape the path forward. Systematic Improvement (Renewing): Examine what happened against what you expected. Renew your understanding and verify alignment. Find the root pattern, not just the symptom. Make the improvement permanent. Spread it to everyone with the same problem. These three moves form a compounding loop. Searching shapes what you Drive toward. Being Driven creates data for Renewal. Renewal feeds richer context back into Searching. Each cycle, you search more effectively, you're driven by clearer ownership, and you renew with better calibration. All three working together create the compounding effect (but renewal is the secret sauce that turns experience into permanent gains). The Framework Structure</h2> Here's the complete structure showing how each pillar follows the same recursive pattern: Phase</th> Contextual Awareness (Searching)</th> Clear Strategy (Driven)</th> Systematic Improvement (Renewing)</th></tr></thead> Main Action</td> Search: Understand before acting</td> Drive: Execute based on what you know</td> Renew: Make the next cycle better</td></tr> Step 1: Search</td> Proactive CuriositySystematically find and organize information</td> Challenge MatchingAssess where your capability meets the challenge</td> Iterative IntegrationMeasure results against expectations</td></tr> Step 2: Driven</td> Cohesive NarrativeBuild accurate mental models</td> Directed IntentionalityCommit to one clear objective</td> Deliberate PracticeIdentify patterns to improve</td></tr> Step 3: Renewal</td> Shared UnderstandingKeep everyone aligned on what's true</td> Adaptive ControlAdjust based on feedback</td> Update PropagationMake improvements permanent and spread them</td></tr> </tbody></table> Each column is a complete cycle. Each row represents the same type of action across all three pillars. The structure repeats at every scale. The framework is self-similar at every level. Each pillar has its own internal Search → Driven → Renewal structure. A single code review follows the same pattern as an entire career: search for information, drive synthesis into a decision, renew to make that decision stick. Contextual Awareness: Searching</h2> Proactive Curiosity: Systematically search for and organize information. Crawl your domain (code, docs, people, systems), index it for retrieval, fuse signals from multiple sources. Don't wait to need information (build the index before the fire). Agents can automate much of this mechanical crawling, giving you leverage over what would otherwise be tedious manual work. Cohesive Narrative: Create accurate mental models and continuously update them. Raw data isn't useful without synthesis. You need a coherent picture of how the system works, who it serves, and where it's headed. This synthesis is human judgment (you decide what signals matter and how they connect). Shared Understanding: Actively align mental models across the team. Writing a document is the beginning, not the end. When something changes, does the whole team's understanding renew, or does it silently fragment? This step requires allocated time (you can't mechanize alignment). Schedule it deliberately: onboarding sessions, design reviews, retrospectives. These aren't optional ceremonies; they're the forcing function that prevents knowledge from fracturing into private versions. An engineer onboarding to a new team reads the codebase and traces service interactions (Proactive Curiosity). They synthesize that into a mental model of how the system fits together (Cohesive Narrative). They write it up and verify with senior engineers (Shared Understanding). Two weeks of investment, years of compounded return. AI coding agents amplify your searching. They crawl code faster and synthesize patterns from multiple sources. You decide what's worth searching for; agents help you search more thoroughly. Clear Strategy: Being Driven</h2> Challenge Matching: Balance challenge against skill. Too hard → anxiety. Too easy → boredom. Right-sized → Flow, and you're driven by momentum. The key is sizing work to maintain forward progress. Break large problems into smaller chunks that you can ship incrementally. Each completed chunk gives you momentum. Each completed chunk gives you feedback. The loop keeps you in flow. Directed Intentionality: Commit fully to one objective. Eliminate competing priorities that fragment attention. When you know exactly what success looks like, all available attention flows toward achieving it. Clear goals create forward progress. Unclear goals create thrashing. Adaptive Control: Act with immediate feedback. Every action is a data point. The difference between expert and novice performance is the speed of the feedback loop and the precision of the adjustment. When you're stuck, tight feedback surfaces the blocker fast. Debug by shortening the loop: instead of building everything then testing, test each piece as you go. Stuck on a complex refactor? Ship a smaller version first. Stuck on unclear requirements? Show a prototype and get feedback. Forward progress comes from detecting stalls early and adjusting course. A team writes down exactly what "done" looks like for every story (Directed Intentionality). They assign work based on current skill levels with explicit stretch targets (Challenge Matching). They run daily demos with real deployment feedback (Adaptive Control). The result: higher velocity, fewer surprises, engineers who grow. AI coding agents multiply your drive. They handle mechanical work so your decision-making bandwidth expands. You're driven by ownership of what matters most, not buried by what could be delegated. Agents give you leverage (you focus on the hard decisions, they handle the repetitive implementation). Systematic Improvement: Renewing</h2> Renewal is where the magic happens. This is the most human part of the framework (the deliberate reflection that turns raw experience into permanent capability). Agents can assist (extracting patterns, automating proven processes), but the judgment about what to improve and why is yours. Iterative Integration: Constantly integrate new data about system state against expected state. Run tests (automated and human: postmortems, retrospectives, assumption checks). Ask "is this still true?" continuously. You're renewing your mental models based on what actually happened, not what you hoped would happen. This is honest self-reflection, not blame. The delta between expected and actual is the learning signal. Deliberate Practice: For every process, behavior, or component: do less of / keep doing / do more of. Don't fix this incident; fix the class of incidents. Distinguish signal from noise, recognize recurring patterns, extract lessons that apply beyond the specific case. This is deeply human thought (recognizing the pattern beneath the symptoms, deciding which improvements have the highest leverage). You can't automate this judgment, but agents can help surface the data that informs it. Update Propagation: Improvements don't stay local. Eliminate waste permanently (don't defer, delete), mistake-proof the system (make regression structurally impossible), automate what's proven (keep human judgment in the loop), standardize before spreading (lock in the gain), and propagate horizontally (find every team with the same problem, apply the fix everywhere). Renewal spreads knowledge. Without propagation, you're just locally optimizing. After a production outage, a team runs a blameless postmortem (Iterative Integration). They identify the root pattern: "we treat config as 'not code,' but config controls production behavior." They build a concrete do-less / keep / do-more plan (Deliberate Practice). They implement config-as-code and share the fix with three other teams (Update Propagation). The outage becomes a system-wide renewal. Renewal is the secret sauce. Searching and being driven create velocity. Renewal creates compounding. Without renewal, you execute faster but don't get better. With renewal, every cycle leaves you more capable than the last. The system improves what it does AND improves what it's optimizing for. That's the difference between a team that works hard and a team that gets exponentially better. AI coding agents accelerate your renewal. They help you extract patterns from repeated interactions, automate proven processes, and propagate improvements across codebases. You decide what patterns matter; agents help you scale the renewal. The Recursive Nature</h2> The Quest Engine is a system, not a checklist: the HOW feeds back to refine the WHY. Each cycle doesn't just produce better outputs (it recalibrates what "better" means). This is the connection between the operational cycle (how you execute) and the objective function above it</a> (why you're executing at all). Searching reshapes understanding of goals. Deep context exposes where your goals have drifted from reality. You're not just searching for how to achieve the goal (you're searching to verify the goal is still right). Being Driven validates what success looks like. Execution outcomes prove or disprove your assumptions about what "better" means. Being driven by real outcomes keeps you aligned with what actually works. Renewing reveals what actually matters. Pattern recognition across improvements shows which actions drive real value. Renewal surfaces whether you're still optimizing for the thing that matters. Each cycle of Searching → Being Driven → Renewing produces richer context, more calibrated execution, and more precise learning. Each cycle also refines your objectives. The system that improves what it does AND improves what it's optimizing for (that system outlasts every other). Quest Engine in Practice</h2> Here's how Searching → Being Driven → Renewing works when building authentication: Searching: You review existing systems and find a design doc evaluating auth options. You synthesize understanding: OAuth + JWT is stateless and scales; session tokens require server-side state. You verify this with the team (allocating time for Shared Understanding, not just documenting). Driven: You write a vision doc with clear success criteria. You scope the work to match team capability with a stretch goal (sizing for flow, not overwhelm). You implement OAuth integration with PKCE flow and run daily tests against real deployment environments (tight feedback to maintain forward progress). Renewing: After deployment, you compare actual behavior against expectations. You identify the root pattern: "mobile auth flows need explicit testing on actual devices, not just emulators." You update the testing checklist, add mobile device tests to CI, and share the pattern with other teams. The outage becomes permanent capability, not just a fix. The next cycle starts with richer context, better strategy, and proven improvements. The loop compounds. Applying Quest Engine to Your Workflow</h2> Searching: Use worklogs</a> to capture what you're working on, what you've tried, what you've learned. Write design docs to synthesize architectural decisions. Allocate time for retrospectives (Shared Understanding doesn't happen accidentally). Schedule it. Being Driven: Use effort tracking</a> to see where your time goes and ensure capacity for skill-building work. Set clear sprint goals so everyone knows what done looks like. Break work into sizes that maintain flow (too large and you stall, right-sized and you maintain momentum). Build tight feedback loops through daily demos and continuous deployment. When you're stuck, shorten the feedback loop until you find the blocker. Renewing: Run blameless postmortems to compare expected vs actual. Extract patterns (don't just fix this bug, fix the class of bugs). Share improvements (when you solve a problem, help others solve it too). This is human reflection, agent-assisted at scale. You decide what matters; agents help you propagate it everywhere. The three moves (Searching, Being Driven, Renewing) work whether you're operating alone, with a team, or with AI agents. The structure is the same because the underlying dynamics are the same. And renewal is what transforms temporary success into permanent capability. For AI coding agents specifically: when an agent consistently misunderstands a certain type of request, develop a system within your agent to remember the lesson. Fix the class of problems, not individual instances. All three action steps apply to how you work with agents (they amplify your capabilities, they don't replace your judgment). The Quest Engine framework originates from presentation materials on engineering and career development</a>. The name connects "quest" (Latin quaere, to seek) with "engine" (Latin ingenium, cleverness), representing systematic inquiry driven by continuous improvement. The framework's recursive nature (where each cycle refines both execution and objectives) makes it a compounding system for both humans and AI agents. Stop Conflating Effort Tracking with Work Tracking 2026-04-01T00:00:00+00:00 I started separating effort from work after noticing that a full week could produce plenty of completed tasks and still leave me unable to explain where the week went. Worklogs</a> answered "what am I working on?" But I needed a different answer: where is my time actually going? That's what effort tracking is for. And here's the key insight: effort tracking and work tracking are fundamentally different things that shouldn't be conflated. The Conflation Problem</h2> Most systems conflate effort tracking with work tracking. You have a live site incident system that tracks incidents. You have GitHub for features. You have a security portal for compliance work. Each system tracks the work (what needs to be done, what got done), but none of them are designed to answer "where is my time going?" If you try to track effort in those systems, you run into problems. Live site incidents are about tracking incidents, not tracking your time. GitHub issues are about tracking work items, not tracking effort patterns. When you conflate the two, you lose visibility into your actual time allocation. The solution: separate effort tracking from work tracking. Work tracking stays where it naturally belongs (incidents in your incident system, features in GitHub, compliance work in your security portal). Effort tracking lives in one centralized place focused on one question: where is my time going? A Coarse-Grained Method</h2> My effort groups represent types of work, not individual deliverables: Live Site / Production Support</li> Feature Development</li> POC / Spike Work</li> Technical Debt</li> Security / Compliance</li> Planning / Design</li> </ul> These aren't project names or feature names. They're categories of activity. Multiple features roll up to "Feature Development." Multiple incidents roll up to "Live Site / Production Support." I use tags to group related tasks together (no hierarchy, just tags), and that gives me the flexibility to see patterns without maintaining a complex structure. I track effort with a "dev day," which isn't a solar day but what an average day would have of capacity to do work (minus meetings). For my team, that's 4-6 hours of actual work per day, but we track dev days, not hours. There's no strict math, and it's not meant to be super precise. Some days are longer than others. Some weeks have more days than others (5 vs 6 if you're on-call, for example). A 10-hour day might count as "2 days of effort," though that's rare. The simplicity is the point. I'm trying to understand patterns, not account for every hour. The groups answer questions that task-level tracking can't: "How much time did I spend on live site work last quarter?" With effort groups: one query. Done. "Why didn't I finish the planned features this sprint?" With effort groups: "60% of my time went to unplanned live site work, leaving only 40% for planned features." "Where should I focus to improve things?" With effort groups: "I'm spending 50% of my time in reactive mode. If I can reduce that to 30%, I'd have 20% more time for strategic work." This produces three distinct views: Tasks: What needs to be done ("Implement OAuth login")</li> Worklogs: Document work in progress with context for AI agents</li> Effort Groups: Where time is going in aggregate ("Feature Development")</li> </ul> You might have 20 tasks for authentication, 3 worklogs documenting phases of that work, and all of it logs to one effort group: "Feature Development." One of the biggest benefits appears when work spans multiple systems. Live site incidents are in one system, security tickets in another, feature work in GitHub, IT requests somewhere else. With effort groups, I don't care which system a task lives in. At the end of the week, I categorize my time: "1 day on live site, 2 days on features, 0.5 days on POC work." The effort tracking system sees all of it in one place. My implementation lives in Azure DevOps, but that is only an implementation detail. You could use any system that lets you centralize effort data. In ADO, I track effort in tasks or bugs, but these aren't the same as my work-tracking tasks. These are effort-tracking entries. The key is separating the concerns even when they live in the same system. You might use different teams, different iteration paths, or different areas to keep effort tracking separate from work tracking. I've built simple keyboard-driven tooling that makes logging effort take seconds. I can log a full day, half day, or even 1/3 of a day with just keyboard shortcuts. The tooling automatically subtracts from what's left to do. The granularity stops at thirds - that's coarse enough to be simple, fine enough to be useful. Here's what an effort entry looks like: Title: Feature Development Days: 2.5 Week: 2026-W13 Tags: backend, frontend </code></pre> The key distinction: This ADO task tracks effort (where my time went), not work (what I built). The actual feature work is tracked in GitHub, live site work is tracked in the incident system, etc. But the effort for all of it gets centralized here. ADO is for tracking effort numbers, not detailed notes. Detailed notes, context, and work-in-progress documentation go in worklogs (GitHub Issues) or in the actual work-tracking systems. ADO just tracks: which effort group, how many dev days, when. This only works if you update it frequently, but not obsessively. Minimum: twice a week. Ideally: daily, or at least three times a week. The pattern I follow: Monday, Wednesday, Friday. Update effort at the end of those days. If you wait a whole week, you'll forget. If you update twice a week, you can still remember what you did in the last 2-3 days. Daily is better if you can swing it. The tooling makes it fast enough that daily updates don't feel like a burden. Think about your day, categorize your time, log the numbers. 30 seconds per update, maybe a minute if it was a complex week. Detecting Team Overload</h2> Here's the real value: visibility into whether your team is overloaded. You have three ongoing projects. You planned to spend a third of your time on each. But Project A needs to be done right away, so your team is actually spending all their time on Project A. And they're logging 1.5x normal effort - long days, working weekends. You need to know that. Effort tracking tells you that. Or: you planned 50% feature work, but you're spending 80% of your time on live site incidents and zero on development. That's a signal. Maybe it's temporary, maybe it's a problem that needs fixing. But you can't fix what you can't see. Think of it like CPU monitoring. You don't care about every individual task the CPU is running. You care what those tasks roll up to. Which process is consuming resources? If a game is spawning a thousand tasks and pegging your CPU, you don't debug each task - you see "oh, this game is the problem" and you shut it down. Same concept. This isn't contractor or lawyer billing where you track hours for invoicing. That requires precision. This is monitoring where you need signal, not perfection. 80-90% accuracy is plenty. You're trying to detect patterns: is the team overloaded? Is time going where we planned? Are we spending more time on one thing than another? The groups also evolve over time. I'm still an individual contributor, but the mix of work changes. Some quarters "Feature Development" is 80% of my time. Other quarters I'm doing more POC work or handling more live site incidents. The groups adapt to reflect how you spend your time. You can add categories when you take on new work, retire ones that aren't relevant. The framework is flexible because groups represent activities, not organizational structures. The Separation Is the Point</h2> Stop conflating effort tracking with work tracking. They answer different questions: Work tracking: What needs to be done? What got done? (the actual deliverables - this feature, that bug fix, this incident)</li> Effort tracking: Where is my time going? (the aggregate patterns - how much on features vs live site vs debt)</li> </ul> You might have 10 tasks that took 2 days. You don't need to log 0.2 days per task. You log 2 days to the effort group those tasks roll up to. That's the separation. Effort tracking provides a coarser-grained view than work tracking. You organize work by deliverable (this feature, that incident, this compliance task). You organize effort by type of activity (Feature Development, Live Site Support, POC Work). The centralization is what makes it work. Work tracking can be distributed across multiple systems - that's fine, each system is optimized for its type of work. But effort tracking needs to be in one place, focused on one thing: where is my time going? Even if you use the same system (like ADO) for both, keep them separate. Different teams, different areas, different iteration paths. The separation of concerns matters more than the physical location. Combined with worklogs (what I'm working on, captured with context for AI agents) and work tracking (individual deliverables in their respective systems), centralized effort tracking gives me visibility into whether my time allocation aligns with what matters most. Whether I'm spending more time on areas that I didn't plan for and want to address in the next quarter or month. This distinction gave me the view that task tracking could not: whether my time still matched what I said mattered. Worklogs</a> preserve the story of the work, while effort groups reveal its shape. Keeping those views separate makes both of them more honest. Why I Switched to Worklogs (and You Should Too) 2026-03-28T00:00:00+00:00 I wanted to share something that's been a game-changer for how I organize my work with AI coding agents: worklogs. What worklogs are (and what they're not)</h2> At its core, a worklog is about capturing context so it doesn't vanish when your session ends. Think of it like a scientist's lab notebook 📓. You're running experiments, writing down your thoughts, documenting failures, documenting things that worked. Back in the day you would have used a Notepad file, or a Word doc, or maybe sticky notes. Now you have a super lightweight way to let an agentic loop hold this context for you, so you can reference it and search it easily, without it disappearing. A worklog captures: what you're working on, the status, blockers, notes, links to PRs, and outcomes. It's a living log that both you and your AI agent can read and update. To be clear: worklogs are not agent plans (the plan.md</code> files that AI coding agents create at the start of a task). Some people check these into their repo, others don't. Either way, they're ephemeral: they help the agent think through a problem within a single session. This is NOT about design documents or vision documents. Those still exist and are still important. Worklogs don't replace them. In fact, you can use a worklog to track the creation of a design doc as a deliverable. The distinction is simple: Agent plans = how the agent will execute a task right now (ephemeral, session-scoped)</li> Worklogs = a log of work in flight (persistent, cross-session)</li> Design docs / vision docs = formal artifacts that describe what and why (durable, reviewed)</li> </ul> Agent plans are great for the session they live in. But when you close the session and come back tomorrow, you need something that remembers where you left off, what you tried, and what's next. That's the worklog. </th> Agent Plans</th> Worklogs</th> Design Docs</th></tr></thead> Scope</td> Single session</td> Cross-session</td> Cross-project</td></tr> Purpose</td> Execute a task</td> Track work over time</td> Define what and why</td></tr> Lifetime</td> Session ends</td> Until work completes</td> Permanent record</td></tr> Analogy</td> Whiteboard sketch</td> Lab notebook</td> Published paper</td></tr> </tbody></table> Right now I have seven sessions running in parallel, each working on a different area. Each session has its own worklog. These worklogs give me clarity on: What am I working on across all sessions?</li> What's the status of each piece of work?</li> Which PRs are open, which are blocked, which are done?</li> What did I try that didn't work? What decisions did I make and why?</li> </ul> Without worklogs, that context lives in scattered session histories. With worklogs, it's all in one place, searchable, and any new session can pick up right where I left off. How we built it</h2> GitHub Issues is just the backend we chose. You don't have to implement it this way. You could use Azure DevOps work items, a storage account, or roll out your own endpoint and API. The concept is what matters. A worklog backend needs to be: Easy for agents to push context to (create, update, close via CLI)</li> Easy for agents to pull context from (read, search, filter)</li> Easy for humans to review (readable UI, no special tooling)</li> Easy to categorize and search (labels, filters, full-text search)</li> </ul> We went with GitHub because the API is incredibly simple. Authentication is straightforward, the gh</code> CLI just works, and saving context requires zero ceremony. You could build this on Azure DevOps too, but we found the GitHub API to be so effortless that it just removes all friction. If something better comes along, we swap the backend and the workflow stays the same. The whole thing is powered by a skill file (just a markdown file). That's it. A skill file is a set of instructions that teaches the AI agent a workflow. It defines conventions (how to name things, what labels to use, what template to follow), the CLI commands to run (gh issue create</code>, gh issue edit</code>, etc.), and the decision logic (check for duplicates before creating, ask for a size estimate, link related items). When you say "open a worklog", the agent loads this skill file and follows the instructions. It knows: The template: every worklog has four sections (Context, What to Build, Dependencies, Notes)</li> The conventions: title format, label taxonomy, t-shirt sizing (XS through XL)</li> The lifecycle: not-started → in-progress → pr-open → closed</li> The guardrails: check for duplicates, confirm before creating, never overwrite existing content</li> </ul> Because it's just a markdown file, anyone can write one. You don't need a framework, a plugin system, or a deployment pipeline. You write the instructions, drop the file in your repo, and the agent picks it up. Want to change the template? Edit the markdown. Want to add a new workflow (like syncing from Azure DevOps)? Add a new section to the file. # Example: the entire skill is structured like this .claude/skills/worklog/SKILL.md ├── Conventions (title format, labels, sizing) ├── Issue body template (Context, What to Build, ...) ├── Workflow: Add a work item ├── Workflow: Update an existing item ├── Workflow: Review backlog └── Workflow: Sync from Azure DevOps </code></pre> The skill is the recipe. GitHub Issues is the storage. The gh</code> CLI is the interface. And the AI agent is the one following the recipe. You just talk to it in plain English. YOU COPILOT CLI YOU CODE DONE "open a worklog → creates issue, → do your work, → "mark worklog for this task" adds labels + size update as you go as done" </code></pre> All from your terminal. The agent handles GitHub issue creation, sizing, labels, and status updates. 🚀 The key insight: If you're already using Copilot CLI, worklogs add zero extra work. You just tell the agent: > "open a worklog for this task" > "update my worklog, just finished the database migration" > "mark this worklog as done" </code></pre> You stay focused on your actual work. The agent does the rest. What I love about it: No context switching: you create and update worklogs in the same terminal where you're coding</li> Automatic tracking: sized, labeled, and assigned without you touching GitHub</li> Team visibility: everyone can see what's in flight on the worklog board</li> Built-in history: when you close a worklog, the agent links the PR and summarizes what was done</li> No merge friction: it's just GitHub Issues, no PRs or file conflicts</li> </ul> We still use Azure DevOps to track effort. That hasn't changed. The distinction is what makes this work: </th> Azure DevOps</th> Worklogs</th></tr></thead> Purpose</td> Effort tracking (where is the time going?)</td> Work documentation (what am I doing right now?)</td></tr> Granularity</td> One block of effort (may cover multiple tasks)</td> Individual task (notes, context, outcomes)</td></tr> Updated by</td> You (manually)</td> You + your AI agent</td></tr> Analogy</td> Timesheet</td> Lab notebook</td></tr> AI-native</td> Not yet</td> Built for it</td></tr> </tbody></table> This separation of concerns is what makes it powerful. A single Azure DevOps work item might have multiple worklogs under it, each capturing a different piece of the work. You can link them: the agent tags worklogs with the work item ID and you can tell it "sync worklogs from Azure DevOps" to import items. But the worklog is yours: your notes, your pace, your documentation of what actually happened. The architecture boils down to three layers: You in Terminal ("open a worklog for auth refactor" | "update worklog, found the root cause" | "close it, PR merged")</li> Copilot CLI + Worklog Skill (the agent understands your intent and invokes the skill, which contains templates, labels, sizing, dedup, and sync logic)</li> GitHub Issues (storage) (worklogs, notes, context, outcomes; labels for status, size, category; searchable, persistent, no merge friction; optionally linked to Azure DevOps for effort/sprint tracking)</li> </ol> Worklogs as an agentic work queue</h2> Here's where it gets really interesting 🔄. Because worklogs are structured (title, context, deliverables, dependencies, size), they become a queue of work that an agent can pick up and execute. The flow looks like this: Enqueue: Create worklogs throughout the day as ideas come up, investigations reveal new tasks, or work items land. Takes seconds.</li> Prioritize: Ask the agent "what should I focus on next?" It reads your backlog, checks dependencies and sizes, and recommends.</li> Execute: Pick a worklog and start working. The agent already has all the context (what to build, dependencies, notes). No ramp-up time.</li> Document: As you work, the agent updates the worklog with progress, blockers, and outcomes. Your future self (or teammate) can read exactly what happened.</li> Close: Done? The agent closes the worklog, links the PR, and your backlog shrinks. On to the next one.</li> </ol> The speed gain is in the enqueue step. Capturing work traditionally means stopping, switching to a browser, filling out forms. With worklogs, you say one sentence mid-conversation and it's tracked. That low friction means you actually capture everything, not just the big items you remember to log later. My recommendation: start using worklogs as you go. Don't batch them up or plan a big migration. Just next time you start a task, tell the agent to open a worklog. Update it when you hit a milestone. Close it when you're done. That's it. Where this is heading</h2> All of this is in flux. I'm aware of sprints. I'm aware of Agile. I'm aware of all the different methodologies for organizing work. Worklogs are not trying to replace any of that. The main difference is that a worklog is personal. Think of a scientist's notebook 🧪: you keep your notes in there, you document every experiment, what you tried, what the results were. And then you file it away in a shared space so others can go look at your notes if they need to understand an experiment, or how a result came about. That's exactly what this is. It brings rigor to the engineering process. It moves us closer to how scientific discovery and progress actually work: you hypothesize, you experiment, you document, you share. When a teammate sees a PR and wants to understand how it came about, they can go look at the worklog and find the full story. But it's not a status report for management. It's not a sprint board. It's a lab notebook for software engineering. And here's the beautiful thing: it's not process. You're not manually filling out forms or updating tickets. Your agent is doing it. The rigor comes for free because the agent is already in the loop, already has the context, and captures everything as a natural byproduct of the work itself. You get the discipline of documentation without the overhead of documentation. I also don't think worklogs are their final state. This is an evolution. (I traced how I got here, from sort-of-daily Markdown files in 2017 to monthly Word docs to today's agent-maintained logs</a>, in a separate post.) We're in the early days of figuring out how to work with AI agents, and I think we're going to discover that we need more agent-native ways of working. The old tools were designed for humans coordinating with other humans. The new tools need to account for humans coordinating with agents, and agents coordinating with each other. Worklogs are one step in that direction. They give agents a place to read context, write progress, and pick up where they left off. But I expect new patterns will emerge as the tooling matures. Better ways to interface with agents. Better ways to hand off work between sessions. Better ways to let agents propose, prioritize, and execute autonomously. These are the kinds of new ways of thinking that will start to surface as we build more tools around agentic workflows. Worklogs are where we are today. Tomorrow will look different, and that's the point. My AI Tools Journey Since Claude Opus 4.5: Rust, Scripting Languages, and the Evolution of Agent-Driven Development 2026-02-07T00:00:00+00:00 Before Claude Opus 4.5, I would not ask an agent to build a serious Rust CLI. I stayed with shell scripts because Rust seemed too complex and too easy for an agent to get subtly wrong. Then Opus 4.5 arrived on November 24, 2025, and the boundary moved. The vast majority of my development work has been through GitHub Copilot CLI, and the experience has been nothing short of eye-opening. I've been using it consistently since Sonnet 4.5 came out around September 2025, and it's been a gradual evolution in how I approach coding. The Game Changer: Claude Opus 4.5</h2> Claude Opus 4.5, released on November 24, 2025, was an absolute game-changer. This wasn't just another incremental update (it represented a fundamental leap in capability that transformed how I approach coding). Before Opus 4.5, getting value from agents required significantly more steering. The harness you used had to do more of the heavy lifting, which could be annoying if you were working with a less sophisticated setup. With Opus 4.5, the amount of steering needed dropped dramatically. When I do need to steer now, it's typically because there are multiple valid approaches and I need to apply personal preferences or taste that are difficult to codify. The model brought significant improvements in coding, agentic systems, and overall accuracy. Tasks that would have required multiple iterations became reliable one-shot completions. Here's where things get interesting. Before Opus 4.5, I only wrote shell scripts for my CLI tooling. Rust seemed too complex, too error-prone to attempt with AI assistance. But when Opus 4.5 came out, writing Rust became doable. The vast majority of my Rust journey has been since Opus 4.5, and it's been a revelation (especially within the Rust ecosystem where the model excels). This shift from scripting languages to compiled languages like Rust showcases the progression in AI tooling capability. It's not just about the language choice, it's about what becomes feasible when the AI assistance reaches a certain threshold of reliability. Rust vs Scripting Languages for CLI Tools</h2> The choice between Rust and scripting languages for CLI tooling isn't just about language preference. It's about understanding how AI agents interact with different validation paradigms, and what that means for investing in long-term tooling solutions. Rust development with AI agents has been surprisingly smooth. In Rust, tests live right alongside the code in the same file. This means when an agent is writing or modifying Rust code, it has immediate context about how the code should behave. This contextual awareness leads to significantly better one-shot solutions. My Rust projects have comprehensive CI steps that check code coverage, linting, compilation errors, and integration with tools like cargo</code>. But here's where the real magic happens with compiled languages: The agent can write code, run the compiler, and get immediate feedback without executing anything. The compiler acts as a validation step that guides the agent to make fixes and edits on its own. In scripting languages, the only way to validate is to actually run the code, but with compiled languages like Rust, the agent can validate by compiling. This creates a tight feedback loop where the agent iterates and fixes issues independently, without requiring me to run the code myself. I prefer to validate the final result myself, but the compilation step means the agent can get much further on its own. Rust's strict type system acts as inline documentation. The compiler catches a vast majority of issues, which means the agent's code is validated thoroughly before it ever runs. Even CLI tools and TUIs (Terminal User Interfaces) benefit from this. I've been using Ratatui (a Rust TUI library), and it's been fantastic. Creating a nice command-line interface in Rust with Ratatui is actually easier than doing the same in scripting languages like PowerShell or Bash. The type safety and library ecosystem make complex UIs surprisingly manageable. For Rust, I find that prompts typically result in working code on the first try. The combination of strong types, inline tests, and excellent tooling means less back-and-forth. Scripting languages like PowerShell or Bash present different challenges with AI agents. With scripting languages, you often don't know if something will work until you actually run it. Linters exist, but they're nowhere near as powerful as a compiler. Testing frameworks exist (like Pester for PowerShell), but the testing infrastructure is not as seamlessly integrated as in Rust. Tests are typically in separate files, and the overall testing culture isn't as ingrained. The major upside? Distribution is incredibly easy. Scripts just run on most systems. No compilation, no binary signing (in most cases), no cross-platform build matrices. For internal tools, this low barrier to entry is invaluable. Scripting languages excel at quick automation tasks, but they can become unwieldy when they grow to thousands of lines. The progression I experienced (shell scripts before Opus 4.5, Rust after) highlights important considerations for investing in CLI tooling. Choose Rust for CLI tools when the project will grow beyond a few hundred lines, you need strong reliability guarantees, performance matters, you're building CLIs or TUIs that need to feel polished, you want comprehensive compile-time checking, and AI agents are capable enough to make it feasible (post-Opus 4.5). Choose scripting languages when you need quick automation, distribution ease is paramount, the script will stay relatively small, setup burden needs to be minimal, or you're working with less capable AI models. With capable AI models like Opus 4.5, Rust becomes viable even for smaller CLI tools where you might have previously defaulted to scripts. Once a script reaches thousands of lines, the case for Rust becomes even stronger. One surprising discovery: calling external CLIs from Rust is extremely smooth. There are excellent crate packages that let you call tools like the GitHub CLI (gh</code>) from Rust almost as if you were writing a shell script. This bridges the gap between "I need the robustness of a compiled language" and "I need to integrate with existing command-line tools." One trick I've picked up is spinning up multiple agents to work on different parts of the codebase in parallel. Instead of having one agent refactor an entire large codebase, I'll have a "fleet" of agents each handle individual files. This approach has been much more effective overall, especially when working with the larger codebases that Rust projects tend to become. This feature became available in GitHub Copilot as of January 2026, though it's not particularly visually obvious. You can explicitly tell the agent to spin up sub-agents and even specify which model each agent should use (Opus, GPT, Gemini, etc.). This is incredibly helpful for tasks like inline code reviews where you can have different models review your code to get different perspectives. For example, you can use a prompt like: "Increase the unit test coverage percentage to 80. Spin up a fleet of parallel Opus sub-agents." The agent will then coordinate multiple parallel agents, each working on different parts of the codebase to achieve the goal. The biggest recent development has been Opus 4.6 Fast mode (I like to call it "Ludicrous mode"), which came out on February 7, 2026. It's like having Opus 4.5's thinking power at Haiku's speed. My less than 24 hours of experience with it has been great so far. I can iterate much faster, which could be especially helpful when running multiple sessions across different repos. I'm still evaluating it in the face of long-running sessions which are driven by a plan. Something I need to take a look at is maybe using fast mode for the planning phase before switching to the regular model for actual implementation. The speed boost is undeniable though. The Human Element</h2> Despite all these advances, the fundamentals haven't changed. What to build is still the hardest decision. What NOT to build might be even more important. Taste and product sense can't be delegated. Judgment about trade-offs remains deeply human. Agents are incredible tools for implementation, but the human aspects (vision, taste, prioritization) are more critical than ever. When I need to steer agents now, it's less about correcting errors and more about expressing preferences and taste that are inherently subjective. I believe we're in the middle of a fundamental shift in how software gets written. More and more coding will happen through agents. But this doesn't mean coding is "solved" (it means the problems we focus on are shifting from implementation details to architectural decisions, product vision, and user experience). The timeline has been remarkably tight (all of this transformation has happened in just about three months since Opus 4.5's release in late November 2025). The improvement is more subtle than it might appear: while there was extensive steering to get to the first version before, now we typically get one-shot results. The total steering effort hasn't necessarily decreased, but it's shifted to things that matter like taste and preferences rather than getting basic functionality working. I'm having a lot of fun exploring this new landscape. The combination of powerful AI tools and languages with strong ecosystems (like Rust) creates a development experience that would have seemed like science fiction just a few years ago. Here's to figuring out how to keep these agents on track and using them to build things that actually matter. 🚀 The change I keep coming back to is not that agents made every language equal. They made stronger validation loops easier to use, which changed what I was willing to build in Rust. The human work moved upward toward taste, architecture, and deciding what matters (the same shift behind language choice in the LLM era</a> and proof-carrying work</a>). The tools will keep changing, and I expect my conclusions to change with them. The Evolution of Keyboard Layout Config Mapper: When Agents Are Better Than Automation 2025-12-11T00:00:00+00:00 I built the Keyboard Layout Config Mapper because I wanted one source of truth for every keyboard I used. Following that project from 2022 to 2025 taught me something I did not expect: sometimes the lightest automation is asking an agent to make the change directly. The Keyboard Layout Config Mapper (KLCM)</a> project is a perfect case study in how AI-assisted development is fundamentally changing our approach to automation. The Automation Problem</h2> If you use multiple ergonomic keyboards (Kinesis Advantage360, MoErgo Glove80, custom mods with Nice!Nano controllers) you face a unique challenge: keeping your keyboard layouts synchronized across different firmware systems (QMK, ZMK) with different configuration formats. The vision was clear: create a tool that could parse, validate, and sync keyboard configurations across multiple keyboards, acting as a single source of truth for your layout preferences. The first phase was a manual coding approach. In April 2022, the project started with what any experienced developer would do: write comprehensive code to solve the problem programmatically. The initial PR (#1) was massive (a proper software engineering solution) with: Complete Go packages for keyboard configuration parsing</li> HID to keycode mappings for different firmware types</li> Parser infrastructure for QMK and ZMK config formats</li> Validation and testing framework with proper test coverage</li> Merge and sync algorithms to copy layouts between keyboards</li> String manipulation for in-place file editing</li> </ul> The commit messages tell the story of deep technical work: "we are now able to parse qmk configs without any changes to the source text"</li> "tests are passing"</li> "adding logic to edit files in place"</li> "success: automated config change. Still need to validate on hardware"</li> </ul> This was proper software engineering. Parser generators, type systems, test-driven development, abstractions for different firmware formats. The kind of code that feels satisfying to write because it's solving a hard problem with elegance. Then came the reality check: the tool worked, but it was complex. Every new keyboard layout feature required updating parsers. Every firmware update could break the mappings. The "simple" problem of keeping keyboard configs in sync required maintaining a sophisticated parsing and transformation pipeline. The code existed. It technically worked. But the maintenance burden was real. After the initial burst of development, the project stalled in 2023: A couple of config file updates</li> Some layout experiments</li> But no major development on the tooling itself</li> </ul> This is the classic pattern: the automation tool exists, but maintaining it feels like more work than just... manually editing the configs. The tool that was supposed to save time required its own time investment. The sophisticated Go codebase sat largely dormant, a monument to the challenge of maintaining automation infrastructure. Fast forward to August 2025, and a Copilot renaissance began. The project came back to life, but with a completely different approach. With AI assistance, the V5 target release (PR #12) rebuilt the project with modern CLI tooling: Complete CLI tool with Cobra framework</li> Git-style diff functionality</li> GitHub PR automation</li> Interactive workflows</li> 2000+ lines of old code removed</li> </ul> The commit message is revealing: "🧹 Cleanup Completed: Removed old source/ directory (2000+ lines unused code)" </blockquote> But here's the key insight: this wasn't about abandoning the parsing and automation. It was about using AI coding assistants to build better tools faster. Then came the critical realization. The PRs in November-December 2025 show the pattern shift: PR #28: "Add screenshot key to right pinky column on all ZMK keyboards" Direct changes to adv360.keymap</code>, pillzmod_pro.keymap</code>, glove80.keymap</code></li> Simple, surgical modifications across three files</li> No parser infrastructure needed</li> </ul> PR #26: "Streamline KLCM for ZMK-only keyboards + add pedal docs" Focused on simplification</li> Documentation updates</li> Direct config changes</li> </ul> PR #23: Multiple keyboard config updates with clear, specific changes The pattern is clear: Instead of writing code to automate changes across keyboards, just ask an AI agent to make the changes directly. The Paradigm Shift: Why This Matters</h2> Here's the profound realization that emerged from this project's evolution: The old way was to write code to automate: Identify a repetitive task (syncing keyboard configs)</li> Write parsers to understand the config format</li> Write transformers to modify configs</li> Write validators to ensure correctness</li> Maintain this infrastructure as formats evolve</li> Run your tool whenever you need changes</li> </ol> Time investment: Hours to write, ongoing maintenance burden The new way is to use agents directly: Identify a repetitive task</li> Tell an AI agent: "Add this key to all three keyboards"</li> Agent understands the context, makes the changes</li> Review and merge</li> </ol> Time investment: Minutes per change, no maintenance The KLCM project reveals when agents are better than automation: For many tasks, having an AI agent make direct changes is simpler than writing code to automate those changes. This is especially true when: Changes are needed infrequently (monthly keyboard layout tweaks, not hourly deployments)</li> The task requires contextual understanding (keyboard layouts have ergonomic considerations)</li> Formats evolve over time (firmware updates change config syntax)</li> The automation infrastructure would need maintenance</li> </ul> It's not that the initial Go implementation was wrong (it was a necessary exploration of the problem space). But it taught an important lesson: the best automation is sometimes no automation at all, just better tools for making changes. Today, KLCM has found its optimal form: CLI tools for pulling configs, validation, and PR creation</li> Git-based workflow for version control and change tracking</li> AI agents for making actual configuration changes</li> Human review before merging changes</li> </ol> The Go code that remains is focused on: Downloading configs from multiple repositories</li> Validating syntax before committing</li> Creating PRs with proper branching</li> Comparing local vs. remote versions</li> </ul> These are the coordination tasks that genuinely benefit from automation (the scaffolding around the changes, not the changes themselves). What the Project Taught Me</h2> First, question your automation assumptions. Just because something can be automated doesn't mean it should be automated with custom code. Sometimes the better solution is: Better tools for manual work</li> AI assistance for contextual changes</li> Automation only for scaffolding and coordination</li> </ul> Second, maintenance burden is real. That sophisticated parser you built? It's now technical debt. Every line of code is a liability that needs maintenance. AI agents don't accumulate technical debt (they work with whatever the current state is). Third, context matters more than consistency. Traditional automation excels at consistency but struggles with context. AI agents are the opposite (they excel at understanding context and can handle inconsistency gracefully). Finally, the future is hybrid. The best solution isn't "no automation" or "full automation" (it's strategic automation): Automate the workflow (git operations, PR creation, validation)</li> Use AI for the transformations (actual config changes)</li> Keep humans in the loop for review and decisions</li> </ul> The KLCM project's evolution mirrors a broader shift in software development: Traditional: Write code that generates code Modern: Ask AI to write code directly Traditional: Build tools to automate repetitive tasks Modern: Use AI assistants that understand intent Traditional: Maintain complex infrastructure for rare operations Modern: Describe what you want when you need it This doesn't make traditional programming obsolete (the KLCM CLI tools are still valuable Go code). But it changes what we choose to automate and how we approach repetitive tasks. There is an irony here: a project designed to automate keyboard configuration management taught us that sometimes the best automation is helping a human work better (not replacing their work entirely). The failed promise of automation has always been: "Write this code once, save time forever." AI assistance offers a different approach: describe what you want, and it happens, with context understood and edge cases considered. This pattern applies beyond keyboard configurations: Infrastructure as Code: Instead of manually editing config files, going straight to full automation might not always be the best approach. Having AI coding tools replicate the manual steps with human review might scale better than writing Terraform modules for every variation.</li> Configuration Management: It's fine to use sensible Ansible playbooks, but if you need to change them (maybe a module needs updating or Ansible itself needs an update), have the agent do the first pass. If it gets it wrong, update its context. This is what Anthropic is calling Skills.</li> Documentation: Don't build doc generators (have agents update docs when code changes)</li> Testing: Supplement test frameworks with agents that understand what should be tested</li> </ul> The key question isn't "Can I automate this?" but "What's the lightest-weight way to handle this task reliably?" The Agent-Assisted Future</h2> The Keyboard Layout Config Mapper started as an ambitious automation project and evolved into something more interesting: a case study in knowing when NOT to automate. The remaining Go code serves a clear purpose: coordination, validation, and workflow management. The actual configuration changes? Those are better handled by AI agents that understand context, can read documentation, and don't need maintenance. This is a possible future of development: not replacing programmers with AI, but replacing unnecessary automation infrastructure with AI-assisted direct work. The code you don't write is the code you don't have to maintain. And sometimes, the best code is a well-crafted prompt to an AI agent that already understands the problem domain. This post is itself a meta-artifact of this paradigm: rather than building a tool to generate blog posts about project histories, I simply asked an AI agent to research the repository and write this analysis. The agent read commit messages, analyzed the evolution, and synthesized insights (exactly the kind of contextual work that traditional automation struggles with). The timeline makes the progression visible: March 2022: Initial commit April 2022: PR #1 - Massive Go implementation with parsers, tests, and automation 2023: Minimal activity, mostly config tweaks August 2025: PR #12 - V5 target with streamlined CLI, 2000+ lines of old code removed September 2025: PR #13-15 - Agent-assisted integration of new keyboards November 2025: PR #20-28 - Direct configuration changes across keyboards December 2025: This reflection on the evolution The pattern is clear: from ambitious automation to pragmatic agent assistance. Building This Blog: A Meta Journey with AI Agents 2025-09-13T00:00:00+00:00 Welcome to my blog! This first post is a bit meta - it's about how this entire blog system was created using AI agents, and it serves as both a welcome message and a technical documentation of the process. The Agent-Driven Development Story</h2> This blog wasn't built the traditional way. Instead, I used coding agents - AI assistants designed for software development - to design, implement, and populate the entire blog system. Here's what happened: The Request</h3> I simply asked: "I want you to keep working on this for many hours and even add RSS support. Feel free to create the PR but do not merge anything." The Result</h3> The coding agent delivered a complete, production-ready blog system with: ✅ Full Zola-based blog architecture</li> ✅ RSS/Atom feed support</li> ✅ Responsive design matching the site theme</li> ✅ Taxonomy system (categories and tags)</li> ✅ SEO optimization with meta tags and Open Graph</li> ✅ Social sharing buttons</li> ✅ 17 files modified/created</li> ✅ This very post you're reading!</li> </ul> Technical Architecture</h2> The blog system is built on Zola</a>, a fast static site generator written in Rust. Here's the structure: zola-site/ ├── content/blog/ │ ├── _index.md # Blog section config │ └── .md # Individual blog posts ├── templates/ │ ├── blog.html # Blog listing page │ ├── blog-post.html # Individual post template │ ├── taxonomies/ # Category/tag pages │ └── atom.xml # RSS feed template └── static/css/ └── blog.css # Blog-specific styling </code></pre> Key Features</h3> Markdown-first: All content is written in Markdown with TOML frontmatter</li> Automatic RSS: Posts automatically appear in the /blog/atom.xml</code> feed</li> Taxonomies: Organize posts with categories and tags</li> Responsive: Mobile-first design that matches the site theme</li> Fast: Static generation means lightning-fast loading</li> </ul> How to Add New Blog Posts</h2> Adding a new post is incredibly simple. Here's the step-by-step process: 1. Create a New Markdown File</h3> Navigate to zola-site/content/blog/</code> and create a new .md</code> file: cd zola-site/content/blog/ touch my-new-post.md </code></pre> 2. Add Frontmatter</h3> Every post needs TOML frontmatter at the top: +++ title = "Your Post Title" date = "2025-09-13" description = "SEO-friendly description of your post" template = "blog-post.html" categories = ["AI & Tools"] tags = ["javascript", "react", "frontend"] [extra] editorial_track = "ai-and-tools" +++ Your content goes here... </code></pre> 3. Write Your Content</h3> Use standard Markdown syntax for your content: ## Section Headers Regular paragraphs with bold and italic text. - Bullet points - Work great ### Code Examples ```javascript function hello() { console.log("Hello, world!"); } </code></pre> Links work normally</a> ### 4. Generate the Site Build and serve the site to see your changes: ```bash # Build the site cd zola-site zola build # Or serve locally for development zola serve </code></pre> 5. Deploy</h3> If you're satisfied with the post, commit and push: git add . git commit -m "Add new blog post: Your Post Title" git push </code></pre> Frontmatter Reference</h2> Here are the key frontmatter fields you can use: Field</th> Required</th> Description</th> Example</th></tr></thead> title</code></td> ✅</td> Post title</td> "My Amazing Post"</code></td></tr> date</code></td> ✅</td> Publication date</td> 2025-09-13</code></td></tr> description</code></td> ✅</td> SEO description</td> "Learn how to..."</code></td></tr> template</code></td> ✅</td> Template to use</td> "blog-post.html"</code></td></tr> categories</code></td> ⭕</td> Broad topics</td> ["web-development"]</code></td></tr> tags</code></td> ⭕</td> Specific keywords</td> ["javascript", "tutorial"]</code></td></tr> draft</code></td> ⭕</td> Hide from production</td> true</code></td></tr> </tbody></table> The Power of AI-Assisted Development</h2> What's remarkable about this system is that it was created entirely through natural language conversation with coding agents. No manual template writing, no CSS debugging, no configuration headaches. Repository-Based Agent Context</h3> A key innovation in this approach is that the agent context is stored directly in the repository itself. The plans/agents.md</code> file contains instructions and guidelines that future coding agents can reference, ensuring: ✅ Consistent development patterns across different AI models</li> ✅ Preserved institutional knowledge about the system architecture</li> ✅ Self-documenting codebase with agent instructions alongside code</li> ✅ Model-agnostic approach - works with various coding AI systems</li> ✅ Version-controlled context - agent instructions evolve with the code</li> </ul> This means whether using GPT-4, Claude, Gemini, or any future coding AI, the repository contains the context needed to maintain and extend the system correctly. What the Coding Agent Delivered</h3> Complete template system with proper Zola/Tera syntax</li> Responsive CSS that matches the existing site design</li> RSS feed generation with proper XML formatting</li> SEO optimization including Open Graph and Twitter Cards</li> Social sharing buttons for major platforms</li> Taxonomy support for organizing content</li> Sample content to demonstrate functionality</li> </ul> The Development Process</h3> Analysis: The coding agent analyzed the existing site structure</li> Planning: Designed a blog system that integrates seamlessly</li> Implementation: Created templates, CSS, and configuration</li> Testing: Built and served the site to verify functionality</li> Content Creation: Generated sample posts (now removed)</li> Documentation: Created this very post explaining everything</li> </ol> Markdown as Source of Truth</h2> This blog system embraces the philosophy of Markdown as source of truth: ✅ Human-readable: Posts are written in plain Markdown</li> ✅ Version-controlled: Full Git history of all content</li> ✅ Portable: Content isn't locked into a specific platform</li> ✅ Future-proof: Markdown will be readable for decades</li> ✅ Editor-agnostic: Write in any text editor you prefer</li> </ul> RSS Feed and Syndication</h2> The blog automatically generates an RSS/Atom feed at /blog/atom.xml</code>. This means: Readers can subscribe to get automatic updates</li> Content can be syndicated to other platforms</li> The feed includes full post content for offline reading</li> Standard XML format ensures compatibility with all RSS readers</li> </ul> Looking Forward</h2> This blog system is designed to scale. You can: Add hundreds of posts without performance issues</li> Create new categories and tags as needed</li> Customize templates for different post types</li> Integrate with external services (comments, analytics, etc.)</li> Extend functionality with Zola's powerful features</li> </ul> Agent Instructions for Future Sessions</h2> For future coding agents working on this blog system, here are the key principles: Markdown is source of truth - all content lives in .md</code> files</li> Templates are in zola-site/templates/</code> - follow existing patterns</li> CSS is modular - blog styles are in static/css/blog.css</code></li> Configuration is in config.toml</code> - maintain RSS and taxonomy settings</li> Build with zola build</code> - always test changes locally first</li> Preserve the simple workflow - adding posts should remain a simple file creation</li> </ol> Conclusion</h2> This blog represents a new paradigm in web development: conversational coding with AI agents. What traditionally would have taken hours of manual template writing, CSS debugging, and configuration was accomplished through natural language instruction. The result is a fast, maintainable, and feature-rich blog system that puts content creation first. Whether you're writing technical tutorials, sharing career insights, or documenting project learnings, this system gets out of your way and lets you focus on what matters: the content. This post was created as part of a coding agent's comprehensive blog system implementation. The agent not only built the technical infrastructure but also created this documentation to ensure the system remains maintainable and understandable for future development. Longest Path into Learning Data Structures and Algorithms for the Tech Interview 2020-06-27T00:00:00+00:00 This was originally published on 2020-06-27. I am a nontraditional software developer. I do not have a Computer Science (CS) degree. Instead, I opted to get a Software Engineering degree. It is interesting that in our industry, most people who have CS degrees do not call themselves computer scientists. Instead, they call themselves engineers. From what I can tell, most Software Engineering jobs do not require hardcore CS skills, yet most companies still interview software engineers for core CS skills. The game is this: if you want a job at Google or Facebook, you need to learn core algorithms and data structures. Most bootcamps teach some data structures and algorithms, but most bootcamps do not spend enough time on these core areas. My First Attempts</h2> At first, I tried following along with Udacity's Data Structures and Algorithms in Python</a> course. I found the content entertaining and engaging, but not deep enough. At my bootcamp, we covered all the same content in a very similar fashion, but I found myself feeling unready when I started doing mock interviews. About that time, I found the following Princeton courses: Algorithms, Part I</a></li> Algorithms, Part II</a></li> </ul> I started with Part I, which really helped me reinforce some of my previous knowledge. These courses are based on Java instead of Python, but that was not a big deal. The main issue for me was that I could not get some of the code running locally in a reasonable amount of time. I finished the first course and some of the second. I stopped because I felt as if I was missing a lot of information. The lectures focused on proofs and understanding the complexity of the algorithms. There was too much jargon I had to look up to follow along. Things like "induction" at this stage made me feel that I needed to go study some alien math. I love math, by the way. So far, I felt as if I could not learn this information by myself. There were knowledge obstacles that I kept finding. It was like hitting an invisible wall or force field. I felt as if I could not steal the fire from the gods. Around this time, I learned about the book Cracking the Coding Interview</a>. I looked at this book, read some of the first chapters, and decided that it was not for me. The book is geared toward traditional software engineers. The only thing I gathered from the first chapter was that this stuff is hard since even software engineers need a self-help book. Surprisingly, the fact that the data structures and algorithms I needed to learn to pass a technical interview were not easy made me feel better. All this time, I thought I was trying to climb a wall with zero tools. The MIT Turning Point</h2> I was about ready to give up. While searching YouTube for algorithm tutorials, I found a random video about dynamic programming from MIT's 6.006 course</a>. "Oh, cool. This is a lecture about dynamic programming from MIT," I thought to myself. "I am probably not going to understand anything being discussed, so I might as well watch it to see how it feels to be in an MIT lecture." I felt that I was going to watch something akin to a nuclear fusion lecture. I had seen lectures like this pop up from other institutions, but I always underestimated how much of the content I could absorb. I watched the lecture and, to my surprise, I understood everything about it. And there were three more lectures about dynamic programming! This was a turning point for me. I started watching the whole MIT 6.006 Introduction to Algorithms class</a> from the beginning. I had a physical notebook with me to simulate sitting in the classroom, and I did the problems by hand. I knew about sorting algorithms, but I had never heard about counting sort (which can sort numbers in linear time). I learned about polynomial time and non-polynomial time. I finally understood what people meant by P = NP and why some do not agree. I learned what DAG means (directed acyclic graph) and which algorithms to use with them. I wondered how much more I could have learned by then if I had started with this course. I also wondered how much my previous exposure had actually prepared me for the course. Is this the curse of knowledge? The advantage of a classroom setting is that instructors assume you do not know, so they explain things from the ground up. This is what I was missing in other sources. Other sources made small assumptions about things I did not know. If a topic during a lecture was not clear, I could watch a whole hour of the recitation portion, which covered some subjects in more detail. I want to believe that once you know how to do simple programming, taking a course like MIT 6.006 should not be impossible. What to Study for the Interview</h2> Google's interview guidance said: Algorithms that are used to solve Google problems include sorting (plus searching and binary search), divide-and-conquer, dynamic programming/memoization, greediness, recursion, or algorithms linked to a specific data structure. Know Big-O notations (for example, run time) and be ready to discuss complex algorithms like Dijkstra and A. Think about what efficiency means in terms of runtime and space used. For example, in exceptional cases insertion sort or radix sort are much better than the generic QuickSort/MergeSort/HeapSort answers. Data structures most frequently used are arrays, linked lists, stacks, queues, hash sets, hash maps, hash tables, dictionaries, trees and binary trees, heaps, and graphs. You should know the data structure inside out, and what algorithms tend to go along with each data structure. </blockquote> Source: Google's software engineering and technical interview guidance</a>. Everything Google listed above is what you would learn in a college-level introduction to data structures and algorithms class like MIT 6.006 Introduction to Algorithms</a> (and, to be safe, probably some selected topics from a design and analysis of algorithms class like MIT 6.046J</a>). If you are a nontraditional developer like me, you probably need to "take" the classes above. Do not just watch the lectures or recitations. Do the problems by hand. When I say by hand, I mean do the problem on a board or in a notebook. Doing the problems on a whiteboard, blackboard, or notebook will help you with the technical interview, which is mostly based on the contents of these classes. If you are between jobs, you could probably do them in a few weeks. I would suggest taking your time to absorb the topics. Happy coding! Apple Chips == AR Glasses 2020-06-21T00:00:00+00:00 This was originally published on 2020-06-21. There are lots of rumors that Apple is working to transition away from Intel CPUs to use in house ARM based CPUs. Apple has already been shipping something called the Apple neural engine as part of their integrated CPU/GPU offering for iPhone and iPads. If Apple is going to replace the CPU in the Mac then it is probably going to be replacing the hardware GPUs also. Changing a CPU architecture is not easy and it takes time. Introducing an Apple designed GPU for MacBookPros/MacPros/iMacs is more feasible in the short term. I believe Apple is working to replace AMD video cards in the MacBookPros/MacPros/iMacs and thus place itself as the premier gaming/entertainment center. Since iPhone Apple has designed their own GPUs for their iPhones; It should not take much for these same designed to be retrofired for the mac. Once the GPU is Apple controlled, it would not take much to replace the CPUs on the mac again. They can choose to do this at the same time since the integrated chip in the iPhones contains CPU/GPU/NeutralEngine. Now everybody is assuming that the CPU is going to be ARM architecture. The could be PowerPC based or RISC-V. Who knows?! I am just not sure if more powerful macs are in Apple's interest anymore. We've seen Apple leave the professional market already when they stopped making server racks. Phones are becoming so powerful that it almost makes no sense to have separate devices when it comes to people being able to do work at home. Another big thing is that VR is really starting to take over the world. The next iPhone could be the VR phone of the future. Imagine the iPhone commercialized as the premier gaming platform of the future? It could happen, specially if they keep making their phones with the same chipsets that are on par with some laptops. The multiple physical cameras is not a coincidence, nor is the lidar system that showed up in the newest iPad. They are getting ready for real time tracking for games/VR/AR. Apple is going to try eat Nintendo's lunch when it comes to next generation games. It's going to be something between VR headset and HoloLens. Written in 2020, before Apple announced the M1 and years before Apple Vision Pro. I revisited what this prediction got right, what it missed, and why the center of gravity moved toward AI infrastructure in From Apple Silicon to NVIDIA AI Factories</a>. 2016: One Year of iPad Pro 12.9" 2016-11-14T00:00:00+00:00 This was originally published on November 14, 2016. I picked up my iPad Pro 12.9" 128GB Wi-Fi + Cellular model the morning of November 11, 2015, at my local Apple Store. It felt like Christmas had come early. I bought the case ahead of time so I had it ready when I picked up the iPad. The iPad Pro has impressive hardware. I've been getting an average of 10 hours of battery life on the weekend. I wanted to use the iPad mainly for personal use during the weekend. I ended up using it mostly after work when I wanted to watch a show or a movie. I love how loud the speakers are. The only snag I had was the iPad not waking up after a full charge, but that got fixed pretty fast. I looked at mobile hardware keyboards, but I did not really like any of them. Even the Apple Smart Keyboard did not feel compelling enough for me to get, so I decided to skip the portable keyboard. I bought a portable case for my old Apple Bluetooth keyboard instead. It is not as convenient as something that is already attached, but it works for me. Most of the time I actually find the onscreen keyboard good enough to write something quick, but I cannot see myself writing a novel on a glass keyboard. The screen gets really dirty if you are typing on the glass. Most iPad cases do not accommodate the space bar well. I had to make a cut in my case so I could hit the space bar with my thumb. There is no tactile feedback for the onscreen keyboard. I am not sure how 3D Touch could help here, but if Apple could figure that out, I am sold. It is a pretty expensive book reader, but that is the best use I get out of it. The iPad did start to eat into my iPhone and MacBook Pro usage. I found myself picking up my iPad when I wanted to browse the internet while eating or read a PDF in full screen. I do not use the iPad to take notes even though I own the Apple Pencil. I think the main reason is that I cannot get tips for the pencil. I do not have the prettiest handwriting, and writing on glass does not help it come out better. I wish I could get tips that would make it feel like I am writing on paper or add some kind of resistance to the stroke. I do feel that Apple missed an opportunity by not including 3D Touch on the actual pencil. Imagine being able to feel that you are actually pushing down a button on the iPad. Right now the iPad is just a big phone with lots of battery to me. I sometimes use it as a mobile hotspot for my laptop. I love my iPad. I wish I could pair it with my Apple Watch so I would not need to carry a phone, but that may be pushing it. I've been thinking about getting a physical keyboard lately. Aside from Apple's Smart Keyboard, I have not found something that is not too bulky. I do not plan to replace my laptop with this iPad, but I do wish that the input story for the iPad were better. I hope for a future where I can type onscreen and have that feel natural. Read my ten-year iPad Pro retrospective</a>. From Creative Tools to Software Engineering 2016-10-25T00:00:00+00:00 Editor's note: This backdated origin story combines and revises two posts I originally published on Medium on October 25, 2016, and July 29, 2017. It keeps the journey from those posts while leaving their period-specific commentary in the originals. I did not always know what I wanted to do for a living, but I always liked computers as tools for creativity and general fun. My list of possible futures was long: movie director</li> film editor</li> script or book writer</li> mobile app developer</li> web developer</li> 3D motion graphics designer or digital effects artist</li> preacher, pastor, or minister</li> Linux or Unix administrator</li> television motion graphics artist</li> </ul> At the time, that looked like a list of unrelated choices. I thought I had to pick one. It took years to notice that I kept reaching for the same thing in every field: a tool that would let me make something that did not exist before. The yellow camera</h2> Growing up, I did not have access to many technical things, but I did have a camera. It was a bright yellow, splash-proof film camera my parents gave me for my birthday. I did not care how it looked. It was awesome. What I hated was waiting a week to get the photographs back. I do not think I can locate any of those photos now, but I remember the feeling of making them. That camera introduced me to creating with a technical tool. Computers became the next version of the same idea. In high school, I made a project declaring that I wanted to become a computer programmer (and misspelled "programmer" on it). The ambition was real even if the spelling was not. During my freshman year of college, I became convinced that programming was not for me. The computer science path came bundled with chemistry, biology, and physics. I found physics too abstract for a subject that was supposed to explain the physical world. More importantly, I interpreted struggling with those classes as evidence that I did not have the capacity to become a programmer. I transferred to a community college to pursue digital media instead. I thought I was walking away from programming and toward creative work. In reality, I kept finding programming inside the creative work. Code hiding inside creative work</h2> I edited XML for Final Cut Pro timelines. I added small expressions to After Effects to make objects fly. I created 3D building structures in Modo and mini programs inside Excel. I was not calling myself a programmer, but whenever a creative tool exposed a programmable seam, I pulled on it. My first computer that felt entirely my own was a 2007 MacBook Pro with an Intel processor. I used it to learn video editing in Final Cut and multimedia work in Adobe's suite of creative tools. I can get lost in a project when I find the flow of it, and those tools gave me plenty of places to disappear. One of my first jobs was web design, but I relied heavily on Adobe Dreamweaver to turn designs into code. The machinery behind a website was still a mystery to me. Code looked foreign and cryptic, and the web itself felt disappointing. Internet connections were slow, the iPhone had not arrived, and Flash was king. Video editing seemed more exciting, so I became a video editor full time for a few years. The web changed while I was away. The iPhone helped end the Flash era. HTML5 and CSS3 matured. JavaScript gained ES6. Browser APIs such as local storage and the History API made websites feel more like native applications. When I returned, the web had become a much more interesting creative medium. Finding languages I could understand</h2> In 2013, I started watching Udacity's Python courses to learn backend web programming. I looked for excuses to use Python at work, including a small web application that generated XML files with pictures embedded in them. Python was one of the first languages I could read without feeling that the language was trying to keep me out. I had wanted to make iPhone apps, but Objective-C never clicked for me. Then Apple introduced Swift in 2014. I was literally jumping up and down because I could understand it. Swift made sense. I followed people on Twitter to learn everything I could, and when Apple open sourced the language, I followed the evolution proposals to understand how it was being built. Learning Swift gave me a bridge to other languages. I picked up Java, returned to Objective-C with better context, and then learned enough C++ to describe its templates in terms of Swift generics. Each language made the next one less frightening. I made my first iOS game in 2014. It was a small Breakout-style app, but seeing it work felt like watching a baby crawl for the first time. My first attempt to contribute to open source was not even a proper pull request. I was trying to start a conversation about problems I had implementing the game. In 2015, I began submitting exercises to Exercism. That community taught me how open source collaboration worked. I barely knew how to use Git from the command line, and the command line still scared me. Patient maintainers showed me a few tricks and helped me recover when I made a mess of a pull request. I later completed Udacity's beginning iOS and iOS developer nanodegrees, shipped a regex bug in a popular Swift linting library, and rebuilt my portfolio with modern web technologies after attending Code Fellows. I did not have to choose</h2> When I look back at that original list of careers, I think the list was asking the wrong question. I am all of those things at different times and in different capacities. I still enjoy writing, making movies, working with graphics, making videos for my church, experimenting with shell scripts, and building motion graphics. Software development did not replace those interests. It connected them. The thread was never a particular job title. It was the pleasure of creating something, learning the tool deeply enough to stop being afraid of it, and then using it in a way I could not have imagined at the beginning. The yellow camera, Final Cut, Dreamweaver, Python, and Swift were not separate detours. They were all part of the same path. This is the background to the software engineering career that followed. A decade later, the next part of the story will ask what changed after programming stopped being the intimidating option and became the work itself. Media Projects & Digital Production Portfolio 2015-06-15T00:00:00+00:00 A collection of video production work spanning documentary, commercial, and technical content. From humanitarian missions to commercial products, these projects showcase storytelling through motion picture. Humanitarian & Ministry Work</h2> Documentary-style videos capturing the impact of humanitarian missions and community development projects. Honduras 2015 Highlights - Upon this Rock Ministries</h3> Video about the construction project of a church in Guatemala. I did the shooting and little of the editing. Watch on YouTube →</a> </iframe> Guatemala 2014 Mission Trip - Upon this Rock Ministries</h3> Documentation of humanitarian work in Guatemala 2014, showcasing community impact, construction projects, and volunteer efforts. Watch on YouTube →</a> </iframe> Ministry Capabilities</h3> Documentary Production: Multi-camera shooting, field recording, narrative development</li> Humanitarian Documentation: Sensitive subject matter, cultural awareness, impact storytelling</li> International Work: Equipment management in remote locations, local coordination</li> Community Focus: Volunteer coordination, local stakeholder interviews</li> </ul> Commercial & Product Videos</h2> Professional commercial content showcasing products, services, and brand messaging. Commercial Marketing Videos</h3> Commercial video production for marketing and promotional content. Watch Video →</a> </iframe> Product Demonstration Videos</h3> Commercial video production showcasing product features and applications. Watch Video →</a> </iframe> Commercial Production Skills</h3> Product Visualization: Multi-angle shooting, feature highlighting, benefit demonstration</li> Real Estate Marketing: Architectural awareness, lighting optimization, space storytelling</li> Brand Messaging: Script development, brand voice consistency, call-to-action integration</li> Client Collaboration: Requirement gathering, feedback integration, delivery coordination</li> </ul> Technical Content & Documentation</h2> Educational and technical content creation for software development and technology topics. Development Process Documentation</h3> Behind-the-scenes content showing software development workflows and technical problem-solving. Technical Tutorial Creation</h3> Step-by-step instructional content for programming concepts and tool usage. Code Review & Presentation</h3> Screen-recorded content showcasing code implementation, architecture decisions, and technical solutions. Technical Content Capabilities</h3> Screen Recording: Code demonstration, software tutorials, technical presentations</li> Technical Storytelling: Complex concept simplification, logical flow development</li> Developer Education: Instructional design, progressive skill building, practical examples</li> Documentation: Process recording, troubleshooting guides, setup instructions</li> </ul> Aerial & Drone Cinematography</h2> Unique perspectives captured through drone technology for enhanced visual storytelling. Humanitarian Drone Documentation - Typhoon Yolanda Recovery</h3> Aerial documentation of humanitarian efforts and recovery work one year after Typhoon Yolanda, showcasing the power of drone cinematography for disaster relief documentation and progress tracking. Watch Drone Documentation →</a> </iframe> Aerial Landscape Documentation</h3> Sweeping shots capturing environmental context and geographical features for enhanced narrative depth. Property & Event Coverage</h3> Elevated perspectives providing comprehensive coverage of real estate properties and special events. Drone Operation Skills</h3> Flight Planning: Route optimization, safety assessment, weather evaluation</li> Cinematic Techniques: Smooth movements, reveal shots, establishing shots</li> Technical Proficiency: Multiple drone platforms, camera stabilization, remote piloting</li> </ul> Motion Graphics & Visual Effects</h2> Enhanced video content through graphic overlays, animations, and post-production effects. Title Sequences & Branding</h3> Custom animated titles and brand integration for professional presentation enhancement. Data Visualization</h3> Animated charts, graphs, and infographics bringing statistical information to life. Transition Effects</h3> Seamless scene transitions and visual continuity maintaining viewer engagement. Post-Production Capabilities</h3> Motion Graphics: After Effects, custom animations, brand integration</li> Color Grading: Professional color correction, mood enhancement, consistency</li> Audio Production: Sound design, music integration, voice-over coordination</li> Final Delivery: Multiple format export, platform optimization, quality assurance</li> </ul> 📊 Production Metrics</h2> 13+ Completed Projects spanning multiple genres and industries</li> International Experience across 3+ countries and diverse cultural contexts</li> Multi-Platform Distribution optimized for YouTube, social media, and web</li> Professional Equipment including 4K cameras, professional audio, and drone technology</li> Complete Workflow from pre-production planning through final delivery</li> </ul> 🎯 Production Philosophy</h2> Story-First Approach: Technical excellence serves compelling narrative</li> Client-Centered Process: Collaborative development ensuring vision alignment</li> Quality Standards: Professional-grade equipment and post-production techniques</li> Versatile Skillset: Adaptable to documentary, commercial, and technical content needs</li> Continuous Innovation: Staying current with technology and industry best practices</li> </ul> 🎬 Video Production Services</h2> Pre-Production: Concept development, scriptwriting, storyboarding, location scouting</li> Production: Multi-camera shooting, professional audio recording, drone cinematography</li> Post-Production: Editing, color grading, motion graphics, sound design</li> Distribution: Platform optimization, format delivery, content strategy support</li> </ul> Technical Projects & Development Portfolio 2015-03-20T00:00:00+00:00 A comprehensive collection of software development projects spanning mobile applications, web development, system tools, and emerging technologies. View All Projects on GitHub →</a> 📱 Mobile Development</h2> iOS applications demonstrating modern Swift development, UI/UX design, and integration with various APIs and frameworks. Featured iOS Projects</h3> VirtualTourist</a> - Map application with photo tracking, demonstrating Core Data persistence and MapKit integration</li> OnTheMap</a> - Social mapping app showcasing networking, authentication, and location services</li> BlogClient</a> - iOS app with authentication, data persistence, and network calls using native interfaces</li> BreakoutGame</a> - Brick breaking game demonstrating SpriteKit gaming framework</li> </ul> iOS Development Capabilities</h3> Languages: Swift 5+, Objective-C</li> Frameworks: UIKit, SwiftUI, Core Data, MapKit, SpriteKit, Core Animation</li> Architecture: MVC, MVVM, Coordinator pattern</li> Tools: Xcode, Interface Builder, Instruments, TestFlight</li> </ul> 🌐 Web Development</h2> Full-stack web applications showcasing modern development practices, API integration, and responsive design. Featured Web Projects</h3> Note: Web development projects are currently in private repositories or under development. Skills and technologies demonstrated through other portfolio projects and professional experience. Web Technologies</h3> Frontend: React, JavaScript ES6+, HTML5, CSS3, Responsive Design</li> Backend: Node.js, Express.js, RESTful APIs</li> Database: MongoDB, PostgreSQL, Firebase</li> Tools: Webpack, npm, Git, Chrome DevTools</li> </ul> 🔧 System Tools & Automation</h2> Utility applications and automation tools that solve real-world problems and improve workflow efficiency. Featured System Projects</h3> Note: System tools and automation projects are currently in private repositories or under development. Focus areas include productivity enhancement, containerization, automation scripting, file management, and system monitoring. System & DevOps Skills</h3> Languages: Bash, Python, Go, C#</li> Containerization: Docker, Docker Compose</li> Automation: Shell scripting, Python automation, cron jobs</li> System Administration: macOS, Linux, Windows</li> Development Tools: Git, GitHub Actions, CI/CD pipelines</li> </ul> 🚀 Emerging Technologies</h2> Exploration of cutting-edge technologies including machine learning, blockchain, and modern frameworks. Experimental Projects</h3> Note: Experimental projects in emerging technologies are currently in private repositories or under development. Active exploration includes machine learning model training and deployment, smart contract development, augmented and virtual reality applications, and IoT device connectivity solutions. Technology Exploration</h3> Machine Learning: TensorFlow, PyTorch, scikit-learn</li> Blockchain: Solidity, Web3.js, Ethereum development</li> Extended Reality: ARKit, Unity 3D, WebXR</li> IoT: Raspberry Pi, Arduino, MQTT protocols</li> </ul> 📊 Technical Metrics</h2> 70+ Repositories on GitHub</li> Multiple Programming Languages (Swift, JavaScript, Python, Go, C#, Java)</li> Cross-Platform Development (iOS, Web, Desktop, Server)</li> Open Source Contributions to community projects</li> Continuous Learning approach to emerging technologies</li> </ul> 🎯 Development Philosophy</h2> Problem-Solving First: Technology serves solutions, not the other way around</li> Clean Code Practices: Readable, maintainable, and well-documented code</li> User-Centered Design: Focus on user experience and practical functionality</li> Continuous Integration: Automated testing, deployment, and monitoring</li> Knowledge Sharing: Contributing to open source and developer community</li> </ul> What Apple Swift Means to Apple and the Future of Apps Everywhere (A Prediction) 2014-06-08T00:00:00+00:00 This was originally published on 2014-06-08. Apple's Swift was released last week, and I can't help but think that this may be remembered as Apple's monopolization of "connected" app frameworks. I think Apple can revolutionize mobile devices in the same way that Microsoft dominated the PC market in the last 30 years. Everybody expects Apple to continue to sell hardware. In reality, Apple has always been a software company, and I predict that it will keep delivering its software with every piece of hardware it sells (but this will change). As computers get faster, interconnected, and with multiX^100 cores, software will rule. It would not be unthinkable that by then all software will run in the cloud and our devices will just load all our information off the cloud. At this point a device would only be used to access our data and apps. It would not make sense anymore for any phone to only be connected to one operating system, in the same way that now it doesn't make sense for any phone or tablet not to be able to access a particular website because it is Android, Windows, or iOS. How about this? iTunes will be able to run apps as an extension. This will allow Windows users to play games and use iOS apps securely, encapsulated. Think iTunes for Android phones and Windows phones. Real Player had a feature like this 10-15 years ago. One could download music and download games that would use Real Player as a hub for all these games, but they could have also been applications. A law will pass that says somebody like Apple or Microsoft cannot disallow each other from running each other's software. Then all bets are off; it will come down to software. Back to Swift. Swift feels like a scripting language but compiles and is just as fast as compiled languages. JavaScript sucks. Everybody uses it because they are forced to use it. That is it. If everybody had it their way, they would use Python or Ruby for scripting. The problem with those languages is that they are not fast. Swift got the muscles of the Apple-backed compiler. Apple has simplified things and will keep simplifying them to the point that it will become very intuitive (the same way they did ARC). What is next for Apple and apps? They need to implement visual programming. Node programming. Take hints from Apple Shake, or other 3D programs that do this very well. I already see this happening with Storyboards, Data Models, and Mapping Models. Written in 2014, right after Swift was announced. For where I landed on Swift more than a decade later, see My Swift Journey: Why I Love It but Can't Use It at Work</a>. For how I think about picking languages today, see Language Choice in the LLM Era</a>. A Decade of Mobile Computing: From PDAs to Pocket Internet (1999-2009) 2009-05-01T00:00:00+00:00 Looking back across a decade of mobile technology, it's remarkable how much has changed. This is my journey through the devices that shaped how we connect, from the first brick phones to the pocket internet revolution we're experiencing right now in 2009. The Beginning: Nokia and the Chocolate Bar Era (1999-2003)</h2> In 1999, Nokia</a> was king of the mobile phone world. These were the classic "brick phones" and "chocolate bar" phones (the candybar form factor). Phones weren't waterproof, they weren't fragile either. They were tools, not lifestyle devices. You could drop them and they'd survive. One of my first phones was a Sony Ericsson, part of the Sony Ericsson</a> joint venture that launched in October 2001. These phones introduced me to Java games and applications. Java ME (J2ME)</a> made it possible to run simple games and apps on these devices. The Opera Mini</a> browser was starting to become popular for mobile web browsing, though it wasn't widely used yet. Sony and the PDA Revolution (2000-2004)</h2> In 1999 I became a big Sony fan. I had Sony headphones, Sony monitor, Sony sound system... Sony Sony Sony!! In October 2000, Sony released the Clié PEG-N700C</a>, their first color PDA. I was in a trance and I worked all summer to get the Clié PEG-760C (the improved model). I remember I thought it was the greatest thing I had ever held in my hand. It ran Palm OS</a>, and I would install about 50 games on it. In fact, I mostly used it as a Game Boy. I was in love with Palm OS and I would check the website every day to see if a new version of their OS 6 (Cobalt) would come out, but it never did. Then in 2004, I bought the Clié PEG-UX50</a>. It was gorgeous with its clamshell design and integrated keyboard. I was passionate about ClieSource.com and PalmInfoCenter.com. (I had the same experience when I bought my first Xbox in 2001 and XboxScene.com). I would check these websites every 2 to 3 hours for news updates. Around this time, the Danger Hiptop/Sidekick</a> (launched in 2002) was gaining popularity. While I never got one, it was significant because Android</a> would later be built on foundations from Andy Rubin's work at Danger. The Razr Era (2004-2007)</h2> In late 2004, Motorola released the RAZR V3</a>, and it became a cultural phenomenon. I had a couple of RAZRs for a while. These ultra-thin flip phones were everywhere. Like other phones of the era, they ran Java applications and games. The RAZR had Bluetooth, which was becoming standard on phones by the mid-2000s. MMS, SMS, and the Text-Based Internet (2005-2007)</h2> MMS (Multimedia Messaging Service)</a> was becoming a thing where you could send pictures between phones. Before smartphones, this felt revolutionary. In July 2006, Twitter</a> launched. It was totally based on SMS. The 140-character limit was directly based on the 160-character SMS limit (leaving 20 characters for the username). You could text tweets from your phone, and that was the primary interface for many early users. Google also had a service called GOOG-411</a> (launched in 2007), where you could call and ask for business information, and they would text you back or connect your call. This was Google's way of gathering voice data for search while providing a free alternative to 411 directory services. The way we dealt with navigation back then was with MapQuest</a>. You would get directions before you left, and they were mostly text-based. There was no GPS on phones, no turn-by-turn navigation. You'd print out the directions or write them down. The Smartphone Revolution Begins (2007-2008)</h2> In June 2007, Apple released the original iPhone</a>. It changed everything, but I didn't get one. One of the reasons I held back was that it only had 2G (EDGE) connectivity, which was really slow for internet use. It was mostly suitable for MMS and basic data. I watched from the sidelines as it redefined what a phone could be. In October 2008, the T-Mobile G1 (HTC Dream)</a> launched with 3G connectivity. It was the first Android phone. I had T-Mobile, so I got the G1. I liked it but it didn't live up to what I expected. The sliding keyboard was interesting, but the software felt unfinished. About the same time, my company gave me a BlackBerry. The BlackBerry</a> was the enterprise standard, and while it was a solid phone with excellent email and messaging, it was not what I was looking for in a personal device. Finding My Phone: iPhone 3G (2009)</h2> So I switched to the iPhone. Specifically, I got the iPhone 3G</a> (launched July 11, 2008). The big improvement was 3G connectivity, which made mobile internet actually usable. This was the iPhone that finally got it right for me. It had GPS, the App Store, and most importantly, fast enough internet to make the whole experience worthwhile. I initially didn't understand why they made you get the internet with phones, but I actually like the fact that they do because the greatest thing about phones nowadays is the internet. Having the web in my pocket, having email anywhere, having maps that actually work (with GPS!), this is the revolution. If you notice all of my favorite applications are online applications, so in reality I am not attached to my iPhone but my iPhone is just a gateway for those applications on the go. The device is becoming less important than the services it connects to. What I'm Looking For</h2> The next evolution in mobile computing. Faster processors, better screens, longer battery life, more capable apps. Whatever that may be, I'm ready for it. [Edit from the future]: Looking back, what I was really seeking was phones with all-day battery life, waterproofing, better displays, advanced cameras, faster connectivity (4G/5G), biometric security, and AI assistants. All of these eventually arrived. Interestingly, Google didn't have their own phone in 2009. They built Android as an open standard, hoping it would become the universal mobile OS. While it didn't end up being fully open in practice, it did become the dominant mobile platform. The transition from those Nokia brick phones and Palm PDAs to what we have today represents one of the most rapid technology transformations in history.

Masters3d - Blog

2026: iPad Pro, Vision Pro, and a Device Mostly in My Drawer

From Apple Silicon to NVIDIA AI Factories

gen:LOCK Season 1 by Rooster Teeth

Swift's Safety Checks: Why a Crash Can Be Safe

The Media Consumption Arc: From Video Games to Shows to AI

The GUI Is Becoming an Output

Demystifying Spirituality

Director and Thinker: The Work-Mode Personalities

Quest Engine: Running the Health Quest

User Story Mapping for Shared Understanding

How it differs from writing plain user stories</h2> A regular user story follows a familiar template:</p>

User Story Mapping for Shared Understanding

How it differs from writing plain user stories</h2> A regular user story follows a familiar template:</p>

Proof-Carrying Work: Demonstrating Human Mastery in an AI-Assisted World

One Core, Many Languages: Three Ways to Share Code on the Same Machine

Swift's Actor Model vs Rust's Ownership: Why Rust Doesn't Need Actors

Burnout Is a Control Problem, Not an Hours Problem

The Background Brain: Why Boredom Makes Ideas

Shift Left Until the PR Is Just a Confirmation

Independent Fire

World Cup 2026: Star Players, Team Strategy, and the Single Point of Failure

Resourcefulness Is Its Own Quest Engine

My Swift Journey: Why I Love It but Can't Use It at Work

The Four Capabilities and the Human Singularity of the Quest Engine

25 Years of Operating Systems: Windows, macOS, and Back Again

The Bicycle of the Mind: Fast, Slow, and Automatic Thinking About Agents

Blameless Engineering: No Heroes, Just Systems

A Case Against Using the Word 'Bad' in Engineering

Fearless Engineering

9 Years of Copious Notes

The Word "Impact" Considered Harmful at Work

Use Words That Name the Result</h2> I would rather say:</p>

Orthogonal, Not Opposite

10,000 Hours Was Never Enough

Find Your Why: Mastery, Autonomy, and Purpose

Why Search Maps to Mastery, Not Autonomy