Monthly Archives: January 2024

less magic, more infrastructure

My day job is to build automation. Some of my best work is when a person can show their intent with a small effort and automatically marshal hideously complex processes to carry out that intent. I show them the hideous guts of the process once to prove that I’ve done work – a standard wizard tactic to avoid being taken for granted – but after that, it should work like magic.

Or should it? As an individual, I actually dislike magical interfaces. I groan when I read setup documentation, because it always has 3 steps that fail somewhere between step 2 and 3. “Take the device out of the box, place it next to the main device, and it will pair.” Right. And if it doesn’t? (For me, it rarely does.) Then suddenly I’m in 300 more steps that are spread out over a dozen sites, hidden among the worst documentation interfaces possible. I’m pushing the one button on the device in a staccato rhythm while reinstalling the operating system of the other while draping a mylar blanket over both to block stray radiation, and… I realize I’m on the wrong end of the magic.

What I prefer in a case like that is good old fashioned* infrastructure. Plug A into B, tell B that A exists, tell A that B is what you want. Once they’re paired, remove the plug and you’re in the same situation the magic would have left you after step 3. Except! If you run into a problem, you know how to drop into the infrastructure and perform the same set of steps to get you back where  you need to be.

(*It’s not actually old fashioned. We just get used to the infrastructure that works, and it feels like it’s always been there. Infrastructure that doesn’t work is technology, and we get used to it not working and route around it.)

To design infrastructure vs magic, the difference is asking, “what happens when this goes wrong? How can someone using this get to the part that isn’t working and direct it manually?” That’s where the difficult work of engineering comes in, because you need to ask not only how your system works when it all works, but how the whole system it relies on behaves when it doesn’t. What does the process do when there’s no internet? What does it do when the signal from the other device is too weak? What does it do when the list of devices it sees is too long? When the device doesn’t speak the right protocol?

A lot of that design deals with falling back. If the latest protocol doesn’t work, is there an older one that might? If the signal is weak, is there a way to connect that doesn’t use radio? And above all, how do we communicate this to the person looking at it, so they know which part needs help?

So it’s hard work, but really it’s doing the work needed to create full automation. It’s not just automated when it works; that would be magic. Putting me in a place to fix it when it doesn’t work automatically is good infrastructure.


This week’s airline disaster – and in particular the engineering and procedures that got everyone out of the plane alive – reminds me that I’m attracted to preparing for the worst. I’m the one on the plane who checks where the nearest exits are and what kind of flotation device is available. Not that I want the worst to happen, but I feel better knowing Plan B in case Plan A goes south.

Being prepared is also a challenge, a way to think deeply about the infrastructure I rely on even when it’s practically invisible. (Yes I am still thinking a lot about water thank you.) What would I do if the power went out? What would I notice? How would I change so I could keep doing the things I need? The answers let me design alternate systems that take effect when things go wrong, or (in the absolute best case) replacement systems that keep working despite the trouble.

So let’s talk about preppers, though. I grew up loving trips to the army surplus store. Survival gear and wilderness-focused preparation strategies are attractive because they involve stuff that feels tough and adventurous even if I can barely operate a can opener. Now, though, I reject the idea that my survival has to be set up in opposition to other people. It doesn’t just feel wrong, it completely contradicts how I’ve seen a good community operate in a time of crisis. People help each other to survive and recover.

The moment that convinced me was a multi-day power outage when I lived in San Diego. It’s the classic example of what preppers are prepping for: the city is without power, everything shuts down, no one has any of the things they need, and… well, what’s supposed to happen is chaos, looting, folks barricading themselves in their neighborhoods and trading with gold. What actually happened is folks took the day off work, emptied their fridges and freezers, went outside to be in the evening light, and had block parties. Want some ice cream? It’s just going to melt. Need to charge your phone? Here’s  a brick and a solar panel, go ahead. Need a spare flashlight? Let’s share.

It’s hard to describe the feeling in our neighborhood over those couple days. It was a time out of time. People really didn’t want it to end. Which is better than survival, isn’t it? It’s something different. It’s resilience. And it wasn’t even planned, it’s what we all fell into when there was a pause in television broadcasting.

More recently, the state of Washington has talked about resilience centers (or resilience hubs, I’ve also heard), which are places that people can go for essential things during a disaster or an outage. Each center builds up the infrastructure it needs to keep the lights on, to keep the wifi going, to keep the water running, to keep cool or keep warm. I love the idea, because it’s just as attractive a prepping opportunity but it assumes we’re going to find each other, to work together, to form community when something goes wrong. A resilience center doesn’t need an arsenal, it doesn’t need a way to bug out. It still has challenges, though, but they start to look like resilient infrastructure. How would we keep the wifi on? How much power can we produce? What does at-hand food storage look like in the long term?

So now when I prepare for the worst, I think about resilient infrastructure. How about you? What would you build? How could you share it? What helps when we all know how to do it?