"urgency load" metric

Akrasia
1

I’ve been playing with a metric to capture how much I’m skating the edge on my goals.

I have a good number of goals, usually around 60, and I have found it easy to lose track of progress. When I feel like Beeminder is breathing down my neck, I look and see mostly green goals, sit down and do work for an hour, and I look at my dashboard, and… it’s still mostly green. When I’m already in a grumpy mood, I need more basic feedback than “dates changed on a list of 60 items”.

I use Beeminder primarily as a way to balance my life, rather than to focus on a single “life’s work”.

I’ve rigged something up for me, and I’m ready to talk about it in public :slight_smile: Now, when I work on my Beeminder stuff, I can look at my urgency load before and after and see my progress super easily.

@dreev and I were talking about it recently, and he said:

The idea of Urgency Load is to construct a single number that captures how edge-skatey you are across all your goals. One way to do that would be to sum up how many safe days you have on all your goals. So the higher the number, the more safety, the better. But it’s not great how adding more edge-skatey goals adds more total safe days across all your goals. More goals means more (potential) urgency; that shouldn’t improve the metric! So Adam cleverly flips it around: Every day of safety buffer less than 7 is a day of urgency. Sum those over all your graphs and you have an urgency metric that you want to keep as low as possible. A beemergency adds a full 7 to your urgency load, having 6 days of safety buffer on something adds 1, etc. And adding new goals can at best leave your urgency load unchanged, if you keep them at 7+ days of buffer.

In short:

\text{urgency load} = \sum_{g\in \operatorname{goals}} \max(7-\operatorname{buf}(g), 0)

where \operatorname{buf}(g) is how many days of safety buffer a goal g has.

Thoughts? @dreev and I came up with “urgency load” which may not be the most attractive name but it seems to work.

9 Likes
2

Adam also had the idea to normalize it so that 0% would mean that every goal has at least 7 days of buffer (what we can call fully safe – see #15 of blog.beeminder.com/obscure) and 100% would mean every single goal is red.

It might be more understandable that way but I think less mindable. With Adam’s metric you know exactly what to do to get your urgency load down by 1: dispatch a beemergency or do the daily amount due on any goal (that isn’t already fully safe).

PS: Not to mention that normalizing like that ruins the property that more goals = more urgency. Actually I bet Adam had a less extreme normalizing in mind. In any case, I like the above argument for not normalizing at all.

2 Likes
3

I was actually thinking of just dividing my number by 7. A Beemergency costs 1, and a goal due tomorrow is worth 6/7ths. I still kinda like the raw 7 for Beemergency better.

Another thing I want to write: I like that adding new goals with lots of safety buffer doesn’t reduce my urgency. Other options that we’ve talked about suffer this problem, and they don’t map to the “Beeminder breathing down my neck” feeling.

3 Likes
4

This sounds super cool. How long have you been minding this metric? Are you using the metric goal to actively change behavior, or is this more of a tracking goal?

2 Likes
5

I’ve been beeminding emergency days since January, and urgency load since June.

Regarding behavior changer vs tracking… both, really. I’ve been trying for years to build a yes-o-meter, to help me support decisions for when to take on more things vs cut things off. This is quite good for that, so far.

4 Likes
6

How do beemurgencies on this goal tend to go? Do they occur a lot at midnight based on your other goal deadlines?

1 Like
7

Ah, I see your question. The road is far enough away from the goal that having an emergency on this goal isn’t really a possibility right now. I’d like to get there, but I don’t even have a good intuitive grasp of what rates mean with regards to life busy-ness yet.

2 Likes
8

Thinking about this, I immediately thought I’d want a normalized metric - adding more goals for me doesn’t mean I’m creating more capability (there are still only 1440 minutes per day), it just means I’m spreading the capability more thinly.

However, I guess it perhaps depends what your goals are: if they are externally driven metrics, then it is indeed perhaps appropriate to think of it as “urgency load”, which perhaps shouldn’t be normalised as it genuinely reflects more (external) commitments. For me they’re internally created goals, so it’s more about “on average, how close to the edge am I”, which should be normalised.

1 Like
9

This is a nice metric to track, but I have trouble seeing it as a good actionable goal. For any slope that makes you work to achieve the goal, you are likely to bump a bunch of goals just past 7 days and then the day turns over and you have a lot of goals that you need to deal with in order to not fail beeminder - pretty similar to the reason that road skating gets stressful.

I sometimes play a game of try to get at most one goal due by tomorrow, at most two goals by the day after, etcetera. It does set me up pretty well for having to do things all the time but always having the choice of doing a lot of one goal or a little of several (more flexibility without more leniency compared to having a single date in the future that you allow X goals within). But similarly, I can’t think of a metric for it that it would work out to beemind. (A way to generalize this into a number instead of just yes/no is to ask the farthest day in the future - or most recent day in the past - the stair pattern can start. But I don’t think that number is good for beeminding.)

3 Likes
10

If you’re good with it, I’d love to see your graph.

11
1 Like
12

My current hack integration also groups my goals by score in the comment, like this:

0: reviews; 3: meditation_days, meditate; 4: vegetarian_day_entries, overdue_marvin; 5: feedstime; 6: marvin_oldest_inbox;

13

Wait… does Amazing Marvin (which is what I assume you’re referring to…) have a Beeminder integration?

14

I rigged something up. I would need to talk with the Marvin folks again to see if it’s sharable (I wanna make sure I’m not slamming something on their end.)

Maybe send them an email asking if they have a Beeminder integration, get it on their radar again :slight_smile:

1 Like
15

I’m assuming your calculating this metric on a cron? How often per day does it run?

1 Like
16

On the standard zeno schedule, but I can hit refresh on the goal to pull a new calculation.

1 Like
17

@adamwolf, so far, which metric have you found to be more useful, eventhorizon (urgency load) or emergencydays (beemergencies)?

2 Likes
18

To be honest, beemergencies is less useful than urgency load–but I am not sure that’s how it would be for everyone.

A few weeks ago, I was asked if I could emergency help send get some projects ready for a space launch. Of course I wanted to say yes, but I’ve jumped into projects like this before and they’ve thrown off months and months of work… I was able to look at my urgency load and see that I could probably take it on… spent ~18 hour days on it for a week, got it done, and things did not get catastrophically off track.

5 Likes
19

I’m trying it out :smiley:

https://www.beeminder.com/narthur/load

2 Likes
20

Interested in this “load” idea. @narthur and @adamwolf - why are you making your urgency load goals cumulative, as opposed to keeping the current load under a certain amount? I’m struggling to understand and interpret the cumulative graph - it seems less useful that a non-kyoom one.

1 Like