Systems 5 min read

Engineering a Life: Systems That Survive the Operator

Inertia, not willpower, moves a life. I have been trying to build systems that restart after they break.

I prefer a sheet of paper to an iPad for taking notes. On paper I open the book, pick up a pen, and write. That is one layer between me and the page. On the iPad I tap the screen to wake it, swipe or type to unlock, land on a home screen, find the notes app, tap it, and wait. That is four layers. Each one costs a small tax on attention before I have written a single word, and the tax compounds across a day.

I read the same structure into almost everything. Fewer layers means less friction. I call the general version simplify theory, and I apply it to tools, rooms, study methods, and the shape of a week. It started as an aesthetic. Later I began to think it was closer to a load-bearing rule.

Inertia Outruns Will

The idea I keep coming back to is not mine. It comes from reading Qian Xuesen on systems engineering, and from a sentence I keep repeating to myself: the inertia of a system has more force on a life than conscious effort does. A good system accumulates, a little each day, without needing me to be heroic. A bad system does the same in the other direction.

Compare two study habits. One requires a decision every time. The other is already in place, and I only have to fall into it. The second one wins over months even if it looks smaller on any single day. I have watched this happen in both directions. The difference is not effort. It is whether the system has a default I can drift into.

When I learn something new, I now try to start from the concrete and work backward. Engineers sometimes teach top-down, beginning with the substrate, but that path is slow, and every abstraction before the first useful result is friction. I would rather see a sorting algorithm, read the two nested loops, and feel what it does, then dig back toward the theory underneath. I call that diffusive learning. Give me the target and the answer, let me take the answer apart, and the principle shows up on the way out.

I have used it on everything from small programs to concepts in electromagnetism. The learning I remember best came that way, in bursts, from the answer back to the rule.

Polymath is a word I return to. Da Vinci is the obvious reference. I am not sure that goal is a good idea, but it is mine.

What My Systems Actually Look Like

Here is where I have to be honest. I have built good systems. I have also watched most of them collapse.

My attention is not steady. I can absorb a large amount of material in a short burst when something catches me, and then forget most of it once the burst ends. The reading is real. The retention is not. Plans I write with clear discipline collapse faster than I expect. The flood arrives, the water recedes, and the ground is dry.

So a system I design for the best version of me is not really a system. It is a plan for a person who exists for a few days and then leaves. I have written many of those. I know exactly what they look like. They are beautiful on page one.

Designing for the Comeback

The change I am trying to make is to design for the operator who comes back after the plan is already dead. That version of me is not motivated, not organized, and not willing to recover a broken system by hand. If the restart costs more than a few minutes, it does not happen.

So the question I ask about a new system is not how well it performs at peak. It is what the first five minutes after a collapse look like. Can I resume without reading my own notes? Can the habit tolerate one missed week without requiring an apology? Can the default carry me when I have no will left to decide?

I have not finished the answer. Some of my systems still overload me, and the “frictionless” doctrine occasionally fails in the direction of too many saved options and too many open tabs, which is decision friction wearing a friend’s face. I do not know yet whether simplification and variety can be reconciled in one life. I suspect the polymath goal and the low-friction rule are partly in conflict, and I have not resolved it.

The honest version of systems engineering, for me, is the discipline of building around my own failure modes instead of pretending they are temporary.

The systems that last, so far, are the ones that do not require a perfect operator. The operator will not be perfect. The system has to restart anyway.