A year ago, I wrote Timetabling, about the benefits of specifically breaking down your entire day down into scheduled blocks. I said at the time that one of the main benefits of doing this is that it forces you to put more effort into planning and catches large-scale scheduling problems early. Those are definitely benefits, but there's another thing I'd like to cover specifically: a timetable acts as a frame of reference.
I covered some versions of this idea in High water mark, Bug vs feature, The Elo paradox, and Creative competition. In one way or another, all of those posts make the point that it's very important what you measure yourself against. A common problem is to set too high a standard and feel inadequate, but another problem is to set too low a standard and stagnate.
But as many ways as there are to get it wrong, having a frame of reference is still incredibly important. Without one, you often end up just doing things without knowing whether they're improving anything. Worse still, it's too easy to justify your actions in retrospect; if you have no frame of reference, you may as well just put a flag in wherever you end up and say "look, I reached my destination!" This is a degenerate kind of goalpost optimisation where you can just set your goals however you like. If you're doing that, what pressure would there ever be to do better?
I originally thought of a timetable as a kind of plan, or a goal: "I want to have this thing done at this time". But I now think it makes more sense to consider it a measurement. Not sticking to the timetable isn't a failure. After all, a timetable is an extraordinarily rigid instrument that doesn't take into account any kind of adjustments that you might need to make throughout the day. But it does prove particularly useful as a frame of reference: here's what you intended to do today, here's what you actually did. No more mystery in where the time went, no ambiguity in whether you achieved what you expected.
More generally, I think there is a lot of value in this concept of measurements that you observe without criticising. It's why I've continued to call out how many prototypes I've done each week despite having decided to stop committing to a specific number. The point isn't that I particularly need or intend to achieve a certain amount, but all the same I don't want to accidentally decieve myself about what the actual amount is. If I want to know how things are changing over time or draw inferences from my behaviour, that information should be readily available.
And if I want to place judgements and standards on top of that to push myself, great, but it all starts with having a reliable frame of reference.
One thing I've been thinking about recently is the connection between short-term and long-term thinking. For example, the connection between a long-term goal and its eventual implementation in short-term actions. Many psychologists think of impulse control or delayed gratification as a fundamental attribute, but I think it may be more useful to consider it as part of the general case of connecting short-term and long-term decisions.
Possibly the most famous work on delayed gratification is the marshmallow experiment, where kids had the choice of one marshmallow now or two later. Followups showed that the longer the kids waited, the better they did later in life on several measurements including addiction, divorce and even BMI. Clearly there's a powerful effect here, but is that purely becaue of delayed gratification, or is it that delayed gratification goes along with or builds into other short/long term links?
The successful kids often implemented simple strategies to distract themselves like hiding from the marshmallow or distracting themselves with other activity. However, I'm not convinced that avoidance strategies are sufficient. If you're deciding between two things in the short term that both have impacts on your long-term goals, which do you avoid? If you come across some new information in the course of making your short-term decisions, do you incorporate that information or ignore it? I think reducing the affective pull of certain short-term rewards is important, but I don't think it paints a complete picture.
I've written previously about some short/long term bridging ideas. One was the scoping calendar that can be used to block out long-term chunks of time and then refine those into smaller short-term blocks like a regular calendar. Another, more recent, was chaining, a technique where you create an immediate short-term representation of the long-term goal and allow yourself to act differently in the short term only if you destroy that representation. The general idea I described as decision hoisting: reframing low-level decisions as high-level ones.
One way or another, all those ideas are about ways to build a connection between short and long term. But it's also worth wondering why they are even necessary. Some super-rational robot wouldn't need to carefully balance short-term and long-term decisions; decisions are just decisions, no matter when you make them. I think there is something particular about our psychology that causes us to have this disconnect. Subjectively, it feels like completely different processes are involved in making decisions in the moment vs making them while removed from the context they'll be implemented in.
Whatever is behind the disconnect, it seems to cause a lot of unnecessary difficulty. I feel like it would be a substantial contribution to figure out effective strategies for overcoming or working around it.
It's common these days for large internet companies to have bug bounties, which are paid out if you find vulnerabilities in their software. The idea is that people are incentivised to look for vulnerabilities and report them when they find them. They can (and in many cases do) hire their own security professionals, but even so there is a lot to gain from having a larger pool of people testing your site, and encouraging them to report anything that slips through the cracks.
As far as I can tell, the practice started with Donald Knuth, whose reward checks of $2.56 for errors in his books have something of a cult status. Errors in his software, on the other hand, are given the higher value of $327.68, which reached its peak after doubling ever year for 15 years since release. Knuth doesn't have corporate-level money to throw at this problem, so $327.68 per bug is a substantial bet on the quality of his software.
In the context of testing your life, this leads me to a pretty interesting idea. Why not have a personal bug bounty program? It could provide a lot of the same benefits as the software equivalent. It's usually considered kinda gauche to point out someone's flaws unprompted, so this would incentivise speaking up. What's more, it would encourage people you interact with to actively consider your behaviour more critically and look for ways you could improve. It's basically recruiting the collective wisdom of your network to help you improve.
Of course, you'd have to be a bit careful about how you do it. Maybe people would point out issues you already know about, or things you don't consider to be issues. Some of the issues might be too vague to be useful. People might even report lots of trivial problems that aren't really a priority. The thing is, though, these are all common problems that software bug bounties have to deal with, and it's still a net positive for them. So why wouldn't it be a net positive for you?
To put my (literal) money where my (figurative) mouth is, I'm going to run a pilot personal bug bounty. If you find an aspect of my behaviour or decisions that's holding me back, I don't already know about it, and you can describe it in a way that is specific and actionable, I'll send you $5 AUD. By specific and actionable I mean something like "you waste too much time on the internet", not "you aren't achieving your goals enough". I'm looking for a problem that lends itself to a solution. If it also comes with a solution, so much the better, but the main thing is that it describes the problem well.
Obviously there's a certain degree of good faith involved – I could just pretend nothing is a problem. That said, the nominal value is pretty small, so I don't have much financial incentive to cheat. I might have a personal incentive if I'm stubborn or don't want to admit problems. That said, so far I've shown a certain willingness to own up to failures, so in practice I think it will be fine. I will hedge slightly by saying that if I somehow start getting more reports than I can financially handle I might stop the experiment to save my poor wallet.
So if you have any good criticism and want some of that sweet bug bounty gold, email me on anything at this domain.
I've been working on an idea for a post that requires being able to record and play back editing a webpage. This was the first part of that, a library tentatively named пере (a Russian prefix similar to re-). I ended up going down a big rabbithole involving calculating text diffs using the Myers diff algorithm. My implementation ended up looking something more like a standard breadth-first search and is probably woefully inefficient. Still, it was interesting to get stuck into Serious Algorithmic Programming again.
This is a kind of mash-up failure of my most recent failure and an older failure where I pushed out my writing deadline to try to get a prototype done. I think I would normally have seen that coming, but the ongoing catch-up efforts after I ended up so behind recently made the whole situation more complex.
In this case, I had a prototype I was trying to finish for a post I wanted to write before my prototype wrapup for the week. However, it wasn't clear how the prototype deadline would interact with my post deadline (which is normally pretty static, but is all over the place while I'm catching up with my posts). In the end, the prototype got way more complicated than I thought, and it ended up pushing all my posts back by several days.
The whole thing has got me thinking about these deadline-relaxing problems as they relate to my recent ideas about truth as something you should try to represent and some earlier thoughts on goalpost optimisation, where it can be easier to change your goals than achieve them. There's a post waiting to be written on the idea, but it seems like a lot of problems come back to trying to alter these deadlines to meet my immediate needs rather than letting them simply reflect the truth.
Which is to say that I should have just abandoned the idea once it became clear I wouldn't meet the prototype deadline and just done something else as a prototype, or made a prototype wrapup post with no prototypes in it and just copped that on the chin.
To my credit, I kept writing posts (but not posting them) even as I was blocked on this prototype, so I'm not actually as far behind as it seems. Having now come to terms with the prototype not being ready, I can post that backlog which should leave me pretty close to caught up.
As predicted, the problems and difficulty of having to catch up on my posts after falling so far behind is acting as a powerful incentive to not do it again. I'll be glad when things are back to normal.
