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.

1 Like