I’ve started experimenting with using the new urgency_load metric as more than just a metric, but as a way to help me build up buffer on my goals. But one frustrating thing I’ve found with it is that the number can go up during the day, making it difficult to know how much I actually have to do to satisfy the goal.
Could the metric be redefined such that it’s always calculated as if it were, say, the following midnight? (I’m tempted to ask for a user configurable setting so I could keep my earlybird deadline, but I’ll restrain myself. 
) That way the number would stay the same throughout the day except when new data or new goals were added or the user modifies a goal, rather than going up during the course of a single day even if the user hasn’t changed anything.
1 Like
I use the urgency load changing throughout the day! I find it incredibly motivating to wake up with an urgency load of 40 and work it down.
I use aggday to set which value I want for the day. (first, last, min, max…)
2 Likes
Oh, yeah, I totally agree that it should go down when you add data! And I’m using aggday, too.
The thing I don’t like is:
- Wake up with -20 to be safe.
- Satisfy goals that represent 5 urgency points.
- Look at the load and now it’s -23 to safe because I’ve passed some of my goal deadlines.
That kind of one step forward, three steps back feeling is pretty discouraging for me personally.
1 Like
I hear what you’re saying.
I mean, you can do what you want out of it right now with aggday first, right? Or even aggday min to be gracious to yourself?
I don’t personally use different deadlines for goals, unless I’m doing testing as a developer. I don’t like looking at my dashboard, getting everything looking good, and then a few hours later have a bunch I want to do. I prefer having my updates happen when I’m sleeping.
1 Like
No, aggday min doesn’t do it. I’m using aggday min right now. What that does is ensure that once I reach the needed load, I don’t have to worry about it for the rest of the day. It’s great for that.
But if the needed datapoint is 10 and the current point is 15, then I work for a while, and check again and the current point is 17, the fact that I’m using aggday min doesn’t fix my problem. I’ve still gone from needing to satisfy 5 units to needing 7. I’ve made negative progress.
1 Like
Hmm. I need to think about what you’re saying… I don’t quite get it.
If you work all day and your urgency load goes up, that’s a valuable signal, right? It means you didn’t work enough or on the right things to win the Red Queen’s race that day. I’m not sure how only taking the value once per day makes that better, except to make it take more days to realize you’re not keeping up.
However, there are at least two things that you are or may be doing that I haven’t internalized, and they may have a lot of implications here. I am not sure urgency load is useful to edgeskate with–I never have, and I haven’t spent much time thinking about it. I also haven’t thought about what it means to have a lot of deadlines throughout the day. I’ll keep working at it.
1 Like
Thanks for thinking about it!
Right, that’s why I suggested that the urgency load could be calculated as if it were the following midnight. That way you’re not deluding yourself into thinking you’re keeping up when you’re not. Instead, your just being pessimistic about when you’ll be able to satisfy the goal.
And what you gain from that is predictability–if anytime today I push my near goals this many days into the future, I will satisfy my urgency_load goal.
That’s something I currently have no way to know.
1 Like
Big caveat to this whole thing: I’ve only been edge skating this for about a week, and only switched away from my own implementation completely for about a day, so my views on this could change substantially as time goes on.
But I do hate not knowing what I’ll need to do to dispatch a beemergency.
1 Like
I’ve decided to stop edge skating urgency_load, so this is no longer an issue for me.
I think it’s still an issue though.
I think this is potentially a deeper issue with edgeskating a metaminded attribute of goals with different deadlines. If you have 24 different goals, each due a different hour, what could you metamind that wouldn’t be a moving target? Your metamind goal only has 1 deadline, and you have 24 different deadlines.
1 Like
Right, that’s why you have to “freeze” the metaminded attribute in some way.
Beeminder already has a way to freeze goal attributes that change during a day–aggdays. I would need to understand why aggdays aren’t sufficient here before having more of an opinion, I think.
aggdays are for data points. In this case, what you want to freeze is not a data point you post to beeminder, but an attribute, urgency load, that you get from beeminder.