Meta goals for managing exceptions and correlated derailments

Akrasia
1

I’ve noticed myself using a pattern that I haven’t seen described before. It addresses two problems:

  1. Dealing with unanticipated disruptions that prevent you from working on a goal, which doesn’t pair well with edge-skating; you can build exceptions into the fine print of every goal, but that’s both repetitive and also you end up with fake data, so your data is no longer accurately describing what you’ve done, which feels conceptually sloppy and means you can’t get the warm fuzzy feelings from seeing how big the cumulative number is
  2. There’s a built-in downside to organizing your life into a large number of goals, which is that in some cases derailments can be highly correlated and you may find yourself getting charged a lot more than feels “fair” for the situation; i.e., the charges are too coupled to the choice of exactly how to chop your life up into goals

A solution is creating an additional goal that enforces some amount of progress on the other goals.

Pros:

  • the fine print for what counts as an exception can go in one place
  • the edge skating can be concentrated in the one meta goal, because you can target (enforced by edge-skating in the meta-goal!) any desired amount of safety buffer in the normal goals
  • normal goals now have accurate data

Cons:

  • it’s more complicated
    • harder to figure out what you actually have to do and whether you did it
      • I handled this programmatically
      • could still be useful for a very small number of normal goals
    • how do you manage the commitment and safety buffer in the normal goals?
      • like, should the commitment be exactly the rate that you want to work at in the absence of exceptions? and then you need to keep safebuf>7 and manually add breaks whenever there’s an exception?
      • or should the commitment be lower, and you have to encode somewhere else what your actual target commitment is?

I assume the “it’s more complicated” part makes this not useful for most people, but I thought it was an interesting pattern to have written up somewhere.

One way of thinking of it is that beeminder can be factored into two pieces of functionality:

  1. tracking
  2. enforcement

I tend to think of enforcement as the core value prop, and will sometimes design other tracking systems that I apply beeminder enforcement to. It feels a bit like electricity, a very general source of power that can be put to all kinds of use.

4 Likes
2

We had a bit of a discussion about this in the Discord server.

I have an goal to track urgency load. For some reason, I don’t seem to actually have any forum thread discussing it. Anyway, as I think I’ve explained somewhere, part of the reason I wanted to do it was precisely to try to prevent this kind of edge skating followed by “avalanche of derailments”.

Despite that… I forgot about beeminder yesterday and derailed on like 7 goals! Whoops!!! (Thankfully, all but one are capped at $5.)

We discussed a bit why this still ended up happening even though I beemind urgency load. Recall that the urgency load, which my goal asks to be under a certain number, is the sum over all goals of max(0, 7 - days of buffer). So basically, to get zero urgency load you need to have a week of buffer on every goal. If you had almost 7 days of buffer on almost every goal, you could set the target at some really small number (like, I dunno, 5), and then you absolutely could not allow any goal to edge-skate. Then you would be protected from this kinda thing.

Of course, in practice I don’t have a week of buffer on every goal. So I need to set the red line at some number which is still quite large (say 70, I have a lot of goals). I am skating along with, I dunno, 3 goals that have 1 day of buffer and 8 goals that have 3 days of buffer.

Once I’m in this position… bringing a goal off the edge, from 1 day of buffer to 2, is actually no better for getting urgency_load out of the red today than getting a goal form 3 to 4! So inevitably, when I’m tired and it’s late and I need to get urgency_load out of the red… I just add more days of buffer to a goal where it’s really easy to get a day of buffer. On the other hand, some goals are really hard to generate a day of buffer (either because it requires a lot of work, or because it’s a task I can’t actually do more than once a day), and those tend to languish. And so we’re back to edge skating.

We discussed various variations of the urgency_load goal which would put a bit stronger emphasis on avoiding edge skating rather than having the full 7 days of buffer. @gfredericks suggested setting the penalty vs. number of days buffer to look like 3 3 3 2 2 2 1 0 or something, instead of 7 6 5 4 3 2 1. Another option he suggested is just making the goal with the smallest buffer count for 3x as much. A couple options I suggested are simply only counting the N goals with the smallest amount of buffer, or using a modified formula, like say max(0, 3 - buffer days), which would make getting from 1 day of buffer up to 2 really matter.

I’m still unsure whether I’ll try one of these, or try a more complicated solution like described in the OP of this thread, or no change at all.

4 Likes
3

(I’m reading this all with great interest and trying to get “risks of diluting the sting” in perspective. If anyone’s evaluating the proposed designs with that in mind, please chime in, it’d help me! :brain:)

1 Like
4

I also have a meta goal to a similar end, which I described in detail (plus sharing the code) in this thread. Similar to @poisson’s urgency-load based goal, but the other way round (tracking the sum of buffers, so it’s an odometer, not whittle-down). As I explain the rationale behind having one in that post: “This way I can make sure that I still do the average on a list of goals but I get to choose what to do more of on a specific day. Plus, it helps to avoid the stress of having every single one in the red every day and burning the buffer due to akrasia rather than saving it for emergencies.” I guess I haven’t really been thinking about this as a way of handling “life happens” exceptions in one place, but effectively it also contributes to that: if most of my goals have buffer thanks to the meta goal, and “life happens”, I only derail the meta goal, can call it non-legit, and add more buffer for the “normal goals” to account for that day off-goals.

I am interested in your description of your setup. What is the unit for the meta goal? Is it something abstract like urgency load or my buffer days, unified across all “normal goals”? Or is it based on the actual units/commitments of the “normal goals”?

2 Likes
5

Basically all my metagoals have had the form of “log 1 unit if I did what was required for that day”, and then all the complexity goes into defining “what’s required?”; that’s how I’m able to work in day-of-week-based targets, or the solution to the problem where you want to both maintain a safety buffer and schedule a flat portion for a break.

I’ve also setup some of the meta goals to themselves have a lower than 1/day commitment, which means I get regular “breaks” from the need to keep up with everything else. The main reason I’m saying “metagoals” in plural is because I often have multiple so that different vanilla goals can be attached to different metagoals that have different commitments – e.g., one is strict (7/week) while another is laxer (5/week), and this lets me put very-easy goals in the first category and more burdensome ones in the second.

None of this would be viable without some automation to manage the complexity.

3 Likes