In software, we have many ways to manage change. Deprecation1, carefully timed breaking changes, release schedules.
New things can be added any time, but it can take years to remove something. You probably don't know why IPv4 is a problem2, but all the online infrastructure you have ever used is in a decades long war to escape it.
Unfortunately, real life is rolling release. Everything arrives when it feels, and you may or may not have advance warning or any say in the matter.
Maybe this week's change doesn't matter at all.
Maybe next week you'll spend hours reorganizing your entire life around it.
But the real world rarely does deprecation, only breaking changes. How often is a big warning label put up reading "This is no longer helpful, please try something else instead"? Road closures do, but road closures are carefully arranged changes to massive public infrastructure.
You are the only one who can deprecate your hobbies, your systems, your things.
When does a component get outdated enough to stop using, and eventually delete?
You can't keep it all.
If software isn't deprecated no one has time for anything but maintenance and everything grinds to a halt. But at least software is stable by default.3 If you don't change anything4 about it, it will do the same thing, forever.
If you don't change anything in your life, it collapses because it needs upkeep.
If you don't deprecate things in your life, you run out of time.
And then your life will collapse.
Most people deprecate things ad hoc when this happens, the responsibilities naturally get taken away by others more invested in the outcomes than you. You shouldn't need to reach that point.
Let's talk about prevention.
Reduce surface area
This is the easy part. The less you have, the less there is to deprecate.
Most people fail at it anyway.
That's alright.
Simple stuff like deleting accounts, reducing commitments, more time on less things. Do you actually want to do everything you're doing right now, in the same amounts? Seriously think about it.
Everything you choose to remove is one less thing that might overwrite something more important later.
Shoot for the final state
Ever tried to set a new daily habit?
Yes?
How was failing to set a new daily habit? Why did you fail?
Don't lie to me, we've all seen the statistics on New Years Resolutions. Daily habits are more frequent and over longer time spans. Of course the outcomes are even worse.
Daily habits are hard because most people don't allocate enough space for the change in their life.
The goal with habits is to get yourself to the final state of having the habit as quickly as possible. If that final state turns out not to be stable, of course it won't stick. You can't predict every sticking point at the start, but most are obvious.
Want to exercise more? Gym three times a week in the morning?
Cool.
How does this affect your wake up time, your commute, your morning routine, your laundry schedule, your energy levels? Are you certain all of those will be in a stable final state? Obviously, your energy will be worse the first few times you go, your routines will be unestablished and slow. That's a genuine transition problem, and you will need time to get past it, but fixing that won't solve an unstable final state.5
Reduce transition time
The longer you're stuck in the middle, the longer things have to change on you again, and the only thing worse than adapting to one change is adapting to two.
I have a data migration project which is at least two months in the making.
I've reduced it into a series of basic "move this, update that, delete those" operations. I migrate maybe three of fifty items randomly every week when I feel like it, but because I'm going from one stable state to another it's not a problem. The actual transition periods during that month has only ever been windows of five minutes at a time.
I'm never stuck in a spot where I need to work with the data but it's in two places at once at that moment.
Reduce the transition period, and you'll have an easier time clearing it.
Avoid temporary stability
Wait, what? Doesn't that help reduce transition time?
Yes, but there's nothing as permanent as a temporary fix. The last example about data migration is a series of temporary stable states, but I control every part of that project and am alright with being in any of the intermediate states. I don't expect I can move the last few things for months because of other constraints anyway.
If you need to actually get something done quick, temporary stability can be death.
An example.
If you move, you want to be settled in as fast as possible. Unbox as fast as possible, even if the organization is worse. Temporary storage is a black hole.
Why?
Easy, you really want to be done. That was the premise, that you needed to finish it.
So your brain naturally selects the boxes which need to be opened, and marks the rest as "extra". Voila, done even faster with less work.
A sealed packed box is in a stable state, which means it's in a viable final state. If you want to actually finish before your brain goes "eh, good enough", then you need to unbox everything so it's no longer stable.
Roll it forward
You can almost always stay slightly ahead of the curve, but only if you don't have anything holding you back. Sometimes this is unavoidable, you can't drastically change a friendship without causing a breaking change in the other person's life.
That takes time and consideration to resolve.
But for something small scale like where you schedule free time6, how you shop for groceries, anything that primarily impacts you, you can change things as you like. So don't leave things behind, always bring things into the new system, whatever form it takes.
Don't have time? Too bad, you still have to deal with the old stuff, which means that is part of the system now. There are ideas like email bankruptcy which explicitly avoid that, but you can usually do better.
No one wants to go back.
Don't put yourself in a position where you need to.
- Rew
Nightly Notes
This wasn't supposed to be the grand theorizing about change post, but it seems to have evolved. Whoops.
That's a good thing though, means I have more to say than I thought.
Another post, another stable state. Maybe you've noticed I talk in these notes like I've been doing it for longer than two weeks, even in the first few. That's partially because my sense of time is warped, but mostly because I'm trying to trick myself into treating this as the final state.
Obviously, I've always been writing these posts everyday, so I have to write one today. After such a long streak, skipping it is impossible.
...
Yeah, I can't believe it works either. Brains are fools in the strangest ways.
But I'm here, and I'm done for the day.
Keep on rolling.
- Rew
-
When something is officially no longer supported but hasn't been fully removed to avoid breaking changes for users. ↩
-
If you do, here's your cookie. For bonus points, go learn about the history of silly ways we attempted to avoid it. It turns out all of internet routing eventually turns into politics, and that would be hilarious if it wasn't depressing. ↩
-
Software is also fragile and buggy by default, but that's a different topic. My point is that the code won't change while you're gone. ↩
-
Unfortunately this often means literally anything. Old code still runs, but we often lack the machines and environment it was meant to run in. And we can't avoid changing everything. Time marches forever forward. ↩
-
I personally doubt most people are really stuck on those because of the transition period, but I'm one person. Try reading Atomic Habits if you want to learn more. ↩
-
Few people explicitly schedule free time, but if you keep a record of how your time is spent it will become rapidly apparent that you have been blocking out the same time over and over. Yes, scrolling every night before bed counts. ↩