For a while I had one answer to interruptions. Don’t let things go fully cold.
It seemed like the obvious lesson. Things get interrupted. Travel, a busy stretch, a move, a job starting. A system that only runs under good conditions runs a few weeks a year. So the useful skill is making it cheap to pick things back up, and the cheapest way to do that is to never fully stop.
That rule has held up well in a lot of places. It just turned out to be one answer among several, and I found that out by looking at the one system where I had never applied it.
Where the rule comes from
Over the holidays in Lapland I capped Finnish reviews at roughly 25 minutes a day instead of stopping them, and kept journaling without any requirement that it be worth reading. I wrote about that in Switching Into Vacation Mode, and the line I landed on then still holds: keep things alive at a lower volume. Running got the same treatment while traveling. No structured training, no plan worth the name, but the shoes were always in the bag and every place got at least one run in it.
None of that is progress. A 25 minute review day is not learning Finnish, and one run in a city is not training. That isn’t what it’s for. What it protects is a review queue built from months of history and a habit that currently runs without being argued for. Stop the reviews for six weeks and the queue is a wall on the day you come back. Stop running entirely and the next first run gets paid for with willpower, which is exactly what the system was supposed to make unnecessary. The whole design, as laid out in How to Stay Consistent Learning Finnish, depends on the daily minimum being small enough to survive a bad week.
And even with the light versions running, getting back to full rhythm in Hamburg took about two weeks. That was the cost after keeping everything warm.
Where it didn’t apply
By that logic, writing should have gotten the same treatment. A small weekly session while traveling. A few paragraphs somewhere, just to keep the practice alive.
It never did, and nothing suffered for it.
Before the month in South America I prewrote posts and froze side projects, then stepped away from all of it. For that month the writing stopped completely. The blog kept publishing every Sunday anyway, because the posts already existed and the pipeline didn’t need me. Nobody reading it could have told I wasn’t writing.
That’s the part the keep it warm rule missed. It assumes the thing worth protecting is the activity. For Finnish and running, it is. The value accumulates in me, in the review history and the habit, and it only exists as long as the practice keeps running.
For the blog, the activity isn’t what anyone experiences. What needs continuity is the output. The writing itself can go fully cold for a month and come back without much cost, because a writing session doesn’t depend on the last one the way a review session does. So instead of keeping the practice warm, the answer was to put distance between the practice and the output. I wrote about the mechanics in I Don’t Write Weekly. What I hadn’t noticed then is that it’s a restart strategy, not just a scheduling trick.
Three answers, not one
Once the blog stopped fitting, the single rule split into three.
Dial down when the value lives in the practice itself. Finnish reviews, running, journaling. These accumulate something in me that can’t be stored anywhere else, and the only way to keep it is to keep doing it, even at a volume that accomplishes nothing on its own terms.
Buffer when the value lives in the output and the practice can happen in batches. Writing works this way. So does anything where other people depend on a steady result but don’t care when the work behind it happened. The practice is free to stop, as long as the output has enough runway to cover the gap.
Let it go cold when neither the practice nor the output needs to exist during the gap. The side projects I froze before leaving sat untouched for the month, with no minimum and no buffer, and picking them back up afterwards cost little more than remembering where they were. Nothing was lost by the pause, so nothing needed protecting.
The mistake isn’t picking the wrong one of these. It’s not noticing there’s a choice. I had spent effort designing minimums for things like Finnish because the default there was collapse. With writing the default was fine all along, and I only noticed because I was looking for places to apply the rule.
The question underneath
All three come down to one question per system. What actually needs to keep going while I’m not?
If it’s something that only exists while I’m doing it, keep doing it at a lower volume. If it’s something other people see, make sure it keeps arriving and let the work behind it rest. If it’s neither, stop cleanly and don’t feel bad about it.
This is close to the argument in Designing Systems That Survive Your Absence, where the point was that absence shows you which things you personally prop up. Restartability is the other half of that. Once you know what depends on you, the next step is deciding what kind of continuity it actually needs, rather than giving everything the same treatment.
Closing
Restartability isn’t a single property a system has or doesn’t. It’s a decision made per system, and the decision is about which layer needs continuity.
Sometimes it’s the practice, and the answer is to keep it alive at a lower volume. Sometimes it’s only the output, and the practice can stop entirely as long as the output doesn’t. Sometimes it’s nothing, and stopping is the right answer.
I spent a long time applying the first answer everywhere. The better habit is asking the question first.
