Stop writing the directions. Write the destination.

Previous issue: a tired engineer, the wrong terminal, and a fire that explained why we needed to code infrastructure at all. This week, the cure gets invented, by someone who didn't belong in the room.

In the early 1990s, in Oslo, a young theoretical physicist sat down in front of a fleet of Unix workstations that would not behave.

His name was Mark Burgess, and by training he belonged nowhere near a server room. His field was quantum field theory, the mathematics of how reality holds itself together at scales no human will ever see. It is a discipline built on a single faith: that underneath any apparent chaos there is a law, and the law is always simpler and more beautiful than the mess it generates.

Then part of his job became keeping a menagerie of workstations running. And Burgess collided with exactly the manual inferno from Issue #1, except from the perspective of someone whose professional instincts were violently allergic to it.

Because the way you administered machines in 1993 was the way humanity had always done manual work: one step at a time, by hand, by script. You wanted a line in a config file, so you wrote a script to add it. Then the next machine was slightly different, so the script broke, so you added a special case. Then someone edited the file by hand, so the line went in twice, so you added a check. And another. Until your "simple" script had become a brittle thicket of conditionals, each one patching a hole the last patch had opened.

This is the imperative model of work. You write the directions, and the directions have to anticipate every possible state of the world when they run. Every sysadmin of the era accepted this the way you accept that water is wet.

To a physicist, it was nonsense. You do not describe a falling apple by writing it a list of instructions for each instant of its descent. You write down the law, gravity, and the apple's entire trajectory falls out of it, automatically, forever, for every apple. Burgess looked at his thicket of scripts and his drifting workstations, and the theorist in him rebelled with a single reflex that turns out to be the seed of this entire book:

Stop writing the directions. Write the destination.

His answer, released in 1993, was called CFEngine, short for Configuration Engine. And the idea was so simple to state and so strange to the era that the industry took the better part of a decade to absorb it.

You did not tell CFEngine what to do. You told it what you wanted to be true.

Not "open this file, check whether the line exists, and if it doesn't, append it." Instead: this file should contain this line. A statement of fact about a desired world. A declaration. And then CFEngine's whole reason for existing was to look at the actual machine, compare it against your declaration, find the gap between what was and what should be, and act only on that difference. Line already there? It did nothing. Missing? It added it. Mangled? It fixed it.

You stopped being the author of directions and became the author of truth claims about the system. The machine took responsibility for closing the gap.

This is the difference between imperative and declarative, one of the genuinely important distinctions in all of computing. Imperative is a recipe: do this, then this, then this. Declarative is a photograph of the finished dish, handed to a cook who knows how to read a kitchen: make it look like this, and you work out the steps. The second question, "what should be true?", turns out to be far more powerful when the world keeps changing underneath you.

Here is where the popular telling has been quietly wrong for thirty years, and the correct version is more impressive, not less.

The credit usually goes to CFEngine for inventing idempotency, the property that doing an operation once and doing it a hundred times produce the same result. Idempotency is real, and CFEngine has it. But it is not the idea Burgess was actually chasing. The word that carries the real payload of his life's work is convergence.

The distinction is the whole ballgame. Idempotency assumes a tidy world: you run the operation, the system reaches the desired state, you're done. Convergence assumes the real world, the one that never stops moving. Things drift. Disks fill. Someone logs in at 3 a.m., edits a file to fix an emergency, and forgets to tell anyone. Entropy is always pulling your carefully configured machines back toward disorder.

A convergent system never declares victory. It runs again and again, on a schedule, and on every single pass it measures the gap between reality and policy and takes one step to close it. Forever.

Picture it. Monday, the engine runs: the line is missing, so it adds it. Tuesday: the line is present and correct, so it does nothing. Wednesday, a panicked colleague deletes the line by hand during an incident. Thursday, without anyone asking, without anyone noticing, the engine runs again, sees the gap, and silently restores it. Nobody filed a ticket. The system healed itself.

That self-healing-under-disturbance is convergence. And once you've seen it, you cannot unsee how much weaker the imperative alternative was. Burgess later formalized it into something he called Promise Theory: a view of systems not as a hierarchy of commands flowing downward, but as collections of autonomous agents, each making promises about its own behavior and keeping them as best it can. You don't order a server into compliance. The server promises to keep itself in the declared state, and the engine helps it keep that promise. It sounds almost philosophical. It is also a strikingly accurate description of how large distributed systems actually behave, which is why the idea would echo, decades later, through cloud platforms built by people who had never heard his name.

Here is where the story should end if it were the kind the tech industry likes to tell about itself. The lone genius, decades ahead, sees the deep truth, builds the tool, and is vindicated. A keynote, a fortune, a statue.

That is not what happened.

In 2005, an American sysadmin named Luke Kanies, a CFEngine power user who had run face-first into the tool's ceiling, built his own. He called it Puppet. It kept Burgess's essential DNA, declarative, desired-state, targeting machines by their characteristics. But it wrapped that grammar in a language working administrators found dramatically more approachable: tidy blocks describing resources, a package, a file, a service, mapped directly onto the nouns a sysadmin already thought in. Underneath, Puppet worked out the order of operations for you. It was, to the people running these tools at two in the morning, simply easier to hold in your head.

And "easier to hold in your head" is, over a long enough timeline, the single most powerful force in the adoption of any tool.

Easier won.

The man who invented the grammar watched a more usable dialect take the room. Priority did not equal adoption. Rigor did not equal reach. Burgess had built the deeper, more correct, more beautiful idea. Kanies had built the one more people could actually speak. And the market, which has never once rewarded correctness for its own sake, rewarded reach.

It would be easy to read this as a small tragedy and leave it there with a sympathetic sigh. But that misses the point, and the point is the spine of everything that follows.

The tension between Burgess and Kanies is not a footnote about two men and two tools. It is the central conflict of the entire work as code project, showing up for the first time in miniature: the tension between rigor and reach. Between the most correct way to describe a system and the most usable one. Between the elegant law and the friendly dialect. Between the idea that is true and the idea that spreads. It does not get resolved in this chapter, or in this book, because it is not the kind of thing that resolves. Every chapter ahead runs straight back into it.

But notice what survived. The dialect won the market. The grammar won history. Puppet, Chef, Ansible, Terraform, every tool we'll meet in the issues to come, they all speak Burgess's language whether they credit him or not. His way of seeing infrastructure became so completely the assumed foundation of the field that most practitioners no longer know there was a person who had to think of it first, alone, in a room full of misbehaving workstations, by reaching for an instinct he'd learned from physics.

That is the quiet vindication, and it is a real one. The pioneer didn't get the parade. He got something stranger and arguably larger: his way of seeing became invisible, which is what happens to ideas only when they have completely won.

This is Chapter 2 of a twenty-chapter argument. The whole thing compresses to five words: Described. Versioned. Tested. Owned. Improved. That's the lifecycle Infrastructure as Code imposed on machines, and the book watches it escape the server room and reach for everything else.

→ Read more and follow the series at workascode.ai

Next issue: the quiet conviction of one traveling sysadmin becomes a loud, crowded, occasionally bitter market. Three tools, three temperaments, and a war over how much power a tool should hand you at three in the morning. Issue #3: the config management wars.

A great idea rarely arrives from inside the field it transforms. It usually wanders in from an adjacent world, carried by someone who never thought to accept the local misery as normal.

See you in the next issue

Eleodor Sotropa

You're receiving this because you follow the future of programmable work. Subscribe · Forward to a friend who still writes the directions instead of the destination.