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!
