Response to Continuous Beeminding: The Yellow Brick Staircase?

In the latest Daily Beemail, @dreev links to a doc outlining the idea of “Continuous Beeminding”

I started this as an email reply, but it just grew and grew. (Sidebar: Don’t tone down the esoterica! I like thinking about beeminder… and this thought experiment got me thinking.)

The thing is, like, man, quantifying things is tricky.

One way to think about beeminder is as a kind of currency exchange where every “unit” beeminded buys you a certain amount of “buffer time”. In beeminder as it is now, the smallest denomination of buffer time you can buy is 1 day. But in Continuous Beeminding, there is no minimum transaction.

As pointed out in the TPS-hour-per-day example in the doc, things get weird quick. An hour per day will have an “exchange rate” of 1:24… So, an hour buys you a full day’s buffer, and a minute buys you 24 minutes buffer, and a second buys you 24 seconds of buffer. But of course, once you get below a certain length of time, the whole idea of time spent working on a TPS report becomes kinda meaningless. And I’d argue that the break point is probably significantly higher than 3 minutes. What does three minutes working on a TPS report even mean? And I suspect that the same or similar problem applies to anything where the units-per-day is effectively continuous, or at least highly divisible. For example, when I was beeminding fruit and vegetable intake (someday I’m gonna do my writeup of what went wrong), I had my goal set at 5 servings per day, which I (roughly) estimated at 80 grams each. That comes out to an exchange rate of 1 gram for 3 minutes and 36 seconds of buffer. Now in this example at least the “measurement” makes sense (I know what a gram
of plants is), but actually implementing a goal this way would be ridiculous, because I’m not even weighing most things I eat, because that would be impractical and super obsessive.

Of course, the challenge of choosing reasonable units to beemind isn’t unique to Continuous Beeminder, but I suspect these problems don’t seem quite as apparent in Beeminder as it is now (Daily Beeminder? Discrete
Beeminder?) b/c you have to “buy” buffer in 24 hour chunks. For example, nobody’s going to set up a beeminder to explicitly track 86,400 seconds of work on a TPS report per day.

So here’s an idea that might get at some of the granularity and elegance that Continuous Beeminding has:

Turn the road into stairs.

If you want to track something hourly, the “flat spot” on each step is 1 hour long. If you want to track daily, the flat spot is 24 hours long, and so forth. Every time a deadline passes, the “road” ratchets up the y axis by the units required. So if you want to do 5 things per day, it goes up by 5 at the deadline. If you want to do 3 things every 12 hours, that’s fine too.

It keeps deadlines, but makes the units flexible. And it keeps the, uh, continuousness, because your graph could be updated “live”. Your flappy bird is always moving across the x axis, but instead of trying not to fall to the ground you’re trying to avoid smashing headlong into the next step. And, It could be elegantly ratcheted by dragging the staircase up and down the y-axis.

… I gotta say, the more I think about this, the more I like it!


You may have to buy buffer in chunks of one day at the moment, but everything that you put in the piggybank counts until you’ve got enough credit to buy that day.

Right now I use tricks like ‘just read one page’ to set a really low bar for buying a new day, with auto-ratchet configured to soak the excess buffer back up again. CB could be an antidote to that insanity.

Fun fact: CB entered into Danny’s brain after a conversation we had during my first visit to Portland (iirc). I’ve forgotten what I proposed at the time, but I do know that it was less extreme, less literally continuous.


I love this yellow brick staircase idea. (Thank you, @mwalla! Btw, DM me a snail-mail address if you’d like stickers!) We were philosophizing about it more today while thinking about how to make weekends-off less cumbersome in the upcoming fancy road editor. I was thinking about how to generalize the staircase idea even further…

First a recap of continuous beeminding: You’re playing a flappy-bird game where your real-world activity keeps your datapoint jumping up as time forces it inexorably to the right. You have to always stay above the road. Collide with it and you die. Very intuitive so far.

But it’s important to have daily deadlines and sometimes weekends off. So, like @mwalla suggests, the road is actually always a staircase, not a line. By default it steps up every day at a particular time. So the current Beeminder is equivalent to continuous beeminding with a day-based staircase. We then just generalize that further to allow staircases within staircases. At the macro-level you have a weekly staircase with how much is due by Friday each week. Within the week you have a micro-staircase forcing daily progress on workdays. And maybe a micro-micro staircase to force hourly progress during business hours.

If you really wanted you could even go to the other extreme and have a single giant step up in a year to have your 1000-page book written or whatever.

The point is it’s an infinitely customizable nannybot enforcing progress on any timeline at any granularity you choose.

Nudge! That reminds me of @alys’s 1000 Days of Fruits and Vegetables | Beeminder Blog


Fractal beeminding, right down to units of the Planck time! :smiley:


I thought there was a more recent discussion of this, but I couldn’t find it. Sorry!

Here’s my use case for some sort of continuous beeminding (this might be more complicated). I have a do-zero goal for reading after my bedtime. Last night, I had a very late dinner, pulled out my phone while eating, and then subsequently realized I had done some post-bedtime reading - so there’s a derailment on katriel/bedtime. Then, instead of going right to bed, I thought, well, I’ve already derailed, may as well read some more. Whereas, in my ideal world, I would derail immediately, and then once again be in the danger mode of a second derailment that same night.

Now, I realize there’s a personal workaround for this problem - I can commit to paying my pledge a second time via IFTTT if I derail on this or similar goals and then do something that constitutes a derailment again. I’ve been beeminding long enough that the rules I set for myself in fine print are iron clad, at least if I remember them, and I usually do. So I’ll do that now. But it has taken me a few years to figure this out…


Ah, such a good use case!

This might be the more recent thing you’re thinking of:

Dumb question: is this specific to do-less goals?

Not a dumb question at all - I have to think hard to figure out the answer. In practice for me it is specific to do-less goals.

I can think of a convoluted scenario where it would apply to a do-more goal. One of my do-more goals is katriel/wake - I have to get up within 5 minutes of my alarm going off. Conceivably, I could grab my phone in bed, start playing with it, realize I have derailed, and decide I may as well just lie in bed since I’ve already derailed. Conceivably I might want my penalty to grow larger the longer I lie in bed.

1 Like