Internal combustion engines use their own motion to power themselves. The rotation of the motor draws air and fuel into the combustion chamber, where it is compressed and ignited, causing more rotation and continuing the process. However, for this whole crazy process to work you need something to get it started in the first place. In most cases, this is actually a whole separate motor, so your engine is really two engines: the main engine and the starter engine.
It's worth thinking about this as far as other processes, because I see similar patterns in a lot of places. You have a self-supporting inertial system which, once it gets going, should sustain itself and be relatively robust. However, before it gets to that point you need to have a separate starter system to get that system working in the first place. And both systems are important! If your inertial system isn't good enough, you'll have to keep going back to the starter system. If the starter system isn't good enough, you'll never get to the inertial system in the first place.
Why not just have a starter system and no inertial system? Well, usually a starter system is unsustainable. For internal combustion engines, the electric starter will burn itself out if used for too long. They're also usually not very efficient because, well, why bother? The expected duty cycle of the inertial system is orders of magnitude higher than the starter system, so it makes more sense to focus your optimisation there.
And why not make an inertial system that doesn't need a starter? In some cases that's possible, but often the tradeoffs don't line up. It's much harder to make one system that can cover the entire range of conditions than to make one system optimised for the initial conditions and one optimised for the steady state once everything gets going. You might need to go back to trading with precious metals if society collapsed, but that doesn't make them a good candidate for everyday use now.
I think one area where this two-system analysis is particularly useful is when working on habit formation and other personal systems. Once you're doing something on a regular basis it's easy to keep doing it. Ideally, even easier than not doing it. But there are two ways that not understanding the starting vs inertial system can trip you up: firstly, just because it's easy once you're doing it doesn't mean it's easy to start. And the other way is that you can sometimes fall into a good inertial system by chance, without understanding the starter system that got you there.
Which is all well and good, except that what happens when something pushes you out of your inertial groove? Your daily running habit gets put on hold for a few weeks because you have a twisted ankle, or your streak of productivity gets halted through burnout or time off. That's when you need to turn back to your starter system to get things going again.
But if you never really had one in the first place, you might find yourself stuck wondering why your engine isn't moving when it was working fine a week ago.
A friend once told me about the idea that everyone has an emergency fallback strategy for when they run out of other options. If you're in an argument and you're really upset, maybe you try reasoning, emotional appeals, increasing volume, whatever to try to fix it, but if none of those work eventually you pull out your last resort. Maybe you scream, run away, break down in tears, or start smashing stuff, but there'll be some hail mary option you go to every time.
While I'm not sure that's always true, it's at least been true in my experience. And I think there might be other, less extreme ways that we look for safety blankets when things don't go our way. Think about the kinds of things you do when you're top-of-your-game, feeling awake, happy and energetic, and want to take on the world. Then think about the opposite: the kinds of things you do when you're miserable, sick, tired, or just having a bad day.
I suspect you would end up with a very consistent list of safety blanket activities. Reading, maybe, or video games, or watching TV. But there's no need for the safety blanket to be pure consumption, though it doesn't hurt. For a long time mine was programming, and I still find learning something new to be a very comforting activity. For some people I know, theirs was music, and they seemed to improve at it very quickly.
Previously, I wrote that part of committing to something is sacrificing the ability to not do it, even if you're having a terrible day and don't feel like it. That must be a lot easier if the thing you've committed to doing is something you turn to when you don't feel like doing anything else. It seems like you'd get a lot of mileage out of something you don't need to be in good form to keep doing.
I'm not sure if it's possible to change your safety blanket, but it's worth looking into. And, if not, maybe it's worth mining your most useful comfort activities for opportunities.
Today I'm happy to announce obligat.io, a platform for making public commitments to your goals. It doesn't do a lot yet, but I'm pretty pleased with it so far.
The idea is that the wording encourages you to be very concrete about what you're going to do and when so that it's verifiable. It's meant to be fairly soft touch other than that – just giving you the tools to make commitments, not forcing you into any particular system. The idea is that it will piggyback off your existing networks rather than try to be its own one.
I'm pleased that I ended up designing it without a login system. I realised that I don't really need one if I build everything around email. Instead of logging in, the site will email you a link to follow up with when the deadline for your commitment has passed, though that part isn't actually working yet. Mostly I just want to be really careful to do email in a way that doesn't get me instantly blacklisted from the entire internet.
Still, my main goal was to get it to the point where I could start using it, and that's already happening. Mission accomplished!
Well, another week, another failure. But it's a different failure and, as so often in programming, sometimes a different failure is the best kind of progress you're going to get.
This was a kind of compound failure where my goal for releasing the commitment platform I committed to last week conflicted with my new rules for when I count a failure at writing. I'm happy enough with the sacrifice I made (the commitment platform is coming as my next post), but I'm not sure it was strictly necessary to make that sacrifice at all.
In reality, the flexibility I built into my posting commitment should have helped me in this situation, but I was already one behind from the previous day. That says near miss to me: being a post behind became a fairly common state rather than an emergency. I'm beginning to think that this flexibility thing might be more trouble than it's worth.
A separate but related near miss is that, despite my good intentions with planning work on the commitment platform, I still did the bulk of it at the last minute. I did some design and planning earlier in the week that was actually very helpful, but not enough to significantly spread my workload out through the week. I got it done, but I didn't get it done comfortably. In fact, I would say I barely scraped over the line.
I think the issue was that I put effort into estimating time, but I didn't make much effort to schedule that time earlier in the week. I'm going to try that with the next big chunk of work I dedicate myself to, but that probably won't be until the following week so I can have some time to recharge and polish the stuff I did this week.
I wrote before about "it's the opposite to the one I expect" as being a particularly useless way to remember something. The problem is that as soon as you internalise it, it's not true anymore; if you always turn the tap the wrong way, and you remember "I should turn it the opposite way than I normally do", that system becomes useless as soon as your idea of normal changes which, if things are working, should be really soon.
I've been thinking that there's a more general class of problems along those lines, which are non-idempotent habits. Idempotence is something you often talk about in software to mean something that you can do multiple times with the same effect as if you did it once. So adding 1 isn't idempotent, but changing your name to Steve is. You can change your name to Steve as many times as you like and you're still Steve, but if you add 1 twice you've actually added 2. Idempotence is often considered a sign of a well-designed system.
The reason I think this is particularly important for habits and other mental systems is that, unlike a computer, we tend to operate on patterns and associations. So a non-idempotent habit tends to stick around even when it's not useful anymore. I started using 24-hour time and one nifty shortcut I found was that in the afternoon I could just read the 24-hour time as the 12 hour time, by ignoring the first digit and subtracting 2. 1900 is 7pm, 1400 is 2pm, that kind of thing. The only problem is that I kept catching myself looking at 1900 and thinking "that's 5pm". I got so used to subtracting 2 that I was doing it twice!
That's a pretty innocuous example of how non-idempotent habits can get you in trouble, but there are others like "I'll try to be more assertive" that have similar issues. More assertive than what? Than you are now? That will change as you change to feel more comfortable with your assertivenes. Or if you tend to be really behind on things and you build habits to deal with that, those habits stop being useful as soon as they start working properly because you're not behind any more. The high water mark I wrote about before is another example.
Something all of these have in common is a certain degree of self-reference: the habit changes based on its own output. I think a better answer is to find fixed points of reference to anchor habits to. Instead of being useful at first and counterproductive later, an idempotent habit will stay relevant over time. That means less habits but stronger ones, because they have more time to build.