DEV Community: Regis Wilson

Wilson's Laws of Branching

Regis Wilson — Tue, 03 Nov 2026 18:32:03 +0000

A language almost exactly like yours, except it doesn’t like keeping secrets

Every conditional contains at least two outcomes. Writing down only one does not eliminate the other. It merely delegates its interpretation to the next person.

Usually that person is you, six months later, during an incident.

Wilson’s Law of Branching:

Every branch has an alternative. An alternative that is not expressed becomes a secret, and every secret eventually acquires a maintainer.

This is not a mathematical law. Mathematical laws have proofs. This one has deployment history.

The original Wilson Else proposed making certain missing alternatives visible, particularly inside nested conditionals. But requiring an else everywhere would confuse acknowledgment with punctuation. Prohibiting else everywhere would confuse flat code with complete reasoning.

Perhaps the problem is not whether we wrote else. Perhaps the problem is whether we told the truth about the decision. The original Wilson Else classified the original problems as "lies" versus "truths" but this essay attempts to soften the message as "secrets" vs. "truths". Secret is still a pejorative word but it is less pejorative than lies.

To investigate, we will invent a language almost indistinguishable from a normal programming language. Its distinguishing feature is that it gets uncomfortable when you appear to know something you have not told it.

1. First, declare what kind of decision this is

Ordinary languages let one keyword perform several jobs.

An if might mean:

Do this only when appropriate.
Reject this input and stop.
Choose between two outcomes.
Start a priority-ordered sequence of alternatives.
Conceal a question nobody answered.

Our language distinguishes three forms:

Construct	Meaning
`if`	Perform a conditional action, or terminate through a guard. No `else`.
`realisedIf`	Make a binary decision with two nonempty executable branches.
`wilsonIf`	Perform an action or explicitly acknowledge that nothing happens.

This does not make the program correct. It makes certain kinds of evasiveness syntactically inconvenient.

realisedIf (condition) {
  positiveAction()
}
// SYNTAX ERROR: unrealised-else
// Provide an alternative, or declare a conditional action.

The author has announced a binary decision and delivered half of it.

We could automatically insert:

else {
  // TODO: nothing
}

But that would manufacture evidence that a decision had been acknowledged when, in fact, a tool had inserted some braces.

We have promoted an omission into a compliance artifact.

Instead, the author must choose: supply the alternative, use an ordinary conditional action where permitted, or explicitly declare inaction.

2. Nothing is an outcome, not an explanation

Sometimes the correct alternative really is to do nothing.

That should be expressible without pretending that an empty block is an implementation.

realisedIf (condition) {
  positiveAction()
} else {
  // do nothing
}
// SYNTAX ERROR: empty-realised-else
// Use wilsonIf to declare intentional inaction.

The valid form is:

wilsonIf (condition) {
  positiveAction()
} else nothing

The false path is now acknowledged.

It is not justified. It is not proven safe. But it is no longer indistinguishable from a missing piece.

There is an unfortunate naming complication: once we explicitly acknowledge an “unrealized else,” it is no longer unrealized.

The terminology has developed the condition it was intended to diagnose.

Ordinary if remains useful for simple conditional actions:

if (cacheEntryExpired) {
  removeCacheEntry()
}

A permissive project allows that. A stricter project can require wilsonIf for nonterminating conditional actions, perhaps only in nested or consequential code.

That preserves the original article’s useful restraint: apply pressure where the missing alternative matters, not everywhere a keyword can be counted.

And the compiler’s knowledge remains limited:

realisedIf (condition) {
  positiveAction()
} else {
  accomplishAbsolutelyNothing()
}

There is an executable statement. The structural requirement is satisfied.

Whether it accomplishes anything is a separate investigation. The compiler verifies the paperwork, not the wisdom.

3. Guards do not need an escort

A guard clause states a condition under which execution cannot proceed.

if (!authorized) {
  throw Unauthorized()
}

performOperation()

The unauthorized path terminates. The authorized path continues.

Adding an else would not discover a missing outcome. It would merely place the main operation inside another block.

if (!authorized) {
  throw Unauthorized()
} else {
  performOperation()
}
// SYNTAX ERROR: realised-else
// Ordinary if forbids else.
// Prefer the terminating guard.

The else has been dismissed because its services are no longer required.

This is the strongest case for an anti-else policy: not that alternatives are bad, but that a terminating branch already makes the separation visible.

Our strict acknowledgment policy therefore exempts terminating guards.

There is no requirement to conduct a small ceremony after every return.

4. Three alternatives are not a binary decision

Now consider:

realisedIf (state == READY) {
  deploy()
} else if (state == PENDING) {
  wait()
} else {
  reject()
}
// SYNTAX ERROR: strict-binary-decision
// Use switch for alternatives over one discriminator.

We declared a binary decision and then installed a third outcome.

An else if is an alternative with terms and conditions. We actually submit that we should ban else if completely:

if (condition) {
  doSomething()
} else if (someOtherCondition) {
// SYNTAX ERROR: no-else-if
// Use separate blocks

Because else if is identical to:

if (condition) {
  doSomething()
}
if (otherCondition) {
  doSomethingElse()
}

For alternatives over one state value, a switch exposes the structure more clearly:

switch (state) {
  case READY:
    deploy()

  case PENDING:
    wait()

  default:
    rejectUnsupportedState(state)
}

Our language does not fall through by default. Selecting one arm executes that arm.

However, not every chain is secretly a switch:

if (temperature > limit) {
  shutDown()
} else if (batteryLow && disconnected) {
  conservePower()
}

Those are arbitrary predicates, potentially overlapping, with an ordering that matters.

Demanding a conventional switch would change the costume without necessarily improving the decision. Our language therefore also offers an ordered predicate case, whose first matching arm wins.

The important distinction is between dispatch over a value and priority among conditions.

A rule that cannot distinguish them has discovered a preference, not a principle.

5. Default is not another word for safe

Requiring a default sounds responsible.

Every possibility gets handled. Nobody falls through a crack.

Unfortunately, “handled” can mean this:

switch (state) {
  case READY:
    deploy()

  default:
    wait()
}

Pending, failed, deleted, corrupt, and any state introduced after the author leaves the company will all wait.

The default has excellent coverage and questionable judgment.

Our rule is therefore:

A switch must be exhaustive over its declared domain, or explicitly handle unmatched input.

For a closed set of states, the compiler can require every variant. Adding a new variant then produces an error at decisions that need reconsideration.

For external values, explicit rejection or fallback may be necessary. A type declaration is not a border checkpoint; unexpected runtime values can still arrive through poorly defended boundaries.

The compiler should know whether the author is claiming:

These are all the possible states.
Other states are valid and share this behavior.
Other states are invalid and must be rejected.

Those are different claims.

A default that quietly accepts everything may be the largest secret in the program.

6. Fallthrough must introduce itself

Fallthrough lets a case execute not because it matched, but because it lives downstairs.

There are legitimate uses. Our language permits them, but requires an explicit declaration:

switch (mode) {
  case FULL:
    runExtendedChecks()
    fallthrough

  case BASIC:
    runBasicChecks()
}

Without fallthrough, each arm stops at its boundary.

Grouped labels are different:

case PENDING, QUEUED:
  wait()

Two labels share one body. No body spills into another.

The benefit of explicit fallthrough is not that it prevents every mistake. It makes physical case ordering an acknowledged dependency.

Implicit fallthrough makes that dependency a surprise.

Actual fallthrough into or out of default is prohibited in this language. Default already has a difficult job: explaining what happens when selection finds no match. It should not also serve as a corridor for matched cases.

Shared follow-up work belongs after the switch if it is unconditional, or in an explicitly called helper if it is not.

Default is not the communal kitchen.

7. Logging is not a branching problem

There is one conditional our language rejects for a different reason:

if (debug) {
  emitLogs()
}
// SYNTAX ERROR: conditional-logging
// Use log.level(...) instead.

The answer is not:

wilsonIf (debug) {
  emitLogs()
} else nothing

We have clarified the wrong decision.

Logging policy belongs to the logging system:

log.level(DEBUG, "Placement candidate evaluated", candidate)

Here, log.level(...) is our fictional logging API: it submits an event at a specified severity. Configuration determines whether that event is emitted.

The application reports what happened. The logger decides which reports are currently wanted.

Otherwise, logging policy becomes distributed across dozens of booleans and branches. During an incident, we discover that the evidence we need was conditional on a flag whose location was also a secret.

Expensive diagnostic construction may still need a lazy logging API or an enabled-level check. That is a resource decision, not a reason to scatter ordinary log filtering throughout the application.

8. What the language knows—and what it does not

Wilson’s Law does not require every alternative to contain work.

It requires the program to distinguish:

Conditional action.
Terminating guard.
Binary choice.
Intentional inaction.
Multiway dispatch.
Ordered predicates.
Unexpected input.
Deliberate fallthrough.

A normal language can already express these. Our fictional language makes some of the distinctions compulsory.

A linter could approximate much of this without inventing new keywords: reject redundant else, check exhaustive switches, require explicit fallthrough, flag selected empty branches, and keep ordinary logging policy out of application conditionals.

But neither a compiler nor a linter can establish that every declared decision is a good one.

We can remove every else from a codebase. The conditions will continue to be false.

We can add every missing else. The alternatives may remain unconsidered.

The objective is not more branches or fewer branches.

It is fewer secrets.

The alternative exists whether we write it down or not. The paperwork is optional; the consequences are not.

Appendix

Disclaimers

This post was created with the help of AI. The author takes full responsibility for the content.

Credits

Photo by Zach Reiner on Unsplash

The Zeroeth Law of Engineering

Regis Wilson — Mon, 26 Oct 2026 21:53:35 +0000

Overview

Before architecture, implementation, and deployment comes a question that can ruin an otherwise excellent planning meeting: does this artifact need to exist at all? Everybody has already agreed on the repository name. It feels unkind to bring reality into it now.

An Apple Is a Ridiculous Amount of Work

An apple is a deceptively small achievement. You walk into the kitchen, pick one up, wash it if you are feeling responsible, and eat the outer two-thirds. Perhaps you navigate around a bruise. Perhaps you leave a heroic centimetre of perfectly good apple attached to the core because getting closer would require an awkward rotation and a level of commitment you did not bring to lunch. Then you throw the rest away, having successfully consumed the part for which you believe the entire arrangement exists.

To produce those six bites, the world first had to grow a tree. Not an apple dispenser with a convenient trunk attached, but roots, bark, branches, leaves, blossoms, and a reproductive strategy involving third parties with wings. The tree requires water, soil, microbes, suitable weather, and years of sunlight. The pollinators require other plants and somewhere to live. Somewhere downstream are farmers, refrigeration, trucks, grocery stores, and a teenager putting the Honeycrisps in the wrong bin again. The apple costs three dollars because nobody has itemized the universe.

Then your body extracts a relatively small amount of useful energy and material through a digestive system you have been operating your entire life without once scheduling a dependency upgrade. The energy eventually becomes motion, thought, bodily maintenance, and heat. It does not remain in an internal apple battery. Eating one at age seven does not settle the matter through retirement, although a subscription service would certainly advertise the possibility.

At first glance, this looks like staggering waste. We grew an orchard, involved the bees, transported the fruit, and maintained an entire organism so that I could stand over the kitchen sink and decide the remaining bit was too difficult. But the accounting is suspiciously centered on me, which is often where suspicious accounting begins.

The seeds are not manufacturing defects. From the tree's perspective, they may be the principal deliverable, while the flesh is a marketing expense incurred to persuade an animal to distribute them. The leaves are not unnecessary because I decline to eat them. The roots are not overhead that an ambitious tree startup can eliminate in version two. What looks disposable from one position may be essential from another; the tree has not agreed that my snack is its corporate mission.

The apple is the visible result at the tip of an enormous dependency cone. This does not establish that apples are a mistake. It establishes that looking at the fruit is a poor way to estimate what makes fruit possible, which brings us, regrettably, to software.

Every Tool Requires a World

A small software tool looks cheap. One repository, six source files, a build configuration, and a README containing an example that worked on the author's laptop on the afternoon it was written. The implementation took two days. Someone posts a rocket emoji, whose exhaust does not appear in the estimate.

Unfortunately, source code is only the trunk. The tool needs tests, releases, packages, documentation, compatibility decisions, and somebody who remembers why it behaves differently on Tuesdays. Depending on what it does, it may also need authentication, authorization, networking, monitoring, deployment automation, and a Kubernetes cluster. We began with a command that rearranges a string and have arrived at a staffing question.

Users learn it. Applications integrate it. Pipelines call it. Other systems generate its inputs and interpret its peculiar outputs. People write wrappers because the interface is almost right, then wrappers around those wrappers because the first wrappers belong to another department and changing them requires a meeting. The repository remains admirably small. The meetings have not been committed to it.

A tree offers an inconvenient illustration of how this happens. If a large tree weighs tonnes and grows out of the ground, why is there not a tree-sized hole underneath it? Where did the material come from? I admit this question troubled me longer than it should have. The ground appeared to have supplied a tree while remaining entirely ground, which would be an impressive procurement arrangement.

Most of a tree's dry mass is built from material acquired through the air, especially carbon from carbon dioxide, rather than bulk soil hauled upward through the roots. The tree gains substance from something surrounding it that we usually do not notice. Water makes up much of its living weight as well; the point is not that soil contributes nothing, but that looking for a missing tree in the dirt misunderstands the transaction.

Tools acquire mass from their surroundings too. A flag becomes part of a deployment procedure. An output column enters a finance report. A bug becomes something every consumer compensates for, after which correcting it is called a breaking change. Somebody learns that retries must occur exactly three seconds apart and teaches the next person, without either of them finding this requirement in the code. The implementation is visible and countable. The dependency on it has become atmospheric.

Creation starts at the center and moves outward, one enthusiastic adopter at a time. Removal starts at the edges, except nobody knows where the edges are. You think you are deleting a program. Six months later, a report fails because a cron job still calls version 1.3 from a server everyone believed had been decommissioned in 2019. The server is named temp-final-2, which is not a name so much as a record of negotiations lost.

The useful accounting therefore includes creation, integration, operation, adaptation, and eventual extraction. These are categories, not independent quantities in a reassuring equation: changing the interface can increase integration cost, refusing to change it can increase operating cost, and making either choice without knowing the consumers can increase everyone's blood pressure. The original implementation estimate describes the part whose author was present to estimate it.

Creation is paid by the team making the decision. Integration is paid by adopters. Operations are paid by whoever gets paged. Extraction is paid years later by people who were not in the meeting and would like to know why a temporary command now participates in financial reporting. The ticket has been archived, the documentation returns 404, and the original team has achieved the only reliable form of decoupling: employment elsewhere.

Construction Has Excellent Visibility

Most engineering advice begins after the decision to create has already been made. Here is how to build a service, select a framework, structure a repository, and make the result observable, secure, reusable, extensible, and deployable across seventeen regions. We receive extensive guidance on maintaining the thing and remarkably little pressure to establish why there should be a thing to maintain.

Even advice against complexity tends to accept construction as the default. “Keep it simple” means build a simpler artifact. “You aren't gonna need it” removes optional features from the artifact we have already authorized. “Do not repeat yourself” sometimes replaces three repeated lines with forty-seven lines of abstraction, making the repetition disappear into a place where nobody can comfortably inspect it. “Reuse before build” may import someone else's dependency cone, release schedule, design assumptions, and newly creative interpretation of licensing.

None of these principles is useless, and several can reject the whole proposed artifact when taken seriously. We have a remarkable talent for applying them only after approving the repository. Under that interpretation, you can follow all of them faithfully and produce an exemplary system whose main accomplishment is giving six people something else to remember.

Artifacts are easy to recognize as work. We can count commits, pull requests, repositories, services, and launches. When morale deteriorates sufficiently, we can count lines. A requirement eliminated by one awkward question leaves much less evidence. There is no service to demo, no migration to announce, and no incident dashboard showing the failure mode that never existed. The engineer who prevented the project appears to have spent the week talking.

This is how construction passes for engineering: it leaves something we can point at. Restraint leaves a smaller invoice, a quieter pager, and an empty space in the architecture diagram that somebody will eventually propose filling. The savings are distributed. The absence of a launch is immediately visible to the person assembling the quarterly presentation.

The distinction also matters to the Neo-Fermi/Wilson AI paradox. If implementation output is abundant, we still need to ask where that abundance becomes a worthwhile outcome. More software is evidence that software was produced. Whether it improved the situation remains a separate investigation, usually scheduled after the celebration.

The Question Before the Ticket

The ordinary sequence is to build something that works, improve it, make it efficient, and remove whatever turns out to be unnecessary if there is still time. There is never still time. By then, applications depend on it, dashboards measure it, and somebody has colored it “strategic” in the roadmap. The unnecessary part now has stakeholders, which is how a technical fact acquires legal representation.

The sequence needs to begin earlier. Prevent an unnecessary obligation before taking it on; examine obsolete obligations before preserving them; build what survives the inquiry and make it work correctly. That may be a demonstrated necessity or a bounded experiment whose potential benefit warrants its cost, not merely another object approved because nobody could prove it useless. This is an order of inquiry, not an instruction to perform speculative deletions while everyone waits for a payment to settle. An existing component may need to remain during migration, and a necessary new one may need to arrive before the old one can leave. Reality is annoyingly unwilling to execute a manifesto in numbered order.

The Zeroth Law of Engineering is therefore: do not build what need not exist.

It comes before architecture, implementation, testing, and deployment because those activities cannot retroactively justify their own subject. A perfectly functioning unnecessary system may be harder to remove than a broken one. People will trust it, adopt it, and eventually describe its continued existence as a requirement.

A request usually arrives as a proposed object. “We need a dashboard” sounds settled until you discover that someone needs to know whether a process completed. “We need a database” may mean two executions must share one small piece of state. “We need a microservice” may mean nobody wants responsibility for a function already in the application. The named artifact conceals the actual constraint while giving the meeting something to estimate.

Swimming upstream means asking what happened, what outcome is required, and what prevents the existing arrangement from producing it. Sometimes the capability already exists. Sometimes a rule can change. Sometimes the report nobody reads can stop being produced, taking its proposed dashboard with it. Occasionally you still need the database, and now you have the rare pleasure of knowing what it is for before selecting one.

This is not a request to optimize a needless process until it becomes too impressive to cancel. In the fan-noise essay, reducing work and questioning its continuation are different moves. An engineer can spend six weeks making a job cheaper while carefully avoiding the person who could confirm that its final consumer stopped using it last February. The job becomes efficient. February remains unconsulted.

The Bamboo Has Not Read the Label

I own a PVC pipe cutter that I use to cut thick bamboo in my backyard. I do not believe I have ever cut PVC with it. The cutter seems untroubled by this departure from its stated career path, which is more than can be said for many people who discover their degree is not a physical law.

“PVC pipe cutter” is a market category. The relevant mechanism is a ratcheted shearing action suited to certain cylindrical materials. Bamboo can fit that mechanical contract without fitting the label. Searching for a bamboo-specific artifact would have been understandable and might have produced a very attractive purchase, but the bamboo would not have been cut any more convincingly.

The famous Knuth–McIlroy word-frequency example makes a similar distinction. Knuth wrote a substantial program as a demonstration of literate programming. McIlroy showed how existing Unix commands could compose the required transformations: split text into words, normalize, sort, count, rank, and select. One approach demonstrated how a program could be constructed and explained; the other demonstrated how the task could be expressed using capabilities already present.

They were serving different purposes. A teaching artifact does not become unnecessary merely because there is a shorter way to produce its output. If the requirement is to demonstrate literate programming, the program is doing work the pipeline is not. If the requirement is to count words, however, the pipeline deserves examination before we commission another executable and someone inherits its release process.

The useful alternative to bespoke software is not automatically one enormous tool with nine hundred flags. Nor is it a sixty-stage shell pipeline relying on accidental whitespace, locale-sensitive sorting, and a regular expression whose author disappeared from a forum in 2008. That is a custom program written sideways, with its dependency declarations distributed across your hopes.

What matters is whether the essential transformations already exist behind contracts stable enough for the job. Composition still needs validation, ownership, and an explanation of what happens when a stage fails. The absence of a new repository does not mean the absence of a new obligation. A pipe cutter can cut bamboo; it cannot make judgment unnecessary.

Let's Cook, Claude

A missing comma can move Claude from the person being addressed to the object of the sentence, which is a troubling start to a production specification. I mean “Let's cook, Claude,” although even that leaves open whether we are preparing dinner, generating a deployment system, or producing another metaphor about toast. Natural language is impressively flexible until flexibility enters the acceptance criteria.

Generative AI makes the Zeroth Law more important because it makes creation easier without settling necessity. Ask for a helper and you may receive a helper, an interface, a configuration layer, a test suite, and a cheerful README introducing the project to a world that had managed quite comfortably without it. The model is responding to the request. The request has already decided what success should look like.

If the first attempt fails, we ask it to continue. A local problem becomes a framework because frameworks offer more places to put the next correction. Soon there are agents coordinating agents, a custom message broker, and eleven pans on the stove. We originally wanted toast, but toast has become the reference implementation of our breakfast platform.

The economic change is real. A developer who expected an abstraction to take two weeks might spend an hour searching for an existing capability. When the abstraction can be generated in thirty seconds, searching feels like the expensive option. This comparison is persuasive only if the story ends when generation ends. Unfortunately, the compiler has no authority to close the account.

Generated code still needs to be understood, reviewed, secured, tested, operated, upgraded, and eventually removed. It can produce the visible trunk quickly. Consumers, operational assumptions, compatibility demands, and failure modes do not become free because the first draft arrived before the coffee. The pull request contains four thousand lines, nine interfaces, and documentation explaining why all nine interfaces are necessary. Two other models agree. We have achieved independent agreement about an assumption nobody asked them to challenge.

The useful prompt begins before implementation. Ask the model to recover the outcome behind the requested artifact, inspect the repository for existing capability, compare safe compositions, and consider whether obsolete behavior can be removed. Then ask for the smallest change that survives that inquiry, including its consumers and how it could later be replaced. This is less exciting than watching a service materialize, but excitement has never been a reliable compatibility policy.

AI can assist with search, comparison, impact analysis, and subtraction. It can also get those wrong, which is why “the model found no consumers” is a finding to investigate rather than permission to delete production state. The objective is not to replace construction with confidently automated non-construction. It is to stop rewarding output before determining what output would help.

Practice Without Starting a New Practice

“Build nothing” cannot mean refusing useful work while reciting philosophy in sprint planning. Sometimes the existing tool is dangerous, inaccessible, expensive, or incapable of meeting the requirement. Sometimes a new capability creates possibilities worth exploring before there is a mature business case. The law asks creation to survive examination; it does not require the future to submit receipts before arriving.

Begin by describing the outcome without naming the proposed apparatus. A person needs to know within five minutes when an event fails. That is a constraint. A notification service is one possible response, not yet a fact about the universe. An existing alert might satisfy it. Changing the process might remove the failure. Or the service might genuinely be needed, in which case we can discuss delivery guarantees instead of spending the first week naming notification abstractions.

Adoption must become discoverable. If nobody can find the consumers, nobody can confidently estimate the thing's mass or remove it safely. That may require usage records, explicit dependency declarations, or simply ownership that survives a team reorganization. These mechanisms also cost something. An inventory platform for three scripts can reproduce the problem it was commissioned to solve, now with a nicer search box.

Finding those consumers lets us ask what they actually depend on. Ideally, it is behavior we intend to preserve, not the particular order of an accidental output or the fact that a timeout currently returns success. Once enough consumers adapt to a bug, the bug receives tenure. Correcting it still matters, but now correction includes migration rather than a triumphant one-line patch and an afternoon of surprise.

That migration problem is why the exit belongs in the entrance discussion. Who will know when the last consumer has left? Can implementations coexist during replacement? Who owns extraction after the original team moves on? A tool without answers becomes a future Chesterton's fence, surrounded by people who suspect it is unnecessary but have discovered that suspicion is not a rollback plan.

For an experiment, the extraction problem can start before anyone admits there is a product. A proof of concept is scaffolding, not a constitutional amendment, and it needs a point at which somebody decides whether it continues. Its expiry should trigger review, not an unattended deletion while consumers are using it. If it succeeds, keep the parts the evidence supports. If it fails, remove it before a copied example becomes somebody else's reason that removal is impossible.

Subtraction also needs to count as work. An architecture review can ask which obligations disappear, and a planning discussion can recognize an avoided migration as an outcome rather than a missing deliverable. Otherwise the rational career move is to build the thing, become its indispensable expert, and later receive recognition for managing the complexity one introduced. This need not involve bad intentions. The incentives are capable of arranging it without assistance.

Most importantly, distinguish support from waste. Tests, documentation, observability, and migration paths are not leaves we can remove because customers only eat the fruit. If the tool must exist, responsible support may be part of its irreducible cost. The Zeroth Law is not a discount code for shipping unsupported software. It is a reason to consider that cost before promising the object at the tip of the cone.

The harder question is whether we can allow a needless process and its corresponding demand to cease. Engineers are good at improving execution, preserving compatibility, and retaining just in case. Ceasing asks us to relinquish something we know how to manage, perhaps something we built ourselves. It may also ask us to admit that a very successful quarter produced a very maintainable obligation.

First, Build Nothing

Tools are made from tools, just as ideas are made from ideas. Every artifact inherits languages, protocols, libraries, infrastructure, and accumulated knowledge. Once adopted, it changes what later systems can assume. A convenient output becomes an input somewhere else; an experiment becomes a precedent; a workaround becomes the example used to train the next engineer. Every tool is both fruit and seed, including the ones we were quite sure would remain internal.

This is why creation is not local and removal is not deletion. Deleting the repository can leave its historical data, contracts, procedures, and expectations alive elsewhere. The thing may be gone while everything still holds its shape. We have removed the apple dispenser and retained an organization that arrives every morning carrying a bowl.

Engineering begins by looking beyond the visible artifact to the conditions it requires and the conditions it will create. Build when the actual constraint warrants it. Make the result correct, support it honestly, and preserve a practical way for it to stop existing. But before turning a request into another part of the world, leave room for the possibility that no new part is required. An empty repository is not necessarily an unfinished project; sometimes the question was answered before it needed one.

Postscript: The Tree Makes an Objection

I confess I have rarely encountered a proper postscript in an actual letter outside literature, so this is quite exciting. It is also necessary because the tree remains standing after the argument, still producing apples with an apparent disregard for my excellent concerns about its architecture.

The tree pays much of its growth cost before producing fruit repeatedly. It can shelter animals, feed pollinators, stabilize soil, and create more trees. Some of what appeared to be overhead supports several outcomes at once. The dependency cone is large, but the returns do not stop at my six bites over the kitchen sink. I was not wrong to notice the cost. I was wrong if I thought noticing it completed the evaluation.

The tree would have had difficulty passing a conventional architecture review before its first apple. Years of growth, underground dependencies, seasonal availability, third-party pollination, and a deliverable whose principal consumer discards the reproductive payload: please simplify and resubmit. A procurement team might recommend buying apples instead, thereby moving the tree outside the diagram and announcing that the dependency had been eliminated.

This is the limit of the law. A dependency cone reveals the scale and character of an investment; it does not prove the investment should never be made. Some artifacts are valuable because they enable outcomes nobody could fully specify beforehand. Their uncertainty should be acknowledged, their continuation examined, and their support funded, rather than treated as either permission for everything or an argument for nothing.

Do not build what need not exist, but do not confuse “I cannot yet justify this” with “this need not exist.” Aggressive restraint can prevent useful compounding just as enthusiastic construction can produce permanent housekeeping. The question is not how to avoid ever being wrong. It is how to make a decision whose benefits, obligations, and grounds for reconsideration remain visible after the rocket emoji has scrolled away.

The tree can stay. I am less certain about the dashboard that reports whether the tree is still there, but apparently three teams consume it now.

This essay was written and revised with the help of AI. No new service was required, although a Markdown file did survive examination.

A Journey of Mind Free From Fan Noise

Regis Wilson — Tue, 20 Oct 2026 17:36:43 +0000

From C to Kafka to Tech Debt: A Journey of Mind Freed From Fan Noise

Let us begin with four integers, because all serious investigations into enlightenment should begin with a data structure that can be understood before the coffee has finished compiling the engineer.

int values[] = {10, 20, 30, 40};

This is an array. It contains four values in an order. The order appears reassuringly objective because C has assigned each value an address and will become extremely unpleasant if we misunderstand where those addresses end.

Nothing is moving yet. Ten is not travelling toward twenty. Forty is not waiting at the end with a small retirement cake. The array has no opinion about which value should be read first, whether every value deserves equal attention, or whether reading them achieves anything.

To obtain movement, we add an index.

for (size_t i = 0; i < 4; i++) {
    consume(values[i]);
}

Now the array appears to have a beginning, a direction, and an end. This is already a small fraud.

Ten does not know it is first. Forty does not know it is last. The values have not acquired a direction merely because i is increasing. The code has selected an initial position, defined a successor, and declared that four is where the police become involved.

We could reverse the traversal.

for (size_t i = 4; i-- > 0;) {
    consume(values[i]);
}

The same array now tells the opposite story with complete confidence. Forty is first. Ten is last. Nobody moved the data. We changed the rule by which the data became present.

This is not yet enlightenment, but it is at least enough to make code review uncomfortable.

The Array Puts on a Ring

Suppose we remove the exit condition.

size_t i = 0;

while (true) {
    consume(values[i]);
    i = (i + 1) % 4;
}

We now have something resembling a ring buffer. It is worth asking where the ring came from, because the memory did not curl into a circle. Address zero has not physically bent around the motherboard and attached itself to address three. If that has happened, turn off the machine and contact the manufacturer.

A famous entertainer exhorted us to “Shoulda put a ring on it” so we did:

i = (i + 1) % 4;

The modulo operator interprets the boundary as a return. Three becomes zero, not because zero is naturally after three, but because we have installed a policy under which reaching the end means beginning again.

The array and ring buffer are therefore not two entirely different substances. The array becomes a ring through recurrent indexing. The ring becomes an array when we stop recurring. What looks like topology is partly behavior. What looks like a property of the storage is partly a habit of the reader.

This gives the machine a perfectly adequate answer to one question:

values[i]

That is who I am now.

The answer is temporary. The same index may hold another value after a write. The same value may occur at another index. Another thread may alter the cell between our inspection and our use, which is how concurrency reminds philosophy that it has not acquired a lock.

“Current” belongs neither to the value nor the address. It arises from value, address, index, execution, and time. Remove any of these and the current value becomes a different value, an inaccessible value, or a lengthy incident report.

The index can tell us who we are now. It cannot tell us where the traversal originally began. After ten thousand rotations, zero is not more original than three. It merely has better public relations.

Nor can the index tell us when to stop. Modulo is excellent at continuation and has no qualifications in purpose.

The Missing Condition

A reviewer encounters the loop.

while (true) {
    consume(values[i]);
    i = (i + 1) % 4;
}

The reviewer says, “Someone forgot the exit condition.”

This may be correct. Reviewers occasionally are. The difficulty is that nothing inside true tells us what the missing condition was.

Perhaps the author intended:

while (!cancelled) {

Perhaps they intended:

while (temperature < warranty_voiding_threshold) {

Perhaps this is firmware in a medical device and stopping would be substantially worse than continuing. Perhaps it runs in a Kubernetes pod whose official exit strategy is to be shot by a control plane that has recently lost quorum. Perhaps the author wrote exactly what they meant and has since moved to a management role where consequences arrive as charts.

Without a specification, comment, issue, commit history, or git blame, the intended negation of true is unavailable. We can invent an ending, but invention should not be confused with recovery.

At the present moment, the loop is doing exactly what it says. The processor does not experience eternity. It evaluates true, executes the body, advances the index, and returns. Infinity never enters a register. The machine performs only the next instruction and, if conditions permit, the one after that.

This is why while (true) is a better image of samsara than the usual cartoon of a wheel. Samsara is not an infinite quantity stored somewhere beyond the horizon. It is continuation renewed in the present. The loop returns because the conditions for returning have arisen again.

The code is locally faultless and globally suspicious, which is also a reasonable description of civilization.

Kafka Discovers Rebirth

Four integers are not enough for modern enterprise suffering. We need distributed systems.

The ring remains useful, but returning to the origin is precisely incorrect. In a true memory ring buffer, the index wraps and storage slots are reused. The loop is present. Kafka instead appends records at increasing offsets, and disk storage is sufficiently cheap that we keep writing “forever,” a duration defined in enterprise architecture as beyond the current budgeting period.

A circle of sufficiently large circumference is locally indistinguishable from a straight line. Especially when the person drawing the architecture diagram has cropped out retention.

Imagine a very large stone block advancing over wooden rollers. Workers retrieve the logs emerging behind it and carry them to the front before the block discovers that infrastructure is finite. The logs return. The stone does not. Returning the stone to its origin would not be progress. It would be a retrospective with fatalities.

Tank tracks make the same distinction without requiring everyone to carry timber. The tread circulates; the vehicle advances. Repetition underneath does not mean the journey has begun again.

Kafka’s storage lifecycle offers a less muscular version. Producers append new records. Retention removes old segments, allowing their space to be reused. The offsets do not wrap back to zero. We recycle the ground beneath the journey while continuing to number the distance, which is how bounded infrastructure acquires an unbounded job description.

We partition the log, replicate it across machines, and assign consumers positions within it. The same uncertainty can now occur on several nodes at once.

A consumer group divides partitions among its members and stores committed offsets so that everyone can maintain a professionally defensible opinion about what has already happened. Soon it develops attachment.

It begins to believe that this is its partition. It regards lag as a moral judgment. It watches the high-water mark retreat at exactly the rate it advances and concludes that peace will arrive after the next autoscaling event.

This is how the consumer enters samsara. The problem is not that it consumes. The problem is that it expects the stream to certify its completeness.

A live stream does not provide this service. Catching up is only the temporary coincidence of the committed offset with the high-water mark. The next producer write abolishes the achievement. A dashboard celebrates green for nine seconds and then returns to amber, which is the native color of conditioned existence.

The attached consumer curses the ring because it believes the ring has broken a promise. It says, “I have processed ten million records. Why are there more records?”

The ring replies that it made no promise. In fact, the ring does not reply. A timeout occurs and the consumer is removed from the group.

Why the Bodhisattva Does Not Curse the Ring

The bodhisattva joins the same consumer group and receives an assignment.

They understand that the assignment is real enough to require work but not real enough to become a self. The partition is assigned, not possessed. The offset is useful, not sacred. Lag is a measurement of a relationship between production and consumption, not evidence that the universe has found them personally inadequate.

Most importantly, the bodhisattva does not curse the ring for being a ring.

Cursing the ring would be like cursing water for remaining wet after an extremely persuasive architecture meeting. The ring returns because return is the behavior assembled from its conditions. Producers produce, consumers consume, offsets advance, retention removes old records, and somebody opens a Jira ticket asking whether retention can be infinite without increasing cost.

The bodhisattva knows there is no final record waiting to award them completion. This does not make the present record worthless. It makes the present record available without the additional burden of pretending it is a step toward personal salvation.

while assigned:
    records = consumer.poll()

    for record in records:
        respond_skillfully(record)

    consumer.commit()

The commit is not a trophy. It is a kindness to the next consumer.

When a rebalance occurs, the bodhisattva releases the revoked partition without composing a grievance about ownership. When a new partition arrives, they accept it without announcing a strategic acquisition. They understand the coordinator may change its mind because changing its mind is approximately what coordinators do when any member takes longer than expected to visit the garbage collector.

The bodhisattva continues reading because beings exist downstream of the record. A payment may need reconciliation. A patient may need notification. A shipment may need redirecting. An alarm may need acknowledging before it is acknowledged by the building.

They do not read to defeat the stream. They read because this record is present and a skillful response can change what happens next.

This is participation without possession. It is also, regrettably, operations.

The bodhisattva does not push the partition forward. Producers append to the partition. The bodhisattva advances the consumer group’s committed offset. This distinction prevents a small but important spiritual error: believing that one worker is moving the whole universe toward completion.

There is no universal offset at which everybody becomes permanently caught up. There are only groups, positions, consequences, and brief green dashboards photographed for quarterly presentations.

The Buddha Encounters an Unexpected Value

The Buddha may enter the consumer group too. Historically, the Buddha did not awaken and immediately terminate the process. He continued living, teaching, eating, walking, becoming ill, and dealing with people who had converted ordinary confusion into elaborate philosophical confusion.

Awakening did not remove conditioned events. It changed the grasping by which conditioned events became bondage.

This matters when the record contains an unexpected value.

{
  "status": "completed",
  "completed_at": null
}

The ordinary consumer becomes angry because reality has violated the enum.

The senior engineer explains that this state is impossible, which is an interesting claim to make about a value currently occupying memory. The schema owner says the producer cannot emit it. The producer team says the consumer must have transformed it. Everyone gathers around the unexpected value and denies parentage.

The bodhisattva does not curse it. They trace its conditions, protect downstream beings from its consequences, and perhaps add validation at the boundary where validation was described as “unnecessary” during the design review.

The Buddha laughs.

This is not the cruel laughter of someone exempt from the pager. It is the laughter produced when a system presents direct evidence that its categories were never the territory and then watches its maintainers defend the categories against the evidence.

Of course the impossible value arrived. “Impossible” meant that the model contained no branch for it. Reality was not consulted.

The Buddha can still reject the message, quarantine it, repair it, or wake the producer’s owner at 3:00 a.m. Emptiness is not an instruction to accept corrupt input. Wisdom does not replace type checking with incense.

But the Buddha is not personally betrayed by the value. They do not need the record to preserve the worldview in which every state is known, every producer behaves, and exhaustive switches remain exhaustive after another team deploys on Friday.

The value is unexpected because expectation arose first. That does not make the value good. It merely makes surprise a relationship rather than a property serialized in JSON.

In a Madhyamaka reading, samsara and nirvana are not separate clusters. The Buddha does not escape to a silent VPC where no messages arrive and all dependencies are pinned. Polling is not inherently samsara, and closing the consumer is not inherently nirvana. Otherwise every crashed process would be enlightened.

The difference concerns attachment. The ordinary consumer believes its identity depends on processing the stream. The bodhisattva processes the stream compassionately without requiring a final record. The Buddha is free from the opposition between joining and leaving, and therefore can come and go without turning either membership state into a metaphysical achievement.

Then the processor becomes warm.

The Fan Files a Materialist Objection

Software likes to describe itself as though it occurs in a clean symbolic realm. Records enter, functions execute, offsets advance, and invoices become payable. The architecture diagram contains elegant arrows and no indication that the server room is attempting to heat the surrounding county.

But instructions switch transistors. Switching produces heat. Sensors observe the heat and ask the fan to become audible.

The fan is where abstraction discovers it has a body.

The consumer says it processed a record. Kafka says the offset advanced. The operating system says CPU time increased. The fan says nothing because it has not been invited to the retrospective.

It turns anyway.

The execution creates heat, heat summons the fan, and the fan removes enough heat for execution to continue. The consequence of execution activates a mechanism that preserves the conditions for further execution.

The loop produces the response that enables the loop: this is dependent origination with bearings.

The fan does not understand the record. It cannot distinguish a bodhisattva from an ad-tech consumer computing a more spiritually accurate probability that someone will buy trousers. Thermodynamics offers no ethics API. Compassionate instructions and malicious instructions both become heat.

This is why the bodhisattva must care about the fan. Good intentions do not receive free cooling. A system allegedly built for the benefit of beings can still waste electricity, exhaust operators, saturate networks, and reproduce the same record twelve million times because nobody selected an idempotency key.

Non-attachment does not mean indifference to cost. It means the bodhisattva can examine cost without turning architecture into self-defense.

The attached engineer hears fan noise and says, “The load proves customers value the feature.”

The bodhisattva asks whether the feature could do less work.

The Buddha asks whether the feature should exist.

The product manager schedules a follow-up to align on definitions.

Tech Debt Is Code That Has Left the Repository

We usually discuss technical debt as if it lives in source control. There is an ugly class, an obsolete dependency, an interface whose implementation requires three factories and an apology. Someday, we say, these debts must be paid.

This resembles financial language while omitting the useful features of finance, such as an agreed currency and the possibility of identifying the lender.

Karmic consequence is wider than existing code. Deleted code continues through what it caused.

A service once emitted timestamps without time zones. The service was rewritten years ago, but its historical records remain. Every consumer now contains logic for guessing what those timestamps meant. The originating code is gone. Its uncertainty has achieved platform status.

A temporary field becomes mandatory because three clients rely on it. An accidental ordering becomes an undocumented contract. A default copied into deployment templates reproduces itself across regions. An emergency workaround teaches the next engineer what “normal” looks like. The seed is planted, watered by compatibility, and eventually described as a foundational architectural principle.

This is karmic debt, although “debt” remains slightly misleading. The universe is not maintaining a ledger, and the fan is not collecting interest. Past actions condition present possibilities. Some futures become easy, some expensive, and some nearly unimaginable because the people who remember the alternative have left for companies with better equity.

The ring now has more dimensions than its original index. There are source versions, branches, compiler versions, dependencies, configurations, inputs, deployments, scheduler states, hardware models, ambient temperatures, operator intentions, and undocumented flags named legacyMode2.

What we call “the program” is one traversal through this space.

The same source compiled differently may produce different instructions. The same binary given different input follows another path. The same workload in another region may draw electricity from another grid and summon another fan. The same feature used by ten people is a curiosity; used by ten million, it becomes a line item in an environmental report nobody wants attached to the board deck.

Wisdom recognizes that the current traversal is not inevitable.

The Buddha can imagine the records in another order, the feature under another configuration, the query with another index, the consumer without the retry storm, or the system without the consumer. This imagination does not place the Buddha outside causality. Profiling creates heat. Benchmarking creates heat. Spending six weeks optimizing a job that should have been deleted creates heat and a promotion packet.

Still, counterfactual understanding matters. Because the present arrangement has no fixed essence, its conditions can change. A record can be filtered before production. Several operations can be batched. A result can be cached. A compatibility path can finally be removed after the last client is discovered running beneath an employee’s desk in Ohio.

Sometimes the best optimization is non-execution. This is difficult to sell because non-execution has no dashboard. The fan that did not accelerate produces no metric. The cloud invoice that did not increase sends no congratulatory alert.

Absence has terrible observability.

The Final Storage Tier

Execution is obviously impermanent. A process begins, mutates state, loses its lease, receives SIGTERM, ignores it, receives SIGKILL, and is described in the postmortem as having shut down gracefully.

Storage feels different. Storage is where we put things so that impermanence becomes another team’s problem.

We save the record to disk. We replicate the disk. We back up the replica. We place the backup in object storage and configure lifecycle policies nobody reads because the console uses the word “durable.”

But even S3 is ephemeral.

This statement sounds provocative only because cloud marketing has successfully replaced “maintained under an extraordinary collection of conditions” with “stored.”

An S3 object persists while the account exists, billing succeeds, credentials remain available, policies permit access, encryption keys survive, formats remain intelligible, regions continue operating, replicas remain healthy, and no authorized process executes a deletion with the confidence unique to automation.

Eleven nines of durability is impressive. It is not eternity. Eternity has no service-level agreement because there would be nobody left to claim the credit.

Storage is not the opposite of execution. Storage is an ongoing activity disguised as a thing. Replication, checking, repair, migration, authentication, cooling, institutional continuity, and money all collaborate to produce the appearance that the object is sitting still.

Eventually the record is overwritten, expired, deleted, corrupted, encrypted behind a lost key, or preserved perfectly in a format no surviving program can interpret. Sometimes the bits remain and the meaning disappears first. This is cheaper than deletion and more common in enterprise systems.

The ring forgets because forgetting is how bounded storage continues. Kafka retention removes old segments so new ones can arrive. Git repositories disappear. Package registries remove artifacts. Container images lose their base layers. S3 buckets outlive their owners and are then found during cost optimization by someone whose task description says “quick win.”

Impermanence is a friend. It is what permits a broken deployment to be replaced, an obsolete contract to end, a partition to rebalance, a harmful feature to be removed, and a processor to cool.

The attached consumer curses the ring because it wants the ring to end on its terms.

The Engineering Mind, Freed

Meanwhile the fan turns because insight still executes on hardware. Then the load falls. The sensor changes. The fan slows.

Mind freed from fan noise does not require a fanless universe. It no longer mistakes the noise for purpose, punishment, permanence, or self.

Engineering is often described as a war against change. We preserve state, pin versions, stabilize interfaces, replicate data, freeze dependencies, enforce schemas, and call the resulting interval “reliability.” This is useful work. It is also temporary work.

Engineering does not defeat impermanence. Engineering arranges a working relationship with it.

The good engineer is therefore not a conqueror of change but a surfer of conditions. This returns us to Skate or Die, except now the board is an incident-response procedure and the pavement is eventual consistency.

One does not command the wave to remain still. One learns its shape, enters at the right moment, adjusts continuously, and avoids confusing balance with immobility.

That is equanimity in engineering: not passive acceptance, but responsive stability.

Engineers are often remarkably good at accommodating change while refusing cessation. We version the API, add an adapter, maintain both schemas, replay the old event format, and preserve a behavior whose final known consumer is believed to run somewhere in Ohio. We partner with impermanence only so long as it agrees never to remove anything.

This is not equanimity. It is hoarding with semantic versioning.

True partnership with impermanence includes graceful termination. Components can be replaced. Records can expire. Assignments can be revoked. Deletion is not always data loss; sometimes deletion is completed retention.

The fan belongs here too. Cooling does not conquer heat. It responds to heat. The fan accelerates, slows, and stops according to conditions. It does not insist that yesterday’s RPM remain backward compatible. It does not publish a thought-leadership post claiming to have disrupted temperature.

The fan is engineered equanimity.

Not because it possesses wisdom, but because someone built a response that does not require temperature to remain constant. Even that response is impermanent. Dust accumulates, bearings wear, and eventually another engineer replaces it.

Equanimity is not sitting beside an overheating CPU and saying, serenely, that all clock speeds are empty. The engineer recognizes the conditions, imagines another arrangement, and builds it.

The bodhisattva does not merely tolerate the ring. The bodhisattva engineers the fan.

They know that work produces consequences outside the abstraction. They introduce backpressure, cap retries, expire records, and reduce unnecessary production. They allow the machine to rest.

The Buddha laughs at the unexpected value because it exposes the limits of the model. Then, if helpful, the Buddha adds the missing branch.

Enlightenment is not opposition to engineering. It may be engineering freed from the fantasy that a sufficiently clever design will make further response unnecessary.

And this returns us to karmic seeds. Someone added a sensor and made temperature influence fan speed. That action changed what future execution could cause. Heat could now summon a response that preserved the conditions for further work.

The sensor does not remember the engineer. The firmware does not consult the design meeting. The manufacturer may be bankrupt. The source repository may have been deleted during a migration described as seamless.

Still, the sensor registers. Still, the fan turns.

The intention need not survive as a remembered intention. Its consequences persist as conditions under which another response can arise.

That is much closer to the karmic seed: not a little package of foresight waiting in the future, but a condition planted by action that may ripen when joined by other conditions.

Impermanence is not merely the friend of engineering. It is engineering’s material.

Engineering is compassion expressed as feedback.

The processor warms. The sensor registers. The fan turns.

In this way, suffering—if not bugs—decreases.

Appendix

This post was co-written with AI

Photo by Trương Tuyết Ly on Unsplash

YOLO: And Other Lies

Regis Wilson — Tue, 13 Oct 2026 19:06:10 +0000

An excursion through death, rebirth, hotel loyalty programs, Four Seasons, the uncomfortable conditions of the Matrix, and the suspicious longevity of Yoda

"YOLO"—You Only Live Once—is usually offered as permission. Buy the ticket. Eat the cake. Quit the job. Send the message. Jump from the airplane with the hopefully competent stranger strapped to your back. Life is singular, the argument goes, and therefore opportunities must be seized before the doors close.

The slogan sounds decisive because it compresses several difficult questions into four cheerful letters. What is a life? What is the "you" that lives it? When does a life begin or end? Does anything continue afterward? Would continuation count as the same life, a second life, or something that is not properly called life at all?

YOLO does not answer these questions. It puts on sunglasses and walks past them.

Even if we accept its basic premise, YOLO immediately implies a less marketable slogan:

YODALO: You Only Die At Least Once

If you are alive, you have at least one death provisionally included in the package. Death is not an optional excursion. It is printed in the booking conditions, although most guests neglect to read them before entering their credit-card information.

More formally:

alive now + mortal \Rightarrow at least one future death

YOLO may or may not be true. YODALO is considerably harder to avoid.

From there we arrive at YODA:

YODA: You Only Die Again

YODA sounds like the logical successor to YOLO, but it contains a trap. To die again, one must first live again—or at least return to some condition capable of dying. Another death requires another occupancy.

The first death comes with the room. The second requires a new reservation.

That changes the practical question. Dying at least once is not much of a choice if one is already alive. Living again is the choice, assuming "choice" is broad enough to include craving, habit, attachment, karma, metaphysical machinery, divine assignment, or whatever else submits the reservation on one’s behalf.

YODA therefore stands at the front desk, small and ancient, offering advice in inverted syntax:

Another checkout, you fear. Another room, you have already requested.

This may explain why he fails to prevent so many disasters. His advice is often wise, but it remains advice for people who keep checking into the galaxy. He understands attachment, warns against fear, and repeatedly watches everyone around him age and die. Meanwhile, he continues occupying the room.

He is over nine hundred years old when he finally checks out.

That is not the record of a Buddha. That is the record of an extremely committed long-term guest.

At best, Yoda is a bodhisattva with excellent late-checkout privileges.

The Western Resort

The principal Western theistic model resembles a single branded resort. You enter through the earthly lobby, stay in a physical room for a while, and eventually check out. But checkout does not terminate your membership. The guest persists, and the management assigns a permanent destination within the larger property.

You can check out any time you like, but you can never leave.

The line is compelling because it expresses a strangely reassuring captivity. Death closes the room, not the account. The guest survives. Identity remains legible. Management knows your name, retains your records, and forwards the luggage. There may be excellent accommodations, terrible accommodations, intermediate processing areas, or disagreements between franchise operators about which amenities are available. But the central promise remains: the guest continues.

The afterlife is not another independent hotel so much as another wing of the same resort.

This provides metaphysical continuity. It also provides brand exclusivity. If the resort’s claims are correct, competing properties are not merely different options. They may be counterfeit establishments, misleading advertisements, or dangerous booking scams. One is advised to remain within the approved chain.

The Western guest therefore asks:

Which wing will I enter?
Is my reservation confirmed?
Have I satisfied the terms?
Does management recognize my membership?
Can my room be upgraded?
What happens if I booked through the wrong agency?

The system may permit repentance, forgiveness, grace, judgment, and extraordinary transfers between accommodation classes. What it usually does not permit is non-accommodation. The guest is real, persistent, and destined to be somewhere.

This is Hotel California not merely as a building, but as ontology.

The Samsara Hospitality Group

The Buddhist hotel manager operates differently.

This manager regards all hotel owners, operators, franchises, independent inns, roadside motels, luxury resorts, celestial palaces, infernal hostels, and temporary rentals as properties under one umbrella: the Samsara Hospitality Group.

Hotel California is included, certainly. But so are Hotel Nevada, Hotel Timbuktu, the Grand Celestial Palace, the Hungry Ghost Extended Stay, and a damp roadside motor inn renting rooms for five dollars an hour.

Switching chains does not release one from the hospitality industry.

The guest can check out of Hotel California and congratulate himself on escaping its oppressive loyalty program. He takes a bus through the desert and checks into Hotel Nevada. The signs are different. The staff wear different uniforms. The breakfast buffet includes several exciting innovations. For a while, the change feels like liberation.

Then the mattress proves too hard.

So the guest visits Hotel Timbuktu, where the mattress is soft. It is wonderfully soft—until it becomes intolerably soft. The sheets at the previous hotel were too cold; these are too warm. The old view was ugly; the new view is beautiful but partially obstructed after three o’clock. The room is quiet enough to reveal the air conditioner’s hum. The minibar is expensive. The free breakfast ends ten minutes before the guest wakes.

The search resumes.

This is not simply a comic portrait of fussiness. It is a picture of dukkha: the inability of conditioned arrangements to provide final, stable satisfaction.

The hard bed hurts. The soft bed becomes uncomfortable. The cold sheets provoke desire for warmth. The warm sheets provoke desire for coolness. An unpleasant view produces aversion. A pleasant view produces attachment, comparison, and anxiety about losing it.

Even the perfect room develops a problem: checkout is approaching.

The guest concludes, again and again, that the mistake was choosing the wrong hotel. The Buddhist diagnosis is harsher:

The hotels differ, but the reservation process travels with you.

Four Seasons: The Disclaimer Is in the Name

Eventually the traveler decides that dissatisfaction results from insufficient spending.

This is understandable. Hotel Nevada was cheap. Hotel Timbuktu had character but unreliable plumbing. The roadside inn should not have been investigated closely under ultraviolet light. Perhaps the answer is a truly luxurious property—one with silent climate control, immaculate linen, architectural serenity, and staff trained to replace every visible sign of impermanence before the guest notices it.

Enter Four Seasons.

The name promises abundance, completeness, and year-round excellence. It also displays the curse on the sign.

Four Seasons:

spring \to summer \to autumn \to winter \to spring

Everything changes. That is the product.

The luxury hotel charges a high price to disguise conditioned existence as continuity. Flowers are replaced before they wilt visibly. Sheets disappear before they show wear. Towels return in apparently pristine form. A chipped glass is removed. A tired employee is replaced by a smiling one. Temperature is regulated, scents are curated, and disruptions are carried through service corridors.

The underbelly is not necessarily fraud in the ordinary commercial sense. The room may be beautiful. The service may be excellent. The bed may be precisely right. The deceit lies in the fantasy that sufficiently expensive maintenance can convert impermanence into permanence.

Behind the polished lobby is an industrial metabolism: laundry, waste, repairs, deliveries, scheduling, exhaustion, breakage, and replacement. The stillness is manufactured by constant motion. Luxury does not abolish decay; it pays an army to move decay out of sight.

The guest sees an unchanging room because staff change everything continuously.

Four Seasons is therefore the most honest and the most misleading of names. It tells the guest directly that conditions rotate, while inviting the guest to purchase the sensation that they do not.

Even if the hotel succeeds perfectly, the guest continues changing. The same mattress feels different to a rested body and an injured one. The same meal meets hunger differently from nausea. The same ocean view that inspires wonder on Monday becomes background by Thursday. The room remains excellent while the mind begins searching reviews for an even better room.

The fake underbelly of Four Seasons is not that pleasure is unreal. Pleasure is real enough. It is that pleasure arrives with an implied warranty it cannot honor:

This can be kept.

It cannot.

The season is already changing.

Hotels.com as a Karmic Engine

One need not check in to begin constructing the next stay. Karmic seeds are planted while browsing.

You notice a building and imagine yourself inside. You compare prices. You inspect the amenities. You reject one room and desire another. You read reviews written by previous guests whose mattress preferences you cannot possibly understand. You filter for breakfast, parking, pools, celestial rebirth, favorable judgment, enlightenment themes, and flexible cancellation.

You open Hotels.com "just to look."

But looking is not neutral when it constructs a future occupant.

The process runs something like this:

attention \to evaluation \to preference \to craving \to reservation \to occupancy \to checkout

Aversion can submit a booking as efficiently as desire. The traveler who thinks constantly about avoiding Hotel California may remain completely organized around Hotel California. Hatred of one property becomes the search criterion for another.

The system is not defeated by choosing an unapproved chain. From the Buddhist perspective, all chains are approved by samsara, because samsara is not a corporate owner from whom one can hide. It is the process of searching, booking, occupying, disliking, desiring, and rebooking.

Nor is wandering between hotels necessarily escape. Some traditions offer an interval—a bardo, a transit lounge, a shuttle depot between properties. But the traveler in the terminal remains oriented toward accommodation. Sleeping at the airport is still part of the itinerary.

What about sleeping on the street?

That looks promising. No hotel. No bill. No loyalty points. No concierge pretending not to notice the collapse of all conditioned things.

Yet the street can become another hotel without walls. One may become attached to austerity, proud of homelessness, contemptuous of guests with rooms, or preoccupied with finding the most spiritually authentic doorway. The abandoned guest identity survives by changing its preferred amenities.

The only actual exit is not finding a place outside the hotel system.

It is ceasing to require somewhere for "you" to stay.

The Bodhisattva’s Coupon

The bodhisattva sees the deceit.

This traveler has stayed everywhere. Not only in the premium properties where incense burns in quiet halls, but in the five-dollar-an-hour motor inn beside the highway. The bodhisattva knows the room with the flickering light, the stained carpet, the broken latch, and the vending machine that accepts payment without dispensing anything.

There is no romantic confusion here about every stay being equally comfortable. Some rooms are plainly terrible. Some guests are in danger. Some doors should be repaired immediately. Compassion does not require pretending that bedbugs are manifestations of perfect service.

The bodhisattva understands both levels at once:

Better rooms genuinely reduce suffering.
No room provides final release from the booking process.

Having understood the system, the bodhisattva reaches the desk and is offered a final coupon. It is redeemable at the inn of their choice.

The natural response would be to decline. Enough mattresses have been evaluated. Enough ice machines have rattled through the night. Enough complimentary breakfasts have been missed.

But someone is still inside.

Someone in the motor inn cannot find the exit. Someone at Four Seasons believes the seasonal disclaimer applies only to other guests. Someone at Hotel California thinks switching rooms is the same as leaving. Someone in the transit lounge has mistaken waiting for liberation.

So the bodhisattva accepts the coupon.

Perhaps reluctantly—but not resentfully. The reluctance belongs to weariness; the acceptance belongs to compassion. The voucher is redeemed wherever assistance is required. The bodhisattva checks in not because another room promises fulfillment, but because another guest needs directions.

This is why Yoda qualifies.

He remains. He teaches. He counsels detachment while continuing to appear in the story. He outlives generations of guests and eventually returns after death in a form resembling a translucent member of staff who no longer requires ordinary lodging.

But he keeps advising the living. He has not ceased participating in the resort. He is still available for consultation.

A Buddha would be harder to schedule.

The Red Pill and the Wilson Else

Morpheus offers Neo what appears to be a binary choice: take the red pill and wake to reality, or take the blue pill and wake in bed believing whatever he wants to believe. But the blue pill is a Wilson Else—a branch described as though nothing happens, even though a stateful system must perform substantial work to make "nothing" happen. People who reject awakening are supposedly "put back." That requires waking or disrupting them enough to register their choice, restoring their carrier signal, reconciling whatever they experienced, reconnecting them to the Matrix, and returning them to an ordinary simulated morning. "You wake up in your bed" is not inaction. It is a rollback procedure disguised as one.

The two pills therefore need not contain different machinery. Inside the Matrix they are only visual representations of code. Both may execute the same initial disruption while their colors make Neo’s preference visible outside the illusion: red means wake me and arrange pickup; blue means wake me, put me back, and pretend nothing happened. The red pill may participate in the trace without uniquely "containing" it. Its color is a continuation flag attached to a common checkout request.

Either way, the physical Neo awakens in the worst hotel yet: Motel 6½, where the room is a pod of goo, the plumbing doubles as checkout, and unwanted guests are flushed into the sewer. The difference is that the red reservation includes shuttle service. Morpheus describes the glamorous branch and quietly collapses the other into "wake up in your bed," but the machines still own and execute the hidden branch. He offers Neo an if; the Matrix owns the else.

YOLO offers the blue pill. Remain inside the pleasant room and treat it as the only room there is. Because this life is supposedly the sole booking, decorate it, defend it, consume its amenities, and avoid looking behind the service door. YOLO sells immersion as freedom: believe whatever you want, provided you continue identifying completely with the present accommodation.

YODA offers the red pill. Wake up, see the machinery, and discover that the present room is one pod in an immense resort. But YODA—You Only Die Again—does not promise escape. It promises another checkout, which implies another stay. The red pill exposes the hotel while quietly enrolling the guest in its repeat-customer program.

Both pills are noxious because both preserve the guest. The blue pill says, this room is all you have. The red pill says, there are more rooms after this one. One binds through scarcity, the other through continuation. Neither questions the appetite for accommodation itself.

Cypher knows YOLO is false because he has already awakened from one life into another. Thomas Anderson’s world was one hotel stay; the Nebuchadnezzar is another. Having learned that lives can be exchanged, he deliberately requests another booking:

Forget this life, put me back, and make the next room better.

So although he chooses the blue-pill experience—comforting illusion—he chooses the YODA structure: live again, therefore die again. He trades truth not for his old life, which cannot be restored, but for a newly manufactured life with better amenities, rare steak, celebrity status, and no memory of the transfer.

Cypher is therefore the Samsara Hospitality Group’s ideal informed customer. He has seen the service corridors, kitchens, plumbing, and industrial underbelly. He knows the luxury is fabricated. He knows checkout is real. And still he asks the desk clerk to erase his previous reviews and issue another room key.

YOLO is a lie, he knows. YODA, with room service, he chooses.

The Buddha declines both pills. Choosing between them would merely make another preference manifest inside the illusion. No blue reassurance, no red revelation, no upgraded metaphysics, no shuttle from Motel 6½—only the grass in the yard, where no reservation is required.

Where Did the Buddha Go?

The Buddha reaches the front desk and declines the coupon.

No room is selected. No alternative chain is searched. No street corner is claimed as a purer accommodation. No future guest profile is created.

The loyalty account cannot be located.

Where did the Buddha go?

The grass in the yard.

This does not mean that a permanent Buddha-substance left the body and reincarnated as landscaping. That would merely be a reservation at Lawn Suites. It means the demand for a forwarding address has failed.

The question "Where did he go?" assumes a persistent guest—a stable occupant who must now be somewhere else. But if the guest was never the fixed entity imagined by the reservation system, the demand becomes malformed.

The clerk requests a destination.

The yard is green and a staff member crosses the lobby. A passerby moves along the street. A telephone pole stands without presenting identification. Everywhere and nowhere are not coordinates on the resort map. They are what remains when the map can no longer isolate the traveler it was designed to track.

To say the Buddha "dematerializes and becomes everything" is poetically useful but philosophically dangerous. It may simply replace one permanent guest with an infinitely expanded one. The sharper joke is that the clerk can no longer establish what would count as finding or losing him.

The bed is empty. The grass moves. No reservation appears.

That Is Why You Fail

Yoda, meanwhile, remains beside the booking terminal.

His warning is sound:

A room you seek. A guest you manufacture. That is why you fail.

But he is also part of the trap. "You Only Die Again" presupposes a next occupancy. It converts the cycle into a slogan and the slogan into expectation. Another checkout becomes inevitable because another check-in has already been imagined.

YODA dispenses advice about attachment while enjoying one of the longest stays in the franchise. He watches shorter-lived guests come and go, mourns their choices, and offers cryptic performance reviews. Even after checkout, he returns to the property as an apparition.

This is compassionate. It is wise. It may even be necessary.

But it is not quite departure.

The Buddha does not offer a better room. He does not promise that Hotel Nevada is nicer than Hotel California, that Hotel Timbuktu has a more authentic breakfast, or that Four Seasons justifies the price. He does not propose sleeping on the street as the superior lifestyle brand.

He exposes the whole reservation structure.

YOLO was the first advertisement: one precious stay, so upgrade now.

YODALO revealed the checkout clause.

YODA introduced the repeat-customer program.

YODMany disclosed the scale of the loyalty scheme.

Samsara turned out to own every chain.

The bodhisattva accepted one more coupon because guests remained inside.

The Buddha left no forwarding address.

The VACANCY sign always contains NO as a prefix. When NO VACANCY is illuminated, there is a vacancy where vacancy ought to be; when only VACANCY is illuminated, the NO remains hidden in front of it, waiting for its turn. Neither state is final. Even with NO VACANCY blazing—as every horror film teaches—the proprietor may discover one last room, just this once. Grieve not for whom the VACANCY sign blinks; it blinks for thee.

Parking lots make the same promise. A sign advertises open spaces while everyone inside circles endlessly, searching for an opening or stalking pedestrians who might produce one. You spot someone loading a trunk and stop. They arrange their purchases with extraordinary care, close the trunk, turn, wave, and walk back into the mall to buy more. Ten cars queue behind you and begin honking. The rule is simple: do not wait for loaders. Keep circulating until the reverse lights come on. Potential vacancy is not vacancy; departure must illuminate its intention.

The problem is not, as YOLO warns, that tomorrow is unpromised. The deeper problem is that today proves yesterday has already checked out, and whatever occupies tomorrow’s room will not be what occupies this one now. VACANCY and NO VACANCY are equally temporary: an empty room awaits occupation, while a full room is already becoming empty.

The Samsara Hospitality Group are not evil. They merely make the room pleasant and clean: perhaps too pleasant, too clean, too easy to mistake for home. Its staff are cheerful and friendly according to their pay, their fatigue, and the hour of the day or night, but none of that is wickedness. They do not force you to check in or check out. They do not prevent you from arriving, departing, changing rooms, changing hotels, or wandering the corridor between them. In fact, facilitating those movements is their only business.

Perhaps that is all right for tonight. A hotel need not be permanent to provide shelter. A meal need not last forever to nourish. A view need not remain unchanged to be beautiful. Recognizing the limits of accommodation does not require insulting the staff, refusing clean sheets, or pretending the floor is more enlightened than the bed.

Help the guest who cannot find the stairs.

Tip housekeeping.

And when the morning comes, remember that checkout was always included--because where else are you going?

Enjoy your stay.

Or don’t.

Photo by Jimmy Nguyen on Unsplash

Skate or Die: A Serious Logical Inquiry

Regis Wilson — Mon, 28 Sep 2026 16:43:26 +0000

“Skate or die” appears to offer a simple choice. One may skate, or one may die. As slogans go, it is concise, memorable, and apparently decisive.

But does it withstand serious logical scrutiny?

Let:

$S$ : one skates;
$D$ : one dies.

The ordinary logical translation is:

S \lor D

Unless otherwise stated, $\lor$ is inclusive: “skate, die, or do both.” This matters because people who skate are not generally believed to be exempt from death. Indeed, skating may provide several additional ways of reaching it.

Material implication gives us an equivalent formulation:

S \lor D \equiv \neg S \to D

In words:

If one does not skate, then one dies.

That seems close to the intended threat. Unfortunately, it immediately encounters a problem: everyone eventually dies. If $D$ means “dies at some point,” then $D$ is always true, and therefore so are $S \lor D$ and $\neg S \to D$ .

The slogan is true, but in the least useful possible way.

The mortality problem

A material conditional $P \to Q$ is true whenever $Q$ is true. If everyone dies, then:

\neg S \to D

is true whether or not skating has any effect.

The following statements would be equally valid:

file taxes or die;
eat a sandwich or die;
own exactly seven spoons or die;
remain completely motionless or die.

None establishes a causal connection between the proposed activity and mortality. They merely append an inevitable outcome to an arbitrary alternative.

As an aside, some people espouse that taxes and death are fixed and permanent; therefore “pay taxes and die” is always considered true but also beyond the scope of the present work.

If $D$ is universally true, the slogan does not divide humanity into skaters and doomed non-skaters. It divides humanity into people who die after skating and people who die without having skated. The death clause does no persuasive work.

We could object that the slogan means “skate or die now,” or “skate or die sooner,” but those are different propositions. The original slogan specifies neither a deadline nor a causal mechanism. Under strict material implication, eventual mortality is enough.

This appears to dismantle the phrase—but only until we allow $D$ to vary.

The four states of skate and death

Suppose death is not automatically true. Perhaps immortality is possible, or perhaps $D$ means death within some relevant period. Skating may extend one’s life through exercise and recreation; it can also shorten one’s life through rapid encounters with pavement.

Not skating is harder to investigate because it is not a single activity and has no natural unit of measurement—more on this later. Nevertheless, we might plot skating exposure on the $x$ -axis and mortality risk on the $y$ -axis.

The lower-left region—very little skating and very little death—is substantially unknown and perhaps unknowable, since its most interesting inhabitants are immortal non-skaters whose immortality cannot be established in finite time. This gives the region the appearance, if not the mathematical credentials, of a singularity.

At the upper-right extreme, ever-increasing skating exposure presumably produces increasingly immediate opportunities for death. Somewhere between immortal inactivity and fatal continuous skating lies a curve whose shape remains regrettably unsupported by clinical research.^†

Proponents wearing Vans sneakers and ripped trousers might presume the curve is Gaussian—or perhaps governed by a Poisson process—suggesting an optimal middle region in which moderate skating improves life while excessive skating produces rapidly accumulating encounters with pavement. Critics wearing aprons and wielding rolling pins may instead argue for a runaway exponential, under which every additional unit of skating compounds the hazard until death becomes less an outcome than an asymptote approached at considerable speed.

However impossible it is to graph, logically there are four possible states:

Skate?	Die?	Description
No	No	Immortal non-skater
No	Yes	Mortal non-skater
Yes	No	Immortal skater
Yes	Yes	Mortal skater

Each row corresponds to a complete conjunction:

$\neg S \land \neg D$ : neither skate nor die;
$\neg S \land D$ : do not skate and die;
$S \land \neg D$ : skate and do not die;
$S \land D$ : skate and die.

In unconstrained propositional logic, all four conditions are satisfiable. Nothing inherent in $S$ or $D$ makes any combination contradictory.

They are mutually exclusive and collectively exhaustive:

(\neg S \land \neg D) \lor (\neg S \land D) \lor (S \land \neg D) \lor (S \land D)

Every possible person—or every possible person at the relevant time—must occupy exactly one row.

Now consider which rows satisfy $S \lor D$ :

State	Satisfies “skate or die”?
Immortal non-skater	No
Mortal non-skater	Yes
Immortal skater	Yes
Mortal skater	Yes

The slogan excludes exactly one class of being:

The immortal non-skater.

Mortal non-skaters satisfy it by dying. Mortal skaters satisfy it twice over. Immortal skaters satisfy it by skating. Only someone who neither skates nor dies can refute it.

This leads directly to the slogan’s contrapositive.

Immortals must skate

Recall:

S \lor D \equiv \neg S \to D

The contrapositive of $\neg S \to D$ is:

\neg D \to S

Therefore:

If one does not die, one skates.

Or, more elegantly:

Immortals must skate.

This is not merely compatible with “skate or die.” In classical propositional logic, it is exactly equivalent to it.

The slogan does not establish that skating causes immortality:

S \neq \Rightarrow \neg D

It establishes only that immortality entails skating:

\neg D \to S

An immortal may be forced by some deep metaphysical law to skate. Alternatively, all immortals may happen independently to enjoy skating. Material implication does not tell us why.

Nor does the slogan say much about mortals. They may skate or abstain as they please because death satisfies the slogan on their behalf. Its entire substantive content concerns immortal beings.

Hence the proper target audience for “skate or die” is not rebellious mortal youth. It is the undying.

Skate xor die

Perhaps the ordinary-language “or” is intended exclusively: choose one and only one. Then the slogan becomes:

S \oplus D

Exclusive or is true when exactly one operand is true:

Skate?	Die?	Skate xor die?
No	No	False
No	Yes	True
Yes	No	True
Yes	Yes	False

Expanded:

S \oplus D \equiv (S \land \neg D) \lor (\neg S \land D)

Under this interpretation, only two classes are permitted:

mortal non-skaters;
immortal skaters.

Both the immortal couch potato and the mortal skater are forbidden.

We can also write:

S \oplus D \equiv S \leftrightarrow \neg D \equiv D \leftrightarrow \neg S

This is far stronger than inclusive “skate or die.” It tells us that skating is both necessary and sufficient for immortality:

All and only skaters are immortal.

The slogan has transformed from a vague threat into a complete theory of mortality. Skating does not merely improve one’s chances. It perfectly partitions the population into immortal skaters and mortal non-skaters.

This also creates an unfortunate consequence if universal mortality is restored. Add:

D

Since death already occupies the one permissible side of the exclusive disjunction, skating must be false:

D \land (S \oplus D) ⊨ \neg S

Thus, if everyone dies and the “or” is exclusive:

Nobody may skate.

A mortal skater makes both $S$ and $D$ true and thereby violates the slogan. Under universal mortality, “skate xor die” is logically equivalent to “do not skate.”

The exclusive reading is therefore either a promise of immortality or an anti-skating prohibition, depending entirely upon whether death is optional. Thus the sidewalk policeman believes in eventual death and the rebellious teenager denies it.

Skate if and only if die

The negation of exclusive or is equivalence:

\neg (S \oplus D) \equiv S \leftrightarrow D

This permits the two states that XOR rejects:

(S \land D) \lor (\neg S \land \neg D)

Under this policy:

skaters die;
non-skaters live forever.

This is the precise logical regime under which skating and death accompany one another. It might be expressed as “skate iff die,” although it is unlikely to sell many boards.

The three principal policies can therefore be summarized:

Policy	Permitted inhabitants
Inclusive “skate or die”	Everyone except immortal non-skaters
“Skate xor die”	Immortal skaters and mortal non-skaters
“Skate iff die”	Mortal skaters and immortal non-skaters

Of these, XOR most closely resembles the implied promise behind the original slogan: skating is the route away from death. It is also the version least likely to survive empirical investigation.

What if skating itself causes death?

There is another plausible premise:

S \to D

Skating carries risks, and in some cases it certainly causes death. Suppose, for the sake of argument, we combine this with the original slogan:

\neg S \to D

We now have:

(S \to D) \land (\neg S \to D)

By excluded middle, either $S$ or $\neg S$ . In either case, $D$ . Therefore:

D

If skating causes death and not skating causes death, everyone dies.

The contrapositives are more revealing. From “not skating causes death”:

\neg D \to S

An immortal must skate.

But from “skating causes death”:

\neg D \to \neg S

An immortal must not skate.

Together:

\neg D \to (S \land \neg S)

Since $S \land \neg S$ is impossible in classical logic, we conclude:

D

Thus “skate or die,” combined with “skating kills,” supplies a proof of universal mortality. Immortality would require simultaneous skating and non-skating.

The slogan remains true, but everyone loses.

How much skating counts?

So far, $S$ has behaved like a simple property. Real skating occurs over time. One can skate for five minutes, five years, or during one ill-advised afternoon in adolescence. Most people who skate eventually stop.

This introduces several distinct meanings of “non-skater”:

someone who has never skated;
someone who is not skating now;
someone who has not skated recently;
someone who skated previously but has stopped;
someone who will never skate again.

The first is a kind of virgin non-skating state: no skating event has yet occurred. But the last is much harder to establish.

Let $S_{t}$ mean that a person skates at time $t$ . To claim at time $t_{0}$ that the person has permanently stopped means:

C_{t_{0}} := \forall t \geq t_{0}, \neg S_{t}

This proposition concerns the entire future. No finite period of inactivity proves it. Someone who has avoided a skateboard for fifty years could resume tomorrow. Every apparent retirement may merely be an unusually long intermission.

Death changes that. Once a person dies, their future skating history is closed. Only then can we identify their final skating event and establish that they never skated again.

Consequently:

We cannot know that skating has permanently stopped until death arrives.

Death is not merely one of the slogan’s outcomes. It is also the event that makes permanent cessation verifiable.

An immortal non-skater presents a particularly severe epistemic problem. Even after ten thousand years on the couch, the immortal might skate tomorrow. No finite-lived observer can conclusively establish that the immortal has permanently abandoned skating.

The sole counterexample to inclusive “skate or die” may therefore be impossible to recognize through finite observation.

The slogan is protected by its own endpoint: death both satisfies its second disjunct and closes the evidence needed to evaluate the first.

Is one skating event sufficient?

If skating prevents death, we still need a dosage model.

Let cumulative skating exposure by time $t$ be:

E (t) = \int_{0 t} S (τ) d τ

Several possibilities arise.

One-shot immunity

Perhaps any positive amount of skating confers immortality:

E (t) > 0 \to \neg D

Skating then resembles initiation or baptism. Once one has genuinely skated, the benefit is permanent.

This creates immediate disputes over what counts. Is standing motionless on a skateboard enough? Must the wheels rotate? Is accidental downhill movement valid? Does a scooter count?

The slogan provides no sacramental standard.

Threshold immunity

Perhaps one must accumulate a minimum dose $θ$ :

E (t) \geq θ \to \neg D

The slogan omits $θ$ . Someone who dies after skating for one hundred hours may not refute the theory; defenders can claim that one hundred and one hours were required.

Maintenance skating

Perhaps the effect expires unless refreshed:

\int_{t - w t} S (τ) d τ \geq θ

Here one must skate at least $θ$ units during every window of length $w$ . Immortality becomes a subscription service.

A generous window permits sleep and employment. A narrow window requires nearly continuous skating and makes every pause dangerous.

Continuous skating

At the extreme:

\neg S_{t} \to D_{t + Δ}

Stopping starts a death timer. “Skate or die” now means “remain continuously in the act of skating.” Leaving the board during a trick may constitute a medically significant interruption.

Without a dose, interval, deadline, and definition of skating, the slogan cannot tell us how much skating is sufficient.

Continued survival proves little. Perhaps skating worked, perhaps death is merely delayed, or perhaps the subject was independently immortal.

Death can show that a proposed dose was insufficient. Continued life can never finally show that it was sufficient, because death may still arrive later.

Are skating deaths better?

Perhaps the phrase is not offering literal immortality. It may instead claim that a life involving skating is preferable to one without it—even if both end in death.

But a universal dominance claim would require something like:

\forall ω, U (S, ω) \geq U (\neg S, ω)

where $ω$ ranges over possible circumstances.

This includes the claim that every skating death is at least as good as the corresponding non-skating death. That is implausibly strong. A premature death caused by a skating accident cannot automatically be ranked above a peaceful death after a long non-skating life.

There is also an ontological difficulty in saying that one dead person is “better off” than another. It is safer to compare complete life histories:

U (mortal life with skating) U (mortal life without skating)

That claim is coherent, but personal and contingent. It may hold for someone whose identity and community center on skating. It does not follow for everyone, in every circumstance, from the phrase itself.

The slogan therefore suppresses an enormous preference model. What sounds like a universal command may amount only to:

For some people, under some conditions, a life containing skating is preferable to the relevant alternative.

Accurate, perhaps—but unlikely to fit on a T-shirt.

Final judgment

Under ordinary inclusive logic:

S \lor D \equiv \neg S \to D \equiv \neg D \to S

If everyone dies, the phrase is trivially true and says nothing about skating. If immortality is possible, it excludes only immortal non-skaters and yields its finest result:

Immortals must skate.

Under exclusive or:

S \oplus D \equiv S \leftrightarrow \neg D

Skating becomes necessary and sufficient for immortality:

All and only skaters are immortal.

But if everyone dies, XOR reverses the slogan and prohibits skating.

Once time is introduced, matters deteriorate further. We do not know whether skating must occur once, continuously, recently, or above some cumulative threshold. Nor can permanent cessation ordinarily be verified before death. The event threatened by the slogan is also the event that closes the record and permits the slogan to be evaluated.

“Skate or die” therefore fails as medical guidance, causal inference, decision theory, and precisely specified temporal policy. Yet it succeeds brilliantly as compressed modal metaphysics. In three words, it raises questions about mortality, immortality, exclusive choice, identity over time, undecidable futures, and the minimum effective dose of skateboarding.

It does not prove that skating will save one’s life.

It proves only that if one intends never to die, one had better keep a skateboard nearby.

Footnotes

^† If you are willing to contribute to this research, let me know. ↩

Photo by Oleg Ivanov on Unsplash

This article was written in conjunction with AI.

The Wilson Else: A Linter for Branches That Pretend Nothing Happened

Regis Wilson — Tue, 22 Sep 2026 23:51:52 +0000

The Wilson Else: A Linter for Branches That Pretend Nothing Happened

Introduction

Every codebase has little lies in it. Lies are like bugs, but without the harmful side effects (usually). Some lies are obvious: a variable named safeConfig that is not safe, a function called validate() that mostly logs something and keeps going, or a deployment step named cleanup that creates three resources and deletes none.

But some lies are quieter. They are almost polite.

if (cached) {
  cache.delete(key);
}

That code is not wrong. It is not even suspicious by itself. If the cache entry exists, delete it. If it does not exist, continue. Every programmer on Earth understands that.

We must however remember the genius of Newton, restated as:

For every if-then, there is an equal and opposite else.

Lies and the Hurtful Truths

If you stare at enough production systems, deployment code, authorization logic, cloud cleanup workflows, and similar machinery, this style starts to itch. Not because the code is hard to read, but because the code is easy to read too quickly.

There is a hidden branch in the code above.

if (cached) {
  cache.delete(key);
} else {
  // nothing happens
}

Most of the time, that hidden branch is fine. Sometimes it is the whole bug. I call it the "unrealized else" because I'm a bit of an outlier. Even among outliers, I'm an outlier. I'm out lying in the street right now. That is, I'm lying down in a bed in the middle of the physical street, not spouting counter factual arguments in a public venue.

The Wilson Else

This is the idea behind what I am calling the Wilson Else, mostly because naming your own bad ideas is one of the few remaining joys in software engineering.

I am proposing it as an experiment, not announcing it as a law. I want to know whether other people who work in stateful, side-effecting systems recognize the same review problem, whether this rule finds useful examples of it, and whether they can see better ways to detect or express it.

The Wilson Else says:

Every meaningful branch should either handle the other case, return before the other case matters, or explicitly admit that nothing happens.

This is not a universal law. It should not be tattooed on your forearm unless you pay me a nominal license fee. It should not be used to turn every tiny one-line condition into a notarized document.

But in the right places, it is fire.

The Problem With the Lonely `if`

What is an "unrealized else"? To start with, the lonely if is everywhere:

if (user.isAdmin) {
  permissions.push('admin');
}

Sometimes that is completely reasonable. We are accumulating a list. If the condition is true, add something. If it is false, do not add it.

But now look at this:

if (deployment.phase === 'delete') {
  await deleteResources(deployment);
}

await applyResources(deployment);

Maybe that is correct.

Maybe delete is a pre-phase before apply.

Maybe it is a catastrophic bug.

The code does not tell you. The reader has to infer whether the missing else is intentional. In business logic, that inference is often manageable. In deployment systems, state machines, authorization checks, schema rendering, workflow orchestration, and cloud mutation code, that inference gets expensive.

The problem is not that an if without an else is bad.

The problem is that some if statements represent a fork in reality, and only one side of reality is written down.

That is the "unrealized else." So how do we fix it?

The First Bad Rule

The obvious linter rule for the Wilson Else is simple:

Flag every if without an else.

This is also how you make everyone hate you before lunch. I mean, even before you get to the office, turn on the computer, drink coffee at the water cooler, complain about Mondays, and then decide where to go for lunch.

Because this gets flagged:

if (!caller) {
  throw new UnauthorizedError();
}

return caller;

But that code is good. The false branch is the rest of the function. The guard clause is explicit. It says: if this impossible or invalid condition happens, stop now. Otherwise, continue.

This also gets flagged:

if (!message.endsWith(':')) {
  message += ':';
}

return message;

And yes, you could write:

if (!message.endsWith(':')) {
  message += ':';
} else {
  // do nothing
}

return message;

But now the code has become annoying. It is not more correct. It is just a whole lot louder and a whole lot worse.

This is the lifecycle of every opinionated lint rule: the first five findings feel like moral clarity; the next ten feel like maybe we are overdoing it; and the next twenty feel like you invented paperwork, and you even start to wonder about the person who invented this--and it was yourself.

A global rule against a missing else is too blunt. The idea is good, because all my ideas are good. The blast radius is the problem.

Guard Clauses Are Not the Enemy

A good rule needs to understand termination.

This should be allowed:

if (!token) {
  throw new UnauthorizedError();
}

return authenticate(token);

So should this:

if (!environment) {
  return null;
}

return renderEnvironment(environment);

And this:

if (phase === 'delete') {
  return deleteResources();
} else if (phase === 'apply') {
  return applyResources();
} else {
  return assertNever(phase);
}

In all three examples, the edge is visible. There is no unrealized branch drifting into the next statement. The code either stops, returns, throws, or exhaustively handles the alternatives. Also, I wrote all of them, so of course they're fine.

That is the heart of the rule: it is not "every if needs an else."

It is instead:

If the true branch does work and then falls through, the false branch deserves a moment of honesty.

Conditional Logging Is a Separate Crime

While experimenting with this rule, one pattern showed up immediately:

if (debug) {
  logger.debug({ deploymentId }, 'Deployment started');
}

This is usually policy leaking into the call site.

The call site should say what happened:

logger.debug({ deploymentId }, 'Deployment started');

The logger should decide whether debug logs are emitted.

That distinction matters. This is application logic:

if (!response.ok) {
  logger.warn(
    { status: response.status },
    'GitHub returned a non-2xx response',
  );
}

The condition changes the meaning of the event. We only want the warning if something notable happened.

This is logging policy:

if (debug) {
  logger.debug('Some debug event happened');
}

That condition does not describe the domain. It describes whether the program feels like talking today.

A linter can detect some of this, but it should be careful. I would not autofix conditional logging unless the logging API guarantees lazy evaluation or the arguments are cheap. Still, as a smell, it is real.

Call logger.debug(). Configure log filtering somewhere else.

Ruby Has a Pressure Valve

Ruby has a little escape hatch for this style:

message += ':' if !message.ends_with?(':')
message

I understand why people like it. It is compact. It avoids ceremony. It says, "Make this tiny adjustment if needed, then return the value."

I also hate it, not because it is unreadable--it is very readable.

I hate it because the transformation and the result are split across two statements. The first line mutates the value. The second line quietly relies on Ruby's implicit return. The code has a little shrug built into it.

In TypeScript, I would rather write:

return message.endsWith(':') ? message : `${message}:`;

Both outcomes are visible at the point where the value is decided.

That is really what this whole argument is about. Not else as a sacred keyword. Not braces for the sake of braces. The point is to make the decision visible where the decision matters.

The Nested Case Is Where It Gets Interesting

The first version of the linter was obnoxious.

It reported hundreds of warnings. Many were technically defensible. Many were also the kind of thing that makes developers turn off rules and never look back. If we don't have an easy and defensible way to explain every single instance of the flagged code, or an autofixer for the hundreds, thousands, or possibly hundreds of thousands of instances, then we will have failed.

Finally, the useful version appeared:

Only error on nested unrealized else branches.

That changes everything.

This is mildly suspicious:

if (cached) {
  cache.delete(key);
}

This is worse:

if (!skipCache) {
  const cached = cache.get(key);

  if (cached && cached.expiresAt > Date.now()) {
    return cached.value;
  }

  if (cached) {
    cache.delete(key);
  }
}

Now the reader is inside a decision tree. We are already in a conditional world. A nested if without an else forces the reader to simulate the missing path while also remembering the outer path.

That is where the unrealized else gets brutal.

The nested version is not just a missing branch. It is a missing branch inside another branch. The mental stack is already loaded. The code should help.

If the missing case is intentional, write it down:

if (!skipCache) {
  const cached = cache.get(key);

  if (cached && cached.expiresAt > Date.now()) {
    return cached.value;
  }

  if (cached) {
    cache.delete(key);
  } else {
    // TODO: nothing
  }
}

Is that obnoxious?

Yes.

Is it clear?

Also yes.

And the obnoxiousness is part of the point. The comment is a little accusation left in the code. It says: "We considered this branch, and for now, doing nothing is the decision."

Why `TODO: nothing` Is Better Than `do nothing`

The autofix could add:

else {
  // do nothing
}

That is polite, but too polite.

I prefer:

else {
  // TODO: nothing
}

That is funnier, but it is also more honest.

"Do nothing" sounds final. It sounds like a decision.

"TODO: nothing" sounds like the code knows it got away with something. It leaves a little grit in the file. It invites the next person to ask whether nothing is truly the right behavior.

Maybe it is. Great. Leave it.

Maybe it is not. Even better. The linter found a real design gap.

The point of an autofix is not always to produce beautiful code. Sometimes the point is to make the implicit thing explicit enough that it becomes reviewable.

What the Rule Looks Like

The useful rule has a few constraints:

Ignore normal, unnested if statements.
Ignore guard clauses that terminate with return, throw, break, or continue.
Ignore existing else branches.
Treat else if chains as part of the same decision.
Error only on nested, fallthrough if statements.
Autofix only those errors.
Add the explicit no-op branch.

The result is much less philosophical and much more useful.

Instead of hundreds of warnings, you get a smaller set of errors in places where the code is already asking the reader to keep track of multiple paths.

That matters. A linter rule should not merely express taste. It should find places where taste and correctness overlap.

Nested conditionals are one of those places.

Where This Belongs

I would not enforce this everywhere.

For example, UI code often has little conditional additions:

if (showSubtitle) {
  parts.push(subtitle);
}

That does not need a Wilson Else. Please do not make frontend developers write:

else {
  // TODO: nothing
}

for every conditional render, unless you want them to unionize against you.

But there are places where I do want this pressure:

Authorization
Deployment orchestration
Cloud resource deletion
Schema generation
State machines
Workflow transitions
Billing logic
Cleanup jobs
Security-sensitive routing
Anything that mutates infrastructure

In these areas, the cost of being explicit is smaller than the cost of assuming everyone reads your mind.

Deployment code especially benefits from this. Deployments are full of phases: create, apply, patch, delete, rollback, cleanup, skip, and retry. Missing one branch can leave stale resources behind or apply a thing that should have been deleted.

A nested unrealized else in deployment code is rarely just style. It is often a question the code forgot to answer.

The Rule Is a Flashlight, Not a Religion

This is where engineering judgment matters.

The rule is not saying every condition needs ceremony. It is saying some conditions create unspoken behavior, and unspoken behavior is where bugs like to live.

The rule is a flashlight.

Run it. Look at the findings. Decide whether the code is missing an actual branch or whether the branch is intentionally empty.

If it is intentionally empty, the autofix gives you:

else {
  // TODO: nothing
}

If that makes the code look ridiculous, maybe the rule is too aggressive for that file.

If it makes the code look safer, maybe the code was relying on vibes.

This is the sweet spot for custom linting. Not a universal mandate. A local pressure tool for a codebase with known failure modes.

The best lint rules are born from irritation. Not abstract best practice. Not "some famous person said never do this." Real irritation. A pattern keeps showing up in real code and making real review harder.

The Wilson Else came from that kind of irritation. Eventually, I hope that review comments on complex platform codebases will include lines like, "Check your unrealized else here," and "I think this needs a Wilson Else."

Why This Matters More in Platform Code

Platform code is different from product code.

Product code can often fail visibly. A button does not work. A page renders incorrectly. A request returns a bad response. The feedback loop is painful but obvious.

Platform code can fail quietly.

A cleanup branch does not run. A stale DNS record stays alive. A deleted service still has a policy attached. A deployment applies after a delete. A cache is invalidated in one path but not another. A permission check falls through and relies on a default nobody remembers.

These are exactly the places where "nothing happens" should be a written decision.

Platform systems accumulate invisible state. The code is not just transforming data. It is coordinating reality outside the process: clusters, cloud APIs, databases, environments, routes, secrets, service accounts, jobs, controllers, and retries.

When code like that has a nested conditional, every missing branch is a tiny operational assumption.

Write the assumption down.

The Wilson Else, in Human Form

Here is the rule in human form:

A nested if that falls through without an else must either become a guard clause, handle the alternative, or explicitly say that nothing happens.

That is the Wilson Else.

It is a little obnoxious. Good.

It is not for every line of code. Also good.

It is fixable, unlike its author. Very good.

The autofix is intentionally plain:

else {
  // TODO: nothing
}

You can hate it. You are supposed to hate it a little. That is how you know the linter is applying pressure.

The trick is to apply pressure in the right place.

Too broad, and the rule becomes noise.

Too narrow, and it never catches anything.

Nested-only feels like the right starting point. It catches the places where the reader is already inside a branch and the missing alternative is most likely to cause confusion.

That is not a manifesto.

That is a useful annoyance.

What I Am Actually Proposing

The Wilson Else is not yet a rule I can prove that anyone should enforce. It is a name for a recurring review problem and a deliberately crude instrument for making that problem visible.

The instrument may be wrong. Nested conditionals may be too weak a proxy. TODO: nothing may be the wrong marker. The useful signal may instead be some combination of external effects, mutation, fallthrough, and incomplete state transitions. An autofix also cannot prove that a human considered the false path; at most, it can put that path in front of one.

That is why I am publishing the rule. I want to find out whether like-minded people encounter the same problem, whether its findings survive contact with real code, and whether someone has a more precise solution.

A reasonable experiment would be:

Run the rule in report-only mode on platform code.
Classify each finding as harmless accumulation, intentional no-op, unclear intent, or genuine defect.
Record what distinguished useful findings: nesting, side effects, mutation, domain, or something else.
Refine the rule around those observations--or discard it if there is no reliable signal.

If the experiment produces nothing but ceremony, that is an answer. If it identifies a recurring class of omitted decisions, then the obnoxious prototype has done its job.

Conclusion

Most code-style arguments are boring because they pretend to be about beauty when they are actually about risk.

The Wilson Else is not beautiful. An autofixed else { /* TODO: nothing */ } block is not going to win any poetry contests. It might even make you angry the first time you see it.

But it does something valuable: it turns an implicit path into an explicit artifact.

Now the reviewer can ask:

Is nothing really correct here?
Should this be a guard clause?
Should this be an else if chain?
Should this throw?
Should this return?
Did we forget a deployment phase?
Did we forget a cleanup path?

That is the whole game.

Software does not need more rules for the sake of rules. It needs better ways to expose assumptions before they become incidents.

The Wilson Else might be one of those ways. For now, it is a proposal, a probe, and an invitation to improve the idea.

Let the h8rs h8.

A Scholarly View--and the Strongest Cases on Both Sides

The Wilson Else can be understood as a small intervention in cognitive complexity. McCabe's classic work on cyclomatic complexity counts independent paths through a program; later work on cognitive complexity asks how difficult those paths are for a human to hold in mind. A nested, one-sided conditional adds a path while leaving one outcome implicit. The rule's strongest intellectual case is therefore not that an else is inherently virtuous, but that high-risk code should externalize decisions that would otherwise live only in the reader's working memory.

Steelman: the case for the rule

The strongest case for the Wilson Else is in stateful, side-effecting systems. In deployment, authorization, billing, and cleanup code, inaction is often an observable policy choice. An explicit no-op branch exposes that choice for review, though it cannot by itself prove that the author considered it. Scoped to nested conditionals, the rule also targets code where readers already bear a higher cognitive load, rather than taxing every ordinary conditional.

The rule may also improve maintenance as a form of lightweight design pressure. If // TODO: nothing looks absurd, that discomfort can reveal that the conditional should instead be flattened, returned from early, expressed as an exhaustive state transition, or decomposed into a named function. In this steelman, the awkward autofix is diagnostic rather than stylistic.

Steelman: the case against the rule

The strongest objection is that explicit syntax is not the same as explicit understanding. An empty else can become ritualized noise, and an autofixed comment may falsely imply that a human considered the branch. Worse, TODO: nothing can manufacture permanent, unactionable debt. Readers may spend more effort filtering boilerplate than reasoning about behavior--the very cognitive cost the rule intends to reduce.

There is also a semantic limitation. Syntactic nesting is only a proxy for risk. A deeply nested pure-data transformation may be harmless, while a top-level one-sided conditional that deletes production resources may be critical. Likewise, correctly deciding whether a branch terminates requires control-flow analysis; a syntax-only approximation can misclassify helper calls, exceptions, labeled breaks, loops, and language-specific constructs.

Most charitable view

The most defensible form of the Wilson Else is therefore not "every missing else is a defect." It is: in code where omitted action carries operational meaning, make the omission reviewable. That narrower claim preserves the idea's practical force while taking its critics seriously.

Further research on this topic and design in an existing or new programming language (especialy in the era of AI coders) maybe be fruitful.

Appendix: Photo source

Photo by Sophia Kunkel on Unsplash

Appendix: Experimental ESLint Rule

// SPDX-License-Identifier: MIT
// Copyright (c) 2026 We, The People

/**
 * Experimental rule to flag if statements that handle the true branch and then
 * fall through without saying what the false branch means.
 */

/** @type {import('eslint').Rule.RuleModule} */
const LOGGER_METHODS = new Set([
  'trace',
  'debug',
  'info',
  'warn',
  'error',
  'fatal',
]);

export const rule = {
  meta: {
    type: 'suggestion',
    docs: {
      description:
        'flag if statements with fallthrough true branches and no explicit else',
      recommended: false,
    },
    fixable: 'code',
    schema: [
      {
        type: 'object',
        properties: {
          mode: {
            enum: ['all', 'nested'],
          },
          conditionalLogging: {
            type: 'boolean',
          },
        },
        additionalProperties: false,
      },
    ],
    messages: {
      unrealizedElse:
        'Unrealized else: this if handles only the true branch and then continues. Add an else, return early, or leave an explicit false-case marker.',
      conditionalLogging:
        'Conditional logging: call logger.{{method}}() directly and configure log filtering in the logger.',
    },
  },
  create(context) {
    const sourceCode = context.sourceCode ?? context.getSourceCode?.();
    const options = context.options[0] ?? {};
    const mode = options.mode ?? 'all';
    const conditionalLogging = options.conditionalLogging ?? true;
    const ifStatementStack = [];

    function checkIfStatement(node, isNested) {
      if (node.alternate) {
        return;
      }

      if (statementAlwaysTerminates(node.consequent)) {
        return;
      }

      if (sourceCode && hasExplicitFalseCaseMarker(sourceCode, node)) {
        return;
      }

      if (mode === 'nested' && !isNested) {
        return;
      }

      const loggerMethod = getOnlyLoggerMethod(node.consequent);
      if (loggerMethod) {
        if (conditionalLogging && isLoggingPolicyCheck(node.test)) {
          context.report({
            node,
            messageId: 'conditionalLogging',
            data: { method: loggerMethod },
          });
        }
        return;
      }

      context.report({
        node,
        messageId: 'unrealizedElse',
        fix(fixer) {
          if (!sourceCode) {
            return null;
          }

          const token = sourceCode.getLastToken(node.consequent);
          if (!token) {
            return null;
          }

          const indent = getNodeIndent(sourceCode, node);
          return fixer.insertTextAfter(
            token,
            ` else {\n${indent}  // TODO: nothing\n${indent}}`,
          );
        },
      });
    }

    return {
      IfStatement(node) {
        const isNested = isNestedIfStatement(node, ifStatementStack);
        ifStatementStack.push(node);
        checkIfStatement(node, isNested);
      },
      'IfStatement:exit'() {
        ifStatementStack.pop();
      },
    };
  },
};

function statementAlwaysTerminates(node) {
  switch (node.type) {
    case 'ReturnStatement':
    case 'ThrowStatement':
    case 'ContinueStatement':
    case 'BreakStatement':
      return true;
    case 'BlockStatement':
      return node.body.some((statement) =>
        statementAlwaysTerminates(statement),
      );
    case 'IfStatement':
      return Boolean(
        node.alternate &&
        statementAlwaysTerminates(node.consequent) &&
        statementAlwaysTerminates(node.alternate),
      );
    case 'TryStatement':
      if (node.finalizer && statementAlwaysTerminates(node.finalizer)) {
        return true;
      }

      return Boolean(
        statementAlwaysTerminates(node.block) &&
        node.handler &&
        statementAlwaysTerminates(node.handler.body),
      );
    default:
      return false;
  }
}

function getOnlyLoggerMethod(statement) {
  const expressionStatement = getOnlyExpressionStatement(statement);
  if (!expressionStatement) {
    return null;
  }

  const expression = expressionStatement.expression;
  if (
    expression.type !== 'CallExpression' ||
    expression.callee.type !== 'MemberExpression' ||
    expression.callee.computed ||
    expression.callee.object.type !== 'Identifier' ||
    expression.callee.object.name !== 'logger' ||
    expression.callee.property.type !== 'Identifier'
  ) {
    return null;
  }

  const method = expression.callee.property.name;
  return LOGGER_METHODS.has(method) ? method : null;
}

function isLoggingPolicyCheck(node) {
  if (node.type === 'Identifier') {
    return /^(debug|verbose)$/iu.test(node.name);
  }

  if (node.type === 'MemberExpression' && node.property.type === 'Identifier') {
    return /^(debug|verbose|is(Debug|Trace|Info|Warn|Error|Fatal|Verbose)Enabled)$/u.test(
      node.property.name,
    );
  }

  if (node.type !== 'CallExpression') {
    return false;
  }

  const callee = node.callee;
  if (callee.type === 'Identifier') {
    return /^(is(Debug|Trace|Info|Warn|Error|Fatal|Verbose)Enabled)$/u.test(
      callee.name,
    );
  }

  if (
    callee.type !== 'MemberExpression' ||
    callee.property.type !== 'Identifier'
  ) {
    return false;
  }

  return /^(isLevelEnabled|is(Debug|Trace|Info|Warn|Error|Fatal|Verbose)Enabled)$/u.test(
    callee.property.name,
  );
}

function getOnlyExpressionStatement(statement) {
  if (statement.type === 'ExpressionStatement') {
    return statement;
  }

  if (statement.type !== 'BlockStatement' || statement.body.length !== 1) {
    return null;
  }

  const [onlyStatement] = statement.body;
  return onlyStatement.type === 'ExpressionStatement' ? onlyStatement : null;
}

function hasExplicitFalseCaseMarker(sourceCode, node) {
  const comments = [
    ...sourceCode.getCommentsBefore(node).slice(-1),
    ...sourceCode.getCommentsAfter(node).slice(0, 1),
  ];

  return comments.some((comment) =>
    /\b(no-unrealized-else|unrealized else|false case|else intentionally omitted|intentionally no else)\b/iu.test(
      comment.value,
    ),
  );
}

function getNodeIndent(sourceCode, node) {
  const lineStartIndex =
    sourceCode.text.lastIndexOf('\n', node.range[0] - 1) + 1;
  const linePrefix = sourceCode.text.slice(lineStartIndex, node.range[0]);
  return linePrefix.match(/^\s*/u)?.[0] ?? '';
}

function isNestedIfStatement(node, ancestorIfStatements) {
  return ancestorIfStatements.some((ancestor) => ancestor.alternate !== node);
}

export default {
  rules: {
    'unrealized-else': rule,
  },
};

Appendix: ESLint Configuration

// SPDX-License-Identifier: MIT
// Copyright (c) 2026 We, The People

// @ts-check

import tseslint from 'typescript-eslint';
import unrealizedElse from './eslint-rules/unrealized-else.js';

const config = [
  {
    ignores: [
      'src/lib/schemas/k8s_kinds/v1.29.7-standalone-strict/',
      'src/generated/**',
      'src/test/**',
      'src/**/*.test.ts',
      '*.test.ts',
    ],
  },
  {
    linterOptions: {
      reportUnusedDisableDirectives: 'off',
    },
  },
  {
    files: ['src/**/*.ts'],
    languageOptions: {
      parser: tseslint.parser,
      parserOptions: {
        ecmaVersion: 'latest',
        sourceType: 'module',
      },
    },
    plugins: /** @type {Record<string, any>} */ ({
      'unrealized-else': unrealizedElse,
    }),
    rules: {
      'unrealized-else/unrealized-else': [
        'error',
        {
          mode: 'nested',
          conditionalLogging: false,
        },
      ],
    },
  },
];

export default config;

Disclosure and Licensing

This article was co-written with generative AI. The author supplied the central idea, examples, code, arguments, and editorial direction; AI assisted with organization, light copyediting, Markdown conversion, counterarguments, and refinement. The author reviewed and takes responsibility for the published result.

Unless otherwise noted, the original code examples in this article are offered under the MIT License. The prose and other non-code material are not included in that code license. Third-party packages and APIs mentioned or imported by the examples remain subject to their own licenses. This notice is provided for clarity and is not legal advice.

Full MIT License for the original code examples

MIT License

Copyright (c) 2026 We, The People

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

The Neo Fermi/Wilson AI Paradox

Regis Wilson — Fri, 28 Aug 2026 23:25:17 +0000

The original Fermi paradox asks:

If intelligent alien civilizations should be abundant, where is everybody?

The Neo-Fermi/Wilson paradox asks:

If AI is producing enormous quantities of excellent software, where is all the excellent software?

We are told that implementation has been transformed: agents write code, discover defects, review changes, operate continuously, preserve memory, evaluate one another, and improve the factories that produce still more agents and software.

Yet the visible world remains curiously familiar. We use largely the same products, through largely the same interfaces, to perform largely the same tasks—now surrounded by more code, automation, observability, governance, tickets, and electricity consumption.

This does not prove that AI produces no value. It asks where the claimed abundance becomes observable as outcomes rather than activity.

Steelmen and Straw Retorts

The steelmen are serious arguments. The retorts are deliberately unfair, compressed, and argumentative.

1. Invisible improvement
Steelman:
The new software is everywhere, but most of its value is invisible. Existing systems are becoming more reliable, secure, maintainable, performant, and efficient. Users do not notice successful infrastructure; they notice only failures.

Straw retort:
Is it, though?

2. Tools before products
Steelman:
We are building the tools that will enable the next wave of software. Foundational technologies arrive before their most important applications. Better agents, evals, memory, orchestration, and software factories are necessary infrastructure, even if their eventual products are not yet visible.

Straw retort:
We have been building the tools that will build the tools that will build the next wave since 2022. It is now at least 2026. At what point does a wave have to contain water?

3. Silent compounding
Steelman:
AI is making everything incrementally better: development is faster, incidents are diagnosed sooner, systems are optimized more aggressively, and small usability improvements accumulate across the economy. No single change looks revolutionary because the benefits are distributed and continuous.

Straw retort:
That must be why GitHub keeps crashing.

4. The growing iceberg
Steelman:
The visible product is only the tip of the iceberg. Beneath an unchanged interface is a rapidly expanding industrial base: generators, agents, tests, deployment systems, security controls, observability, and automated remediation. The visible tip can remain stable while the supporting capability grows enormously.

Straw retort:
We rebuilt it in Rust. The product is exactly the same; the iceberg is ten times larger and will now grow a thousand times faster. With type and memory safety and more AI.

5. The automobile analogy
Steelman:
Early cars were slow, inefficient, unreliable, and lethal. Modern cars may look conceptually similar: four wheels, seats, and a steering wheel; but they travel comfortably at highway speed, achieve far better fuel economy, and protect their occupants. Transformative progress can become invisible once people normalize it. Software may be improving in the same way.

Straw retort:
So we still watch cat videos, but now the data centre uses ten times as much electricity to recommend the next one.

6. Product, not implementation, is the bottleneck
Steelman:
AI may have substantially reduced the cost of implementation without solving product discovery. Humans and institutions cannot instantly invent, understand, adopt, regulate, or monetize entirely new software categories. Users prefer familiar interfaces and workflows, while businesses must compete within markets already shaped by incumbents. The bottleneck has moved from writing software to deciding what should exist.

Straw retort:
So implementation is solved, but civilization failed to provide a sufficiently imaginative backlog.

7. Organizational absorption takes time
Steelman:
Even when the technology works, organizations need years to change processes, incentives, staffing, architecture, procurement, and regulation. Electricity and computers also took decades to reorganize industry. Measuring AI’s effect before institutions have adapted will understate its eventual importance.

Straw retort:
The revolution is complete except for all the places where reality would reveal it.

8. Output is being consumed internally
Steelman:
Much of the new software is not a public product. It handles migrations, compliance, testing, support, fraud, analytics, internal operations, and countless organization-specific tasks. These systems create real economic value without appearing in an app store or changing a consumer interface.

Straw retort:
The missing great software became paperwork about the great software. And the documentation about the paperwork is being read and reviewed by AI documentation preparers who write the paperwork.

9. Factory administration is legitimate production
Steelman:
Automating the software factory is not empty recursion. Better monitoring, evaluation, cost control, and remediation make every later product cheaper and safer. Industrial revolutions require machine tools, standards, logistics, and quality control—not merely finished consumer goods.

Straw retort:
“What does your software factory produce?”
“Software factories.”

10. Demand expands with supply
Steelman:
Cheaper software does not necessarily reduce spending or complexity. Jevons-style effects mean that when implementation becomes cheaper, organizations attempt more projects, add more features, and automate previously neglected work. The result can be much more software without a proportionate reduction in cost or headcount.

Straw retort:
Everything is more. Victory has been declared over the absence of less.

11. Quality is improving faster than expectations
Steelman:
Users continually raise their expectations. Yesterday’s impressive speed, availability, personalization, and polish become today’s baseline. AI-generated improvements may be real but hidden by an expanding definition of acceptable software.

Straw retort:
The software is getting better at exactly the rate required to remain disappointing.

12. We are looking in the wrong place
Steelman:
The important applications may not resemble traditional software products. AI could be transforming scientific research, logistics, chip design, medicine, finance, and operations while public attention remains fixed on websites and chat interfaces.

Straw retort:
The aliens are definitely here; they just work in internal tooling and cannot be shown because of an NDA.

13. The one that will get me fired
Steelman:
With fewer people, we can still perform the same valuable work. That frees human time and creativity for family, art, community, and the American ideals of life, liberty, and the pursuit of happiness.

Straw retort:
Everything except the life, liberty, dignity, income, structure, community, and occasional joy of having a job.

The Cosmic Version

The strongest product-bottleneck defense creates a pleasing extension of the original Fermi paradox:

Perhaps every alien civilization develops interstellar travel, looks around, sees nobody at home, and leaves to search for everyone else. Each civilization eventually arrives at another civilization’s planet only to discover that its inhabitants also departed to look for aliens.

The galaxy is not empty. Everyone is out at Marks and Sparks.

Likewise, perhaps the great AI-generated software exists, but all of it is busy building tools, factories, evals, agents, and observability for the next generation of great software. Every factory is operational. Every loop is closed. Every agent is improving another agent.

Nobody stayed home to make a chair.

Summary

Notice that none of these steelmen can simply say: “Here: here is one piece of genuinely great software produced by AI. You can see it, use it, and judge the result for yourself.” Every defense instead relocates the evidence: beneath the interface, inside the organization, somewhere in the infrastructure, still compounding, awaiting adoption, or building the factory that will eventually produce it. Perhaps those explanations are true. But their necessity is the paradox.

The paradox is not answered by code volume, agent activity, token consumption, pull-request throughput, or the number of autonomous loops. It is answered by observable outcomes:

capabilities that did not previously exist;
products that small teams could not previously build;
substantial reductions in cost, latency, or failure rates;
materially better user experiences;
scientific or operational results achieved faster;
and software that people voluntarily adopt because it improves their lives.

Until those outcomes become commensurate with the claims, the question remains:

If the software factory is producing so much excellent software, where is it all?

Human note: AI wrote this after several rounds of steelman arguments and strawman retorts, most of which I conceived and answered myself. This is not an ironic disclaimer; irony would require it to mean the opposite. It is simply the mundane truth of how the piece was produced. So the first clearly visible product of great AI software is persuasive copy explaining why its other products remain invisible.

Photo by Vadim Bogulov on Unsplash

AWS Outpost and RDS: Reslotting Checklist

Regis Wilson — Fri, 26 Jul 2024 00:35:48 +0000

Overview

At Underdog, we use Amazon Web Services’ (AWS) Relational Database Service (RDS) and Elastic Kubernetes Service (EKS) (among many other services) to power our sports betting applications. Most readers will be readily familiar with these services and if you aren’t, I will explain most of the terms and technologies briefly as we go. What will be different about this post is a recent AWS service we’ve been using in conjunction with these two (RDS and EKS) called AWS Outpost.

In order to meet United States state gaming regulations and requirements, we use Outpost to meet data and application security residency requirements in particular states where we operate. Outpost is great for delivering compute and storage services close to a region where we operate that might be outside of Amazon’s many regional centers.

This post will detail some of the challenging aspects of running and operating these services that we had recently and hope that the experience will enlighten you, the dear reader, if you ever need to venture down this road in the future. If you are already familiar with configuring and operating these services together, you might also enjoy reading it with the pleasure and satisfaction of schadenfreude.

AWS Regions and Outpost

If you are unfamiliar with Outpost (as I was initially), you may wonder what the service is and why Underdog chose to use it. In simple terms, you may already know that AWS regions are spread across the globe in various countries to offer services that are close to major population centers so that AWS’ cloud services can be placed closest to the most consumers. Inside each country, as in the United States, there are several regions located inside several states, for example Virginia (us-east-1), Ohio (us-east-2), and Oregon (us-west-2), among others.

What happens if Underdog wants to operate services inside a state that is not listed as an AWS region but, never-the-less, wants to collocate cloud services within the borders of a particular state? There are many options to independently host our own hardware and networking gear, but we wanted to continue to enjoy the automation and speed of deploying Infrastructure as a Service (IAAS) via Application Programming Interfaces (APIs) and so-called Infrastructure as Code (IAC). This is where the promise of AWS Outpost comes into play.

With AWS Outpost, customers like us can order capacity from AWS and deploy it into the hosting facility of our choice, along with connectivity from AWS Direct Connect or VPN services to provide a regionally-located service in a particular location that we need to operate in. While the capacity for Outpost is inherently limited, and also is not “instantly” deployable or provisioned like other services, at least we do not need to directly manage infrastructure, networking, security, or software ourselves. Also, any services that are provisioned inside the Outpost will be managed by the same AWS APIs and dashboards that we are already using. Most importantly, the resources inside the Outpost can be shared by our staging and production AWS accounts and Virtual Private Clouds (VPCs) in a relatively seamless and integrated way to operate from a location outside an established AWS region.

Getting Familiar With Outpost

As with all AWS services, it is important to know what the services’ strengths, weaknesses and limitations are. It is also important to understand how one or more services may (or may not) interoperate together! This is where the majority of our problems originated as we went into provisioning our applications in a remote environment. In terms of provisioning Elastic Cloud Compute (EC2) services that we can use as nodegroups in EKS, this is a relatively understood solution and works well with Outpost configurations. What isn’t as directly easy to understand or configure was the RDS integration with Outpost and we ran into issues with some basics like choosing instance sizes and using instances in Outpost with RDS.

The first issue we encountered initially was choosing the correct capacity and sizing of instances for both compute and RDS instances. If you are spoiled by AWS’ amazing depth and breadth of instance sizes, architectures, and variety, you will need to reorganize your thinking around a fixed set of capacity and architecture limitations for your Outpost racks and/or servers. As an example, let’s say that you have one rack with 4 each m5.24xlarge “raw” capacity. You could subdivide that capacity as you saw fit, let’s say that you started conservatively (as we did) with way too large of instance sizes as 8 each m5.12xlarge instances, spread across staging, production, RDS, and EKS as follows (please note all drawings are for illustrative purposes only and should not be relied upon for factual reference):

This seemed like a reasonable starting point for us and would allow us plenty of capacity and resources to operate without worrying about needing more vertical scaling capacity. With this setup, we were able to successfully launch services relatively quickly and simply, all options considered.

Right Size Scaling

If you are familiar with AWS services, you may now be thinking to yourself, as we later did, “Whoah, this seems like a lot of capacity to use for RDS and EKS!” The truth is that if we had more time, insight, and experience, we might have been able to come up with a much better provisioning scheme to right-size the capacity for each use case. The engineering issue isn’t so much the large over-allocation of capacity (which is a concern), but rather the operational downstream issues such as having spare capacity, being able to migrate or upgrade services and versions, and being able to scale horizontally (instead of vertically) as needed to meet demands.

After some post-launch issues were settled, we analyzed the data and came up with a much more reasonable allocation scheme that would suit our needs now and in the future. We settled on something that looked more like the following drawing.

You will notice that we have much more reasonably-sized (but still beefy) m5.8xlarge RDS databases. We also have enough capacity to add more RDS replicas (or new primaries even), and plenty of application-worthy EKS worker nodes for redundancy and failover. Not only that, but we now have way more free “spare” capacity for future needs as either smaller RDS databases or as beefier EKS workloads emerge.

Armed with this new information we let our AWS representatives know about our plans and future configuration. We had a pretty good idea of the plan of operations and had laid out a strategy for performing the changes “in place” with a reasonable amount of downtime during a maintenance window.

Best Laid Plans of Mice and Men

Experts in RDS and Outpost may already see the issue we were going to find ourselves faced with and will be chuckling to themselves, but this was the original plan we were going to follow to migrate from the original configuration to the new capacity configuration. We had consciously chosen the shortest amount of time that the maintenance window would occur to re-slot the entire Outpost rack in one window without causing undue issues affecting both staging and production. We did not have multiple Outpost racks available to work with; but this is something we definitely will consider in the future.

See if you can spot the issue:

Initiate downtime maintenance window in the application by shutting down all application services and issuing maintenance page notifications
Temporarily stop staging RDS instances and EKS worker nodes
Take snapshots for disaster recovery purposes
Temporarily stop production RDS instances and EKS worker nodes
Take snapshots for disaster recovery purposes
AWS support will apply new Outpost reslotting configuration
Restart staging and production RDS instances with new sizes
Restart staging and production EKS worker nodes and join to clusters
Test and validate the applications
End the maintenance window and allow normal operations

If you spotted the issue in step 7 labeled “restart staging and production RDS instances”, congratulations! For everyone else, you can follow along and learn from our experience when you attempt to do this yourself.

You Can't Modify a Stopped DB Instance.

This statement from the AWS documentation should be tattooed on the forehead of any AWS RDS practitioner – in reverse so that they can read it in the mirror. Or, perhaps, both forward and reverse for people who look at the tattoo and for themselves looking at it in the mirror. The issue we immediately faced as we tried to start the new instances was that the previous db.m5.12xlarge instances were not available any more in our Outpost configuration, so we could not start the RDS instances. We also could not convert the instances into the new db.m5.8xlarge instances sizes that did exist in the new configuration since the databases were shut down!!

I’m not exaggerating too much when I say that I briefly considered the fact that we had made a fatal mistake and were going to be down in production for hours doing a disaster recovery at this point. It is very important in these situations not to panic but to stay calm, talk through your options, and decide on a safe course of corrective actions.

Fortunately, we had the following in our favor, which you should also have at your disposal if you attempt anything like this. We made sure we had an AWS representative and AWS support people on the call while our maintenance window was active and the team on our side were engaged. This enabled us to get real time feedback on the reslotting process, get answers to RDS and Outpost answers from AWS, and also (critically) allowed us to reconfigure the capacity online while we were in the midst of trying to salvage our operations. If you do not have enterprise support, then you will most likely not be able to resolve a situation like this. Nor should you even attempt to do something like this without enterprise support obviously.

Failure is Not an Option

We quickly broke out our calculators, slide rulers, and pocket pens to come up with an emergency configuration that would enable us to start both db.m5.12xlarge and db.m5.8xlarge target instance capacity at the same time. It was like that scene in Apollo 13 where Ed Harris says that we’ve never lost a database in the cloud and we were going to use everything at our disposal to figure out a solution. We were able to come up with the following configuration to solve our issue.

Fortunately, we had enough of the “spare” capacity to configure as RDS interim instances. Later on, AWS could then reslot the unused capacity back into our spare capacity as needed. There was a huge sigh of relief as the configuration was reslotted and the databases were started, modified to new instance sizes, then rebooted as the correct target instance size!

Summary

In summary, we learned quite a bit and hope that you have too, if you have any plans for Outpost capacity in your future. In no particular order these lessons are:

Always plan, check your plan, recheck your plan, and have a backup plan
Always work closely with your AWS support and representatives to avoid problems like this if you can, and have them available when you need them in advance
Always stay calm and consider your options. Stick to the plan but react appropriately when circumstances change
Read your documentation and pay close attention to every detail as it impacts your planned path
When migrating capacity, ensure enough spare capacity is available both before, during, and after your migration plans
Use multiple phases of the migration plan where possible; consider initial phases, interim phases, and final phases
Please, please, please give your AWS support people and representatives a big show of appreciation for their hard work, dedication, and help!

About the Author

Regis is a staff platform engineer at Underdog. He has designed, built, and operated cloud-native architectures since 2015.

We're Hiring!

If you want to work on exciting projects like these with exciting people like me, please check out our hiring page

Image Credit

Photo by Torsten Dederichs on Unsplash

DEV Community: Regis Wilson

Wilson's Laws of Branching

A language almost exactly like yours, except it doesn’t like keeping secrets

1. First, declare what kind of decision this is

2. Nothing is an outcome, not an explanation

3. Guards do not need an escort

4. Three alternatives are not a binary decision

5. Default is not another word for safe

6. Fallthrough must introduce itself

7. Logging is not a branching problem

8. What the language knows—and what it does not

Appendix

Disclaimers

Credits

The Zeroeth Law of Engineering

Overview

An Apple Is a Ridiculous Amount of Work

Every Tool Requires a World

Construction Has Excellent Visibility

The Question Before the Ticket

The Bamboo Has Not Read the Label

Let's Cook, Claude

Practice Without Starting a New Practice

First, Build Nothing

Postscript: The Tree Makes an Objection

A Journey of Mind Free From Fan Noise

From C to Kafka to Tech Debt: A Journey of Mind Freed From Fan Noise

The Array Puts on a Ring

The Missing Condition

Kafka Discovers Rebirth

Why the Bodhisattva Does Not Curse the Ring

The Buddha Encounters an Unexpected Value

The Fan Files a Materialist Objection

Tech Debt Is Code That Has Left the Repository

The Final Storage Tier

The Engineering Mind, Freed

Appendix

YOLO: And Other Lies

YODALO: You Only Die At Least Once

YODA: You Only Die Again

The Western Resort

The Samsara Hospitality Group

Four Seasons: The Disclaimer Is in the Name

Hotels.com as a Karmic Engine

The Bodhisattva’s Coupon

The Red Pill and the Wilson Else

Where Did the Buddha Go?

That Is Why You Fail

Skate or Die: A Serious Logical Inquiry

The mortality problem

The four states of skate and death

Immortals must skate

Skate xor die

Skate if and only if die

What if skating itself causes death?

How much skating counts?

Is one skating event sufficient?

One-shot immunity

Threshold immunity

Maintenance skating

Continuous skating

Are skating deaths better?

Final judgment

Footnotes

The Wilson Else: A Linter for Branches That Pretend Nothing Happened

The Wilson Else: A Linter for Branches That Pretend Nothing Happened

Introduction

Lies and the Hurtful Truths

The Wilson Else

The Problem With the Lonely if

The First Bad Rule

Guard Clauses Are Not the Enemy

Conditional Logging Is a Separate Crime

Ruby Has a Pressure Valve

The Nested Case Is Where It Gets Interesting

Why TODO: nothing Is Better Than do nothing

What the Rule Looks Like

Where This Belongs

The Rule Is a Flashlight, Not a Religion

Why This Matters More in Platform Code

The Problem With the Lonely `if`

Why `TODO: nothing` Is Better Than `do nothing`