I've been noticing recently how big a difference it makes to my happiness whether I feel ahead or behind with something. Sometimes that's measurably ahead or behind, as with posts or prototypes or other regular things. Other times, it's the perception of being ahead or behind, like with long-term progress towards some work or preparation for an upcoming deadline. Either way, it's hard to overstate just how different it feels when you're doing something a day before you need to as opposed to doing it on the day, or worse still, a day late.
It's taken a while to acquire the tools to think about this difference and why it exists, but What changes? has turned out to be the thing I needed. The key observation is that, for something with multiple outcomes, you need to ask "what changes?" for each outcome. For a task you do ahead of time, what changes? If you do it, a positive: the task is done. If you don't, a neutral: you can just do it later. For a task you do exactly on time, it's a positive (it's done) vs a negative (it's not done). And for something that's past due, it's a neutral (do it, but it's late anyway) vs a negative (it's even later now oh god help).
Various experimental results show that we tend to value losses disproportionately compared to gains. That is to say, we would rather avoid a loss of $100 than achieve a gain of $100, even though the net change in position is the same. I think that loss-aversion comes into play here too; positive vs neutral is a more favourable bet than positive vs negative, and more favourable still than neutral vs negative, even when the net values work out the same.
That has some other interesting implications too. For example, one element of procrastination could be that the motivational power of the split between positive and neutral is less than the split between positive and negative. So, in a perverse optimisation, you wait until exactly when it's due, because that's when the difference between doing it and not doing it is highest. That would further mean that this split disappears as soon as it's past due, and your motivation would totally collapse, which is consistent with my experience.
Motivation aside, there's obviously a kind of comfort in knowing that the worst feasible outcome in your present situation is a neutral. I think this comes back to positive and negative reinforcement. It's not that a negative reinforcement doesn't work; it does, it's just unpleasant. The reason why being ahead feels good, even if it tends to not be as intrinsically motivating, is that there aren't as many unpleasant negative things to consider.
The practical consequence is that, beyond just not having to consider the unpleasant things, it's also less likely that they will happen. In this case, the unpleasantness is entirely rational because it's helping you avoid dangerous situations. What's irrational is the desire to maximise the split between positive and negative outcome which pushes you towards last-minute dramatics. That whole pattern seems eerily similar to problem gambling and other high-risk behaviour.
How can you avoid it? I think the only answer is to replace risk as a source of motivation. In some cases, that could be the defence in depth idea: pull your risks forward, treat them seriously but not disproportionately, and spend more of your time on meta-risks. But in a way doing that is just moving risk-based motivation around. It'd be interesting to look at entirely different sources, like wanting to maintain a certain character, or building habits to the point where the status quo is motivating on its own.
Regardless, one thing is clear: being behind is a huge motivation killer, and it's worth bending over backwards to recover or restructure as quickly as possible. No matter what other sources of motivation you have, being trapped between a bad outcome and a neutral one is a burden large enough that removing it should almost always be your first priority.
I've been thinking about a few related things lately. I wrote Everything in modulation, about the idea of focusing on transitions rather than constancy. I've also written about motivation-driven development, the idea of doing harder things earlier because they require the most motivation. Recently, especially in my lastfewfailures, I've also seen a pattern: things seem to go to pieces easily when I have a lot going on, and when they do it's much harder to keep working on them unless it's in one big burst to catch up.
Putting these all together, I've been starting to ask this question: what changes? Let's say you have an enormous mountain of things to do. Now you finish one thing. What changes? You still have a mountain. Or worse, let's imagine you have some big scary task to do, something that's weighing on your mind and stressing you out, but you also have some little tasks to do first. You do the little tasks. What changes? The big task hasn't gone anywhere, and if anything it's gotten worse, because you're more tired and have less time to do it.
So the first part of this idea to make sure you have meaningful transitions in your work. If you have two different bits of work to do, putting them back-to-back means that the answer to "what changes?" is "I go from working to more working". This is a useful way to think about breaks, not necessarily as an opportunity to recharge or recover from work, but as a chance to make the transition between tasks more meaningful. Of course, it's important to remember that the work-to-break transition has an equal but opposite break-to-work transition afterwards, and that can be dangerous, especially if the task after the break is the harder than the one before it.
Another way of thinking about it is, instead of focusing on work-break transitions, focus on the transitions in your situation that result from doing the work. This is the perhaps obvious idea that you should do the things that make the biggest difference first. If your two tasks are "finish the feature I'm working on in this project" and "have an uncomfortable conversation with the project manager about probably missing a deadline", those are both important things to do. However, although the first one is easier and arguably more productive in absolute terms, the latter results in the bigger change in your situation: you go from having the deadline conversation looming ahead of you to having it behind you.
The other thing is that the idea of "what changes?" is based on your own perception, which means it can also be useful to try to change your focus. If you perceive your work as one giant undifferentiated lump then it's pretty difficult to find meaningful transitions in it. Even if you break it down, it's important to break it down in such a way that the parts are meaningfully different from one another. This is one thing I like about working iteratively in software, each iteration produces a new working version. The answer to "what changes?" is obvious and visible, rather than leaving large gaps where you're not sure if there's any progress at all.
Sometimes it can be just as simple as paying attention to the transitions. If you're not looking for changes, it can sometimes seem like the things you're doing just leave you in the same place. But even small changes can be meaningful. This is the basis for techniques like journalling, self-measurement, and generally setting up useful frames of reference.
But the most important thing is just that the answer to "what changes?" should never be "nothing". The reason is simple: doing nothing is a far more efficient way of changing nothing, and your optimiser won't hesitate to suggest that instead. And, if you really do think nothing will change because of your actions, you have to admit it has a point.
I've been helping a non-technical friend out with some computer stuff recently, and it always surprises me just how much calcified computer knowledge I'm carrying around. I'm zooming from window to window, clicking through menus and things and explaining what I'm doing as I go, only to realise I've just given more detail than a reasonable human could absorb in twice the time I'm taking. Worse still, there's a severe mismatch between what we find difficult, so I sometimes skim past critically important but obvious (to me) points. Sure, I solved the problem, but the chance of my friend being able to replicate my steps on their own was basically zero.
One time I was doing this and the person I was helping said "hang on, let me get a notepad". And, honest to god, took written notes the whole time. I looked at the notes afterwards and they were... not at all what I expected. They'd written down names of programs that I opened – but those programs are in a list! You can just see them in the list! There's no need to write the names down. Well, not for me, anyway. Obviously I can pretty easily remember which program is which, but to a beginner I guess all the names and beige boxes must blend together. Most of the notes were trivial things like this, things I never would have thought to focus on.
It occurs to me that MOOCs have it right in this regard. They don't have any magical solution to the problem of teachers finding the easy stuff hard and the hard stuff easy, but it doesn't matter because they can cheat using time travel. Instead of live instruction, online courses focus on videos, and videos go at whatever pace you want. Students can fast-forward the boring bits, slow down the critical minutiae that get them lost, and play a troublesome step over and over again until they understand it. Really, it's a way of letting the students decide which parts of the lesson need the most time rather than the teachers, which turns out to be an amazing improvement.
So I think it'd be neat to bring this to computer support. Instead of forcing the long-suffering computer novice to take paper notes, just screen-record the whole session along with the audio of your voice, then give them a copy of the video when you're done. If there's anything that was a bit too dense for them to follow, they can play it back slowed down later. And this also takes the pressure off remembering unimportant details like which menu item the options are under; they know that detail is captured in the video, so they don't need to try to remember it.
What would be pretty interesting is that, with a bit of extra tooling, this could perhaps turn into a fairly compelling software product. You could add things like markers for each important step you took, build up a little library of small instructional snippets, that kind of thing. There's still a surprising number of people who have to call someone every time they want to do an unfamiliar task on a compmuter, and for them the ability to replay the help they've gotten rather than calling back might be a really big deal.
I've read some interesting stories recently by people who ended up in really bad situations and slowly built themselves back up. The first was about a really obese guy on a bodybuilding forum, who posted claiming to be the fattest guy on the forum. The forum members took him in and helped him until he eventually halved his weight. Another was about a lawyer who suffered from schizophrenia and largely just tried to deal with it, until eventually he couldn't anymore and checked himself into a care facility, despite the risks to his career.
What is interesting about these examples is that the people had to hit rock bottom before they could improve. It would have been easiest for the obese guy to lose weight when he was only a bit overweight. It would have been easiest for the lawyer to deal with his schizophrenia before it got so bad he had to remove himself from society to fix it. At least in theory, dealing with your problems is easiest before they get so bad as to be debilitating. But the reality seems to be the opposite. Why is this?
I wrote before about the anthropic principle of problems: if you have a problem, there must be some mechanism preventing its solution, otherwise you would have solved it already. People don't end up in terrible situations because of problems that they can solve, they end up there because of problems they can't, or won't, solve. Sometimes that's because of a lack of knowledge or experience, sometimes it's not realising there's a problem at all. But often the problem is there, you know how to solve it, and the only thing stopping you is hubris.
By hubris, in this case, I mean that the solution is beneath you. It's too easy, or it would involve something you've decided isn't your game, or you have some assumption that stops you from considering it. This can be a good thing in situations where the solution violates your sense of ethics or part of your identity, but often it's not anything so grandiose. Rather, it's that you won't accept help, or you have some arbitrary preconception about the right way to do it, or you feel too concerned about how admitting the problem would make you look.
But the great thing about hitting rock bottom is that it's totally incompatible with hubris. Once things get bad enough, you can't really manage a sense of pride or superiority. You finally reach a point where your situation is, unquestionably, not okay. The various excuses and assumptions sort of melt away, because they ultimately rely on seeing yourself as in some way above or beyond them, as not wanting to give up that position. Rock bottom is when you're not above anything, and you gain the superpower of desperation.
Of course, it's worth suggesting that you can get rid of your hubris without hitting rock bottom too. All that's required is to think about what you would do if you had nothing to lose.
