I had an interesting thought the other day. What we normally think of as being ourselves is a very specific part of us. Sure, most of us would say that our physical body is our self, but if pushed we'd say the core of our identity sits in our brain. I'd go even further: when we introspect, the part we identify most strongly with is the part doing the introspecting. I don't just mean your mind, but the particular part of your mind that analyses and observes: Kahneman's System 2.
However, this belief doesn't align very well with reality. Most of your decisions and actions are actually made by your associative System 1. Your analytical process usually only comes in after the fact, and on the comparatively rare occasions where it's actually calling the shots it's enormously slow and resource-hungry. I would go so far as to say that if you want to define a self, it should be your unconscious, associative self.
It might seem counterintuitive to define your self as the part that isn't conscious, but I think it makes a lot more sense. Gone are paradoxes like "I really want to do things differently, but when the time comes I keep doing the same thing". Really, it would make more sense to say "My self-reflection says I'd be better off doing things differently, but I keep doing them the same way". From that perspective, there's no conflict, it's just clear that your self-reflection hasn't made a compelling argument for you to change.
That doesn't mean I think it's unreasonable to identify with your body, or your analytical mind, but we have some basis for thinking that our brain is more "us" than our foot is. That basis, I feel, is unfairly biased by the nature of introspection. If instead we base our identity on which part, if we understand it best, best predicts our behaviour, I think there's only one answer that makes sense: you aren't you, you're mostly the stuff that happens when you're not paying attention.
I've had an interesting problem come up a few times on long-running projects. Throughout the project you make a lot of different decisions. You choose one particular solution over others, make some tradeoffs in how you design something, and set or change overall direction. These decisions accrete over time until, late in the life of the project, there's a thick, hidden blanket of existing decisions underneath everything. For solo projects you can often remember why something was done, but not always, and for teams it's basically out of the question. The result is you often waste time revisiting decisions.
Existing forms of documentation aren't so great for preventing this. In software you would usually attach documentation to a particular line of code, a general design document, or a larger code review/patch set. Those can explain particular instances of decisions, but I don't think they solve the problem completely. You end up with that information spread out over a lot of different places, and in a lot of cases a given decision spans several different locations. I think that decisions don't map cleanly enough to anchor points in the project itself for that to work.
Instead, I think it might be worth keeping a decision log. Just a flat file of all the decisions you make about a project, maybe split into multiple decision files if you've got neatly separated subprojects. Every time you decide something important, it goes in. The bar for important might need some tweaking, but I think a good one would be anything that takes longer than a minute to decide on. Alternatively, anything you could imagine wanting to know if you hadn't seen the project before.
The end result would be a single place to look if you're trying to figure out (or remember) why something was done a certain way. I think it'd also have the nice side benefit of encouraging you to think about your decisions in the context of that some future person trying to understand what you were doing.
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!