Beeminder Blog

CGP Grey's Weekend Wednesday

dreev — Tue, 23 Jun 2026 00:00:00 GMT

Here’s a simple madhack from one of my favorite YouTubers, CGP Grey: Weekend Wednesday. His video is pretty pithy and persuasive but let me make my own contribution to the internet by turning it into my own typed words that you can read quieter and faster.

Claim: Five workdays in a row is too much. You’re drained by the end of the week and your productivity is plummeting. Then you need Saturday just to recover and so it only feels like one day of actual relaxation on Sunday before the cycle starts over.

Solution: Swap Wednesday and Saturday. Now you just have two days of work, a break, then three days of work, followed by another day off.

The advantages are thus:

More productivity due to more frequent recharging
Weekend days you can enjoy more because you’re less drained
A non-work day (Wednesday) that’s off-sync with the rest of the world so you can do recreational things with less crowds
A workday (Saturday) with few interruptions.

Image: CGP Grey

I’m not fully sold on all this myself. The “being drained by the end of the week” concept isn’t one I really relate to, so the whole thing feels inapplicable. And there’s a possible downside, pointed out by Philip Hellyer who tried taking Wednesdays off once, in addition to normal weekends. He found that in practice it meant every workday was either a Monday (ramping up) or a Friday (ramping down), which was highly unproductive for him, at the time. But he adds that that was before Beeminder!

Obviously if you have kids in school, or have any number of other reasons to stay more fully in sync with the rest of the world, the whole thing may be a nonstarter. But Weekend Wednesday seems like the kind of thing some Beeminder users will want to try.

Thanks to both Nathan Arthur and Mary Renaud who first pointed me to this idea.

Binge and Purge: A No-Good Very Bad Anti-Akrasia Strategy

dreev — Tue, 09 Jun 2026 00:00:00 GMT

This is about TV and video games, not food, to be clear. This blog post started its life as a Madhack Monday based on a random piece of life advice from my friend Jacob Falkovich. Specifically this one: “Binge a show / video game for a couple of weeks, then take a break from TV for a couple of weeks. Trying to limit yourself to an hour a day is less fun and more addictive.”

I was surprised how much that resonated with people, even in the Beeminder community, so I want to give my counterarguments!

First of all, the verb “binge” is a clue that this isn’t healthy! But, ok, maybe you don’t mean it in an unhealthy way. Live a little once in a while, etc. Fine. But clearly there’s an addictive element if the concept of binging is even on the table. So having some insurance against that is only prudent, right?

Can you tell where I’m going with this? If you want to occasionally binge a TV show, that’s a perfectly reasonable choice… if you make it dispassionately. Pick the average number of hours per week you’re ok devoting to TV / video games / whatever and beemind it. If you agree with Jacob that binging for a couple weeks and then abstaining for a couple weeks is more fun, great. Just let Beeminder keep you honest about maintaining that binging-vs-abstaining ratio. Build up your safety buffer and then go crazy using it all up.

I claim it’s even more fun that way because you’ve actually earned the binge. Enjoy it guilt-free!

Counterarguments

Beeminder superuser Lanthala was not convinced by my argument. She says her brain rebels against moderation and that trying to limit a fun activity to, say, an hour a day means she’ll either stop caring about the activity at all or obsess about it for the other 23 hours. “But,” she says, “if I go ahead and let myself be immersed in it as much as I want, the interest will run its course in a week or month.”

(For Lanthala this works in both directions: If she has a necessary but aversive task, a Beeminder goal that breaks it up into an hour a day will make her much more miserable than ripping off the band-aid. Doing it for 9 straight hours until it’s done can mentally transform it into a fun or interesting project.)

Lanthala goes on:

Current best-practice advice for parents trying to teach their kids to “eat in moderation” is not to strictly limit the amount of junk food they can eat, but in fact to regularly (say, once a week) let them eat as much as they want (yes, binge), to let them discover that there is such a thing as enough gummy bears. If you never let them find that out, they’ll always want more gummy bears.

She quotes an article from Parents.com claiming that this is a common recommendation for kids and junk food: “Being able to fill their craving will decrease their desire for such foods instead of piquing it.”

I think Bee and I tried that one Halloween when our kids were little — “free rein on candy today only!” — and both kids made themselves sick but it didn’t change their relationship with candy at all. So I’m skeptical but it’s plausible it’s what works best for some people. Maybe not most Beeminder users though. Lanthala admits as much and says that her own use of Beeminder rarely involves tracking time. She beeminds things that she really does have to do each day, like teeth-brushing.

So far so fair, but I don’t think any of this is an argument against beeminding TV / candy / whatever it is. Let’s assume that meting it out sucks all the fun out. Totally reasonable utility function one might have! But that just means you need to decide what an upper limit on a binge should be and then just wait. Mark it on your calendar for when you’ll have enough safety buffer built up that Beeminder will let you have that binge.

The point is to still think in terms of an acceptable average amount per week and then let Beeminder do the math from there.

Lanthala Remains Unconvinced

“For many people,” says Lanthala, “restricting something makes you want it more.” She continues:

Think of everyone who’s ever dieted who finds that suddenly food is all they can think about, or when you had no interest in going outside but now it’s raining and you can’t so now you’re desperately wishing you could go outside. If you teach your kids that candy is a rare, special treat they can only ever get a few times a year, then whenever they do get candy, they’ll eat as much as they can, because hey, they’ll only get it a few times a year! Gotta get while the getting’s good, ignoring any sense of your body telling you that you’re no longer enjoying it. On the other hand, if they know that every Sunday is Ice Cream Sunday and they can eat as much ice cream as they want — even thirds! — they’ll learn that actually, ice cream is pretty common, easy to come by, and there’s no reason to eat thirds if you’re feeling kind of sick after seconds.

This doesn’t match my own experience. If I only get ice cream on Sundays, I’ll stuff myself silly with it every Sunday.

Basically, I think there’s danger that the binge won’t really self-limit. That you’ll stay up till 3am watching Netflix every dang day. Lanthala seems to be saying, “so be it, any attempt to restrict my consumption will backfire”. I can’t deny her lived experience, but I guess I hope that most people are more like me and can employ systems to limit things like TV and candy that left to our own devices we’ll abuse. Or, better yet, be one of those impressive humans who just don’t have a problem with overindulgence in the first place. Come to think of it, if this “binge until it self-limits” strategy works for you, maybe you’re secretly one of those impressive humans.

Nathan Arthur with the Synthesis

Nathan Arthur says we’re both right:

Personally I would binge YouTube and computer games to the point of losing entire nights of sleep. I needed limits in order to function at all. But once I had those limits, I also needed to do some serious work to create a healthier relationship with those activities and address the things I was avoiding by going to those activities. Both were important pieces for me.

Amen?

Greppable Errors

dreev — Tue, 26 May 2026 00:00:00 GMT

Workerbee Simone saw a weird error on Beeminder one day and sent me this screenshot:

That rang no bells but naturally I grepped the source code for “ERROR_0304” and found this:

return "ERROR_0304" // passed in bad format string; should never happen

My past self was saying, “if this ever happens, which it totally won’t but, y’know, if, then my future self should immediately get pointed at this line of code”. And that is what happened.

This could be too simple and obvious to blog about but until now, googling “greppable errors” wasn’t turning up anything (not anything human-written anyway) to explain it. So, you’re welcome, Internet.

(Also, “grep” is the nerdier term for “control-f”.)

If you’re curious where the “_0304” suffix came from, it was purely to make sure the string would be unique and greppable. I generally use the hour and minute of whatever my watch says as I’m typing, so apparently wrote that line of code at 3am, as I’m wont to do. The point is, it serves as a crude but good enough Universally Unique Identifer (UUID). Ok, not literally universally unique but more than good enough. It’s a safe bet that after we’ve hit publish on this blog post, searching “ERROR_0304” across the whole wide internet will bring you right here.

(Relatedly, it never ceases to amaze me that that’s true for most five-word snippets from any random sentence from any page on the whole internet. Go ahead, try googling “for most five-word snippets”. As I type this, it matches zero documents on the internet so presumably as you read this, it brings you right back here.)

A hierarchy of errors

Here’s another obvious thing. Errors want to be as high on this list as possible:

Fail never (reserved for God and Mary Poppins)
Fail gracefully
Fail loudly
Fail opaquely
Fail silently

Greppable errors help you avoid the bottom two levels, yielding loud failures that leave a nice breadcrumb trail for fixing or improving them.

Like if you’re adding a sanity-check in your code — e.g., you are conscientiously checking that a file exists before trying to read its contents — start by catching that exception in a way that the end user will point you to the place in the code where the check failed. Maybe later you’ll decide that’s too embarrassing and can add logic to fail more gracefully than that. But the worst of all is to fail silently and the second worst is to fail opaquely. Almost-best is to fail loudly. If it’s really worth it, the best, short of apotheosis, is to fail gracefully.

In conclusion, here are some specific implications and advice:

Do error-checking! Make sure a file exists before you try to read from it. Use your napkin at the dinner table. Basic manners and hygiene!
Don’t just print “file not found”, use a greppable error that points you at the right place in the code.
Follow the Anti-Robustness Principle aka Anti-Postel: make everything break loudly when there’s an error.
YAGNI. Don’t speculate and anticipate. Fail loudly and greppably first and wait to see those failures in the wild before refining your error handling.
I like to take this to its logical conclusion: Instead of “fallback handling”, do asserts that force a crash. Sprinkle asserts liberally throughout your code. See also offensive programming. (Emphasis on the first syllable of “offensive”; not like error messages with slurs.)

Forster Lists: Or Mark Forster's Final Version

Mark Forster — Tue, 12 May 2026 00:00:00 GMT

RIP Mark Forster (1943-2025). We first met Mark (on the internet) in 2012, which is also when he started using Beeminder. Forster’s systems and insights have featured in many Beeminder blog posts over the years. But the best of all hasn’t appeared until now. Years ago we collaborated with Mark on a guest post by him, to be published here on the Beeminder blog, with a definitive version of the system he called “Final Version”. Final Version didn’t turn out to quite be the final version of his system, which is why we sat on this draft. But it’s the version we’ve always liked best and is what we mean when we refer to Forster Lists (or sometimes Dot Lists). So without further ado, here’s Mark Forster in his own words (and light editing from us) to explain the system.

Quick Start

Add tasks to the bottom of your to-do list as you think of them
When ready to work on your tasks, put a dot in front of the very first task on the list
Continue down the list until you hit a task you want to do (not must do) before doing the task you just dotted
Put a dot in front of that task and repeat until you reach the end of the list
You now have a chain of tasks with dots in front of them
Do these dotted tasks from bottom to top
You can either complete a task and cross it off or start a task, cross it off, and re-add it at the bottom
If urgent tasks come up, add them to the bottom with a dot, so they’re done first

Quicker Start

Hello from the future. Forster Lists probably work best on paper but for any hands-on learners, I, Bethany, implemented a little web version of the system that might even be self-explanatory:

Bee’s Forster List App

Back to Mark Forster… (and more from us at the end)

Introduction

Here are the long-awaited instructions for the Final Version (FV) time management system. I don’t know if it’s the best time management system ever devised. What I do know is that it is the best time management system that I [writing circa 2012-2015] have ever used myself. It’s shown itself to be resilient, responsive, and very quick.

FV is based on my earlier time management systems, particularly the extensive range of AutoFocus and SuperFocus systems developed over the last three years. These were unique in that they were constantly developing with the assistance of a large band of commenters on my website. Anyone who has tried one or more of these systems will recognize the strong family resemblance that they have with FV. The most striking resemblance is that they are all based on one long list (either paper or electronic) which can be used to capture just about every possible action that springs into one’s mind. There is a minimum of special markings or annotations.

Such a list depends on an effective algorithm to process it. There are three main requirements which have to be kept in balance. These are urgency, importance, and psychological readiness. Traditional time management systems have tended to concentrate on the first two of these. The neglect of psychological readiness is probably the reason that most people don’t find time management systems particularly effective or congenial.

The most distinctive feature of FV is the way that its algorithm is primarily based on psychological readiness — this then opens the way to keeping urgency and importance in the best achievable balance.

The FV Algorithm

The FV algorithm is loosely based on two powerful decision making methods — structured procrastination and Colley’s rule — though neither need be understood to use the finished algorithm.

The FV algorithm uses the question “What do I want to do before I do x?” to preselect a chain of tasks from the list. What exactly is meant by “want” in this context is deliberately left undefined. There may be a whole variety of reasons why you might want to do one thing before another thing and all of them are valid.

The chain always starts with the first unactioned task on the list. Mark this task with a dot to show that it’s now been preselected. Don’t take any action on the task at this stage.

This task then becomes the benchmark from which the next task is selected. For example, if the first task on the list is “Write Report”, the question becomes “What do I want to do before I write the report?” You move through the list in order until you come to a task which you want to do (not “must do”) before writing the report. This task is now selected by marking it with a dot and it becomes the benchmark for the next task. If the first task you come to which you want to do before writing the report is “Check Email”, then that becomes the benchmark. The question therefore changes to “What do I want to do before I check email?”

As you continue through the list you might come to “Tidy Desk” and decide you want to do that before checking email. Select this in the same way by marking it with a dot, and change the question to “What do I want to do before tidying my desk?” The answer to this is probably “nothing”, so you have now finished your preselection.

The preselected tasks in the example are:

   Write report
   Check email
   Tidy desk

Do these in reverse order, i.e. Tidy desk, Check email, Write report. Note that as in all my systems, you don’t have to finish the task — only do some work on it. Of course if you do finish the task that’s great, but if you don’t then all you have to do is re-enter the task at the end of the list.

Once you have taken action on all the preselected tasks, preselect another chain of tasks starting again from the first unactioned task on the list.

That’s it! You’re now ready to go. Everything else is further examples and explanation.

A Longer Example

In this example for ease of understanding no new tasks are added while working on the list. This of course is unlikely in real life.

Your initial list of tasks:

   Email 
   In-Tray
   Voicemail
   Project X Report
   Tidy Desk
   Call Dissatisfied Customer
   Make Dental Appointment
   File Invoices
   Discuss Project Y with Bob
   Back Up

Put a dot in front of the first task:

 • Email
   In-Tray
   Voicemail
   Project X Report
   Tidy Desk
   Call Dissatisfied Customer
   Make Dental Appointment
   File Invoices
   Discuss Project Y with Bob
   Back Up

Now ask yourself “What do I want to do before I do Email?”

You work down the list and come to Voicemail. You decide you want to do Voicemail before doing Email. Put a dot in front of it as well:

 • Email 
   In-Tray
 • Voicemail
   Project X Report
   Tidy Desk
   Call Dissatisfied Customer
   Make Dental Appointment
   File Invoices
   Discuss Project Y with Bob
   Back Up

Now ask yourself “What do I want to do before I do Voicemail?” You decide you want to tidy your desk.

 • Email 
   In-Tray
 • Voicemail
   Project X Report
 • Tidy Desk
   Call Dissatisfied Customer
   Make Dental Appointment
   File Invoices
   Discuss Project Y with Bob
   Back Up

There are no tasks you want to do before tidying your desk, so now take action on the dotted tasks in reverse order:

   Tidy Desk
   Voicemail
   Email

Your list will now look like this (I’ve removed the tasks that have been actioned but if you are using paper they will still be on the page but crossed out):

   In-Tray
   Project X Report
   Call Dissatisfied Customer
   Make Dental Appointment
   File Invoices
   Discuss Project Y with Bob
   Back Up

Now start again with the first unactioned task on the list, In-Tray, and repeat the same procedure. The only task you want to do before In-Tray is Back Up. As this is the last task on the list there are only two dotted tasks:

 • In-Tray
   Project X Report
   Call Dissatisfied Customer
   Make Dental Appointment
   File Invoices
   Discuss Project Y with Bob
 • Back Up

Do the two dotted tasks in reverse order:

   Back Up
   In-Tray

So the list now looks like this:

   Project X Report
   Call Dissatisfied Customer
   Make Dental Appointment
   File Invoices
   Discuss Project Y with Bob

So far the tasks have been relatively trivial, but the Project X Report is something that you have been putting off doing for a long time. So repeat the procedure:

 • Project X Report
   Call Dissatisfied Customer
 • Make Dental Appointment
 • File Invoices
   Discuss Project Y with Bob

You now file your invoices, make a dental appointment and make a start on the Project X Report.

In your final pass through the list you Discuss Project Y with Bob and Call Dissatisfied Customer.

So the tasks on the original list have been done in the following order. The tasks in italics are the ones at the beginning of each scanning process.


   Tidy Desk
   Voicemail
   Email
   
   Back Up
   In-Tray
    
   File Invoices
   Make Dental Appointment
   Project X Report
   
   Discuss Project Y with Bob
   Call Dissatisfied Customer

Notice what has happened here. The root tasks (the ones in italics) have been done in strict list order, regardless of importance, urgency or any other factor. Some of them are relatively easy (e.g. Email) and some are relatively difficult (e.g. Project X Report) or you are reluctant to do them (e.g. Call Dissatisfied Customer).

Each of the root tasks is preceded by a short ladder of tasks which are in the order in which you want to do them. The number and difficulty of the tasks in the ladder tend to reflect the difficulty of the root tasks.

Additional Tips

The best way to sink any time management system is to overload it right at the beginning. FV is pretty resilient, but at this stage you aren’t. So build up the list gradually. My advice is to start off with the tasks and projects that are of immediate concern to you right now, and then add more as they come up in the natural course of things.

Tasks can be added at any level, e.g. Project X, Plan Restructuring, Call Pete, Tidy Desk.

If the first task on the list can’t be done now for some valid reason (e.g. wrong time of day, precondition not met, bad weather), then cross it out and re-enter it at the end of the list. Use the next task as your starting benchmark.

If at any stage you find that a task on the list is no longer relevant, then delete it.

If you find that your preselected list is no longer relevant (e.g. if you have had a long break away from the list), then scrap the preselection and reselect from the beginning. A shorter way to do this is to reselect only from the last preselected task which you haven’t done yet.

If one or more very urgent things come up, write them at the end of the list and mark them with a dot so that they are done next. If something already on the list becomes very urgent, then move it to the end of the list and mark it with a dot in the same way.

Remember that the aim of any time management system is to help you to get your work done, not get in the way of doing your work. So don’t be afraid to adjust priorities if you need to. However try to keep this to a minimum — stick to the rules whenever possible as they will ensure you deal with your work in a systematic way.

Why It Works

At the beginning of this article I said there were three factors which every time management system needs to address: urgency, importance and psychological readiness. Let’s see how FV deals with each of these.

Urgency. Because of the nature of the preselection process, urgent tasks tend to get selected — generally speaking the human brain wants to do things that it knows are urgent. If things come up that are particularly urgent they can be added to the preselected list at any time.

Importance. Generally speaking the human brain is a bit less keen on doing important stuff than it is on doing urgent stuff. This is particularly the case when the important stuff is difficult. However the FV preselection process ensures that tasks towards the beginning of the list are given as much attention as tasks towards the end of the list.

Psychological Readiness. This is where FV really enters new dimensions. By using a preselection process, the brain is softened up towards the selected tasks. But this isn’t all. The selection process is based on what you want to do. This colours the whole preselected list so that even the first task, which you may not have wanted to do at all, gets affected. In addition, doing the list in reverse order, with the least wanted task last, uses structured procrastination to get the tasks done.

Posthumous Postscript

Hello again from Danny and Bethany in 2026. Forster Lists (Dot Lists) sure have stood the test of time! There’s a surprising amount of cleverness in that simple protocol:

Colley’s rule
Structured procrastination
GTD-style review
Distraction logging.

Colley’s rule is like an anytime algorithm for picking the most important task. You start with an arbitrary default and continuously preempt it with tasks you want to do first. Structured procrastion leverages your own dumb pscychology to keep you productive despite being a little (or a lot) ADHD. GTD-style review is the anti-staleness measure. And, finally, distraction logging lets you capture everything that crosses your mind without those thoughts constantly derailing you.

Mark didn’t say a lot about that last one — distraction logging — and since our own previous discussion of it is currently buried in an old Beeminder blog post on Tocks, let us end by singing its praises in the context of Forster Lists.

We love this aspect of Mark’s system, where anything that pops into your head you can just add it to the list and trust that you’ll see it later. Also it helps ensure the whole list doesn’t become something you dread even looking at. There are ugh-y things in there but you’re also constantly dumping shiny things in. This reduces the temptation to let yourself be distracted from the task in the current chain. By the time a task pops up in a future chain you may decide it wasn’t important and can just cross it off. But the key is that with so many unimportant tasks getting dumped in, you need to make sure important ones don’t die in that sea. Which Forster’s system accomplishes beautifully.

Coupled Sliders for Pledges and Pledge Caps

dreev — Tue, 28 Apr 2026 00:00:00 GMT

Announcement: You can now jump down as many pledge steps as you like without waiting a week between jumps. And pledges and pledge caps don’t have to be changed separately — the right things just happen, like if you push the pledge cap below the current pledge, that starts a one-week timer for both of them to change together.

(Review: Your pledge on a Beeminder goal is how much you have at stake: the amount we charge you each time your datapoints deviate from the bright red line on your graph representing what you committed to maintaining. Beeminder has a core concept of an akrasia horizon, meaning you can change your mind about any aspect of your goal — including how much money is at stake, or ending the goal entirely — but any such change takes a week to take effect. So you can change your mind for a thought-out reason but never impetuously or out of laziness. Never akratically.)

Until now (actually a couple weeks ago, when this went live) the only option for lowering your pledge was to drop it one level, starting the akrasia horizon countdown. A week later, you could repeat that process to drop another level. And changing your pledge cap was a completely separate thing you had to remember to do after waiting for the pledge to drop. If you wanted to drop your pledge from, say, $270 to the minimum of $5 and make sure it stayed there, that was literally a month-long operation ($270 → $90 → $30 → $10 → $5).

But now the long national nightmare is over.

We do have at least one user who liked the previous status quo. Beeminder is all about tools against temptation and so the friction of reaffirming each pledge drop could be viewed as a feature. This particular user likes to reward themself with a pledge drop whenever they hit a long enough streak. So they can still do that but will need a bit of self-discipline — sticking to one pledge drop at a time — that previously Beeminder gave them for free. Since this user is wildly outnumbered by those who hated the tedium of changing pledge levels, we’re not including an option for spacebar heating. But since this isn’t strictly a Pareto improvement, we were duty-bound to blog about it.

Conceptually, the new coupled sliders for pledge and pledge cap work like this:

Skeuomorphism! The little cowcatcher that sticks down from the yellow pledge knob means that if you physically slide the pledge value higher, it brings the pledge cap with it. The cap can’t ever be lower than the pledge. Conversely, if you slide the cap lower it pushes the pledge along, for the same reason, maintaining the pledge ≤ cap invariant.

In reality, it’s like this:

We think it’s more obvious when you interact with it yourself, so we made a little mockup version. Try sliding the sliders back and forth and see what they do:

Simple, right?

Wait, One Wee Weirdness

This is mostly too niche to care about, but for completeness, if you, ill-advisedly, have a Beemium plan then something weird happens if you slide the pledge all the way to $0 (as only Beemium people are allowed to do). Namely, in that special case, the pledge cap will also snap itself to $0. The reason is a little arcane. Remember the feet-wetting feature? When you first create a goal you can choose to have the pledge be at $0 just for the first week, while you get your feet wet, after which it automatically bumps itself to $5. It turns out that that doesn’t quite play nicely with the Beemium perk of allowing goals to be at $0 indefinitely. Not the way we implemented it anyway. This is a big part of the reason for deprecating the Beemium plan — all the confusing special cases and hard-to-anticipate interactions with other features like feet-wetting.

The point being, if a Beemium user sets their pledge to $0, the feet-wetting will make it bump itself up to $5 a week later. The workaround is to set your pledge cap to $0 to force it not to do that. And since we don’t want a Beemium user to have their pledge go up from $0 when they weren’t expecting it to, we have this dumb special case to make the pledge cap also go to $0 by default. You can then bump it back up if you want. Just keep in mind that without a $0 pledge cap the pledge will always bump itself back to $5 after a week.

Akrasia Horizon Immunity: Or Getting Dark Green

dreev — Tue, 14 Apr 2026 00:00:00 GMT

A full 10 years ago we published a listicle, “16 Obscure Beeminder Features”. Number 15, we could say, surprised us. With its longevity and practicality. Since we don’t actually want to clickbait you, here it is:

If you have over a week of safety buffer you’re immune to the akrasia horizon.

Quick Review: Akrasia and the Akrasia Horizon

Akrasia (also defined in the sidebar of the blog) means acting against your own better judgment. Beeminder’s akrasia horizon refers to the restriction that, while you can make your goal easier or even end it altogether at any time, the change takes a week to take effect. So you can change your mind about your commitment for a thought-out reason, but you can’t do so akratically. See our help article for more.

In short, akrasia horizon immunity means that you can immediately flatten your bright red line and — though it takes a week for the flattening to take effect — by the time you run out of safety buffer you’ll have reached the flat spot.

In our blog post introducing the rainbow dashboard, we point out that goals with 7+ days of safety buffer are shown in a subtly darker shade of green, to remind you that you’ve achieved akrasia horizon immunity. Quoting ourselves:

If something comes up or you decide you hate your Beeminder goal (it happens), you can click Archive or schedule a flat section of the bright red line. It takes a week for such changes to take effect, but, lucky you, you have that much safety buffer! So instead of clicking Archive or scheduling your break and then toughing it out for another week, you can do that and then immediately check out. By the time your safety buffer runs out, your break will begin. Your friends will be dark green with envy.

Of course if you had the discipline to maintain a week of safety buffer you wouldn’t need Beeminder in the first place. But it’s a nice little carrot to go with the stick.

Beeminder ♥ BoardGameGeek

bsoule — Tue, 31 Mar 2026 00:00:00 GMT

BoardGameGeek is an online community for board and card game geeks. They have reviews of every board game imaginable, from Your Favorite Niche Game, to Candy Land, to Cribbage, as well as community forums, the rules, etc. It’s kind of a forum meets a wiki meets blog.

It’s a great resource for finding new games to try, or recalling that one game you used to play in Joe’s basement every Friday before the X-Files came on.

Once you create an account you can track your board game collection, write session reports, and log your plays. Which is where the Beeminder integration comes in. We’ll automatically track your plays of either a specific game, or all games.

To create a goal, head to beeminder.com/new, pick the BoardGameGeek icon from the list of integrations, and answer the questions about how much you want to commit to game playing. Or if that sounds too hard, here’s a button:

Board Game Geeks Click Meeeee

Um, I just wandered in from BGG; what is Beeminder?

Welcome aboard(game)! You might want to check out our getting started guide in our Help Docs, and then get yourself signed up. Assuming you’re on board with the commitment device and game for paying money if you go off track, the beauty of an autodata integration is that you don’t normally need to interact with Beeminder once you’ve gone through the process above of setting up your commitment. Just log things in BGG like normal and Beeminder alerts you if you need to log more game playing.

(See also the full documentation of the BoardGameGeek integration in our help docs.)

The Sheeple Strategy

dreev — Tue, 17 Mar 2026 00:00:00 GMT

This is pretty obvious and, by definition, is what most people already do, but we’ve found the concept handle useful. When we notice one of our concept handles has stuck, it’s handy to have a blog post to link to that defines it.

In this case, it’s a strategy for minimizing software headaches. Namely, to delay software upgrades (not counting security updates — always do those) long enough that you’re always on whatever version the majority of people are on. Safety in numbers! I use the heuristic of always being one version behind whatever the very latest is. Like for macOS, my laptop wants me to upgrade to Tahoe but I’m staying put on Sequoia. Until I hear about whatever Tahoe’s successor is. Then I’ll finally upgrade to Tahoe.

Maybe I’m being a bit extreme on that one. My friend Serine Molecule suggests a tempered sheeple strategy of merely waiting to upgrade to the next major macOS version until it gets its first point release. And of course a fully strict sheeple strategy would be to always upgrade to whatever has the most market share:

Turns out I’m some months overdue for upgrading to macOS Tahoe, if we believe this golem-generated market share chart.

Of course if everyone followed the sheeple strategy we’d have zero progress ever. So the more pro-social version is to diligently upgrade at least to the majority version and bonus points for taking one for the team sometimes and braving the bleeding edge. And realistically there are enough people doing that because they’re compelled to (as I sometimes am myself). So you can consider yourself to have done your part by following the most sheeply version of the sheeple strategy. At least you’re not a straggler.

Generalizations

If you’re a web developer you probably know about “Can I Use”. A prudent sheeple strategy is to use a fancy JavaScript feature when something like 90% of browsers in the wild support it. (The other half of the sheeple strategy here, as an end user, is to expect developers to do that and make sure you’re in that 90%.)

And to go weirdly far afield, there’s a classic Scott Alexander post I’m enamored with that advocates a sheeple strategy for language usage: “Give Up Seventy Percent Of The Way Through The Hyperstitious Slur Cascade”.

One more example, back in the realm of tech: The last time we had multiple hours of downtime (see status.beeminder.com for gory details) was due to a huge data center outside of New York City having some kind of meltdown. It’s plenty embarrassing that we’re not robust to such things but being located in a popular data center of a popular cloud provider is another sheeple strategy. In this case it had the advantage that enough of the rest of the internet was down that our users treated it as an act of God and, I guess, blamed us less. Again, not something to be proud of, exactly, but what did you expect with a name like “sheeple strategy”? Still, it is sometimes the unironically savvy strategy. And now you know what to call it, you’re welcome.

Related Concepts

Clive Freeman used to call this a fast follower strategy, which is a business term for the counterpart of the first mover. See “Second-mover advantage”.
Theo Spears points out the idea of innovation tokens, from the classic Dan McKinley essay “Choose Boring Technology”.
Also via Theo Spears, the technology adoption life cycle as popularized in Crossing the Chasm.

Gresham's Law of Beeminder Deadlines: Or Death to Deadline Snoozing

dreev — Tue, 03 Mar 2026 00:00:00 GMT

Deadline snoozing in Beeminder refers to scooching your deadline later as it’s bearing down. Traditionally we’ve allowed any deadline changes until six hours before the deadline. But we’ve always hated that. It’s arbitrary and hard to remember. We have a whole essay railing against such things — the Anti-Magic Principle, we call it.

Ok, now for a quick economics digression. Some of you may know Gresham’s Law. It’s generally stated as “bad money drives out good” but the idea generalizes. Another famous bit of economics theory is the “Market for Lemons”. Suppose people sell their cars on eBay or wherever, and some cars are so-called lemons that are constantly breaking down and other cars are the opposite, peaches. Key is that you can’t tell a lemon from a peach till after you’ve bought it and driven it for a while. So if you’re car shopping, you’d gladly pay more for a peach than a lemon but, since you can’t be sure you’re not buying a lemon, you won’t pay peach prices. That means if you’re selling a car, and you know your car is a peach, you can’t get a fair price for it in that market. You can tell buyers your car is a peach, but that’s cheap talk [1] and they won’t believe you. So, as economists love to say, solve for the equilibrium. Everyone selling a peach flees that market and everyone selling lemons flocks to it. The bad drives out the good.

By rough analogy to all that, we’re coining Gresham’s Law of Beeminder Deadlines: Akratic deadlines drive out intentional ones. Presuming you’re like us, when something comes up and you snooze your deadline, it’s like a retrogressive ratchet. You never put the deadline back where it should be because it’s too onerous to do that within your akrasia horizon. You’d have to muster the discipline to make the deadline earlier again when that deadline is already bearing down on you.

So, in light of Gresham’s Law of Beeminder Deadlines, we’d like to simply kill deadline snoozing. Let us save you from yourselves — backing yourselves into corners where all your deadlines end up at 6am. Paternalism! We see this as an instance of a more general rule of thumb that we’ve called “the #1 rule of Beeminder”: things that make staying on the good side of your bright red line easier make reaching your underlying goal harder.

So that’s what’s currently deployed, as of today. If a goal is in the red, the deadline is just uneditable.

And since this is a violation of the Pareto Dominance Principle — meaning there exist users for whom this may make Beeminder slightly worse — we’re following our self-imposed rule that we have to write a blog post justifying ourselves. So, um, are you convinced?

“Noooooo, I am unmoved, you can take deadline snoozing from my cold, dead hands”

Geez, ok, hypothetical user — if you exist, which we’re not totally sure of. We have ideas for potentially getting the best of all worlds if there’s demand for it. (If this is you, please jump into the discussion in the forum.)

In fact, for a few days until today we tried out an honor system version if you tried to deadline-snooze:

Warning! You’re about to make your deadline later on a beemergency day. This can dampen Beeminder’s effectiveness. Do you promise that either (a) you really endorse this later deadline as a permanent change or (b) you have a good reason for changing it temporarily and have set yourself a calendar reminder to put this deadline back?

(If you just really need a break today, we humbly suggest treating yourself to the derailment)

And then you could click Cancel or “I Promise”.

Early feedback was that it was just too easy to click “I Promise” on autopilot. So we started layering on the duct tape. We floated the idea of a popup like the Uncle button has, where you’d have to type out a phrase to prove you understand the corner you may be backing yourself into.

Or we could make you prove you really mean it by charging a fee to snooze your deadline, if that wouldn’t seem too money-grubbing.

The real best of all worlds

But speaking of money-grubbing, the thing we’d most like to convince you of is that, as we’ve been saying for a while, Derailing It Is Nailing It. (See also the whole “derailing is good-actually” series in the sidebar of Maximal Motivation At Minimal Cost.)

Consider what it means to be willing to pay the tax of snoozing your deadline. Today you’re busy or stressed and it’s hard to meet Beeminder’s demands. Snoozing it has a short-term payoff. But, as we argued above, it’s hard to unsnooze a snoozed deadline. And you presumably chose that deadline for a reason. So the tax you’re paying is mustering the discipline to unsnooze the deadline in the future or else have a permanently less effective Beeminder.

The point is, snoozing a Beeminder deadline is paying a real, if non-monetary, tax. We humbly suggest that you could pay the pledge as that tax. In other words, accept the derailment and enjoy the reprieve on today’s deadline, with no further tax imposed on your future self.

We know it’s a little suspect coming from us, but we’re sincere in our belief that it’s the right attitude for optimal beeminding. The “must do whatever it takes to not derail” attitude is not necessarily all bad but it should have its limits. Deadline snoozing should mostly be viewed as outside those limits since, in practice, it seems to amount to digging oneself in a hole.

Again, if you have strong opinions, especially if you’re sad to be losing the ability to change a goal’s deadline when it’s in the red, do head to the forum thread and chime in.

Footnotes

[1] Cheap talk is the opposite of a costly signal. Also, “cheap talk” might be another case of the holy grail of jargon: a technical concept that’s fully (or close enough to fully) captured in a sufficiently short plain English phrase. See Against Pseudovernacular Jargon where we argue, among other things, that Beeminder’s “bright red line” shares this honor.

Neology

dreev — Tue, 17 Feb 2026 00:00:00 GMT

Previously: Call Them “Quals” and Against Pseudovernacular Jargon.

One time I went to a doctor’s appointment with our son for some knee pain he was having. The doctor asked where the pain was, if it was “below the kneecap”. My son and I both tried to clarify the question: “do you mean below as in under or… um, beneath, or… no, none of these words actually clarify” and finally I was like, “can you just speak Latin??”. (It turns out “subpatellar” means below the kneecap as in further into the body, as opposed to “inferior to the kneecap” / “infrapatellar” meaning closer to the foot.) Doctors may sometimes do this gratuitously but on the whole, Latin makes for surprisingly good jargon in medicine.

I’m pretty enamored with Latin myself but mostly resist subjecting Beeminder users to it. (Workerbees are another story.) I think only one bit of Greek has slipped through, with the akrasia horizon.

I know how pretentious these terms can sound. As Richard Dawkins once put it after using the zoology term Bauplan in one of his books:

Bauplan is just the German word for blueprint. Typically one switches languages to indicate profundity.

As I argued in my screed against pseudovernacular jargon, this kind of thing isn’t (just) about indicating profundity but indicating that it’s a technical term.

Speaking of German jargon, do you know what Freud’s terms for the ego, the id, and the superego are in the original German? “Ich”, “Es”, and “Über-ich” — literally just “I”, “it” and “over-I”. Which is also exactly what “ego”, “id”, and “superego” mean in Latin. I learned this from a bitter Twitter thread, castigating Freud’s English translator for deciding that “such an important concept needed to be made more obscure and technical sounding”. The translator’s choice seems to be widely reviled, but I’m a fan. Switching to Latin was an elegant way to avoid a particularly egregious case of (let me link you to it one more time) pseudovernacular jargon. Even more egregious in English where the word “I” is a single character and it’s hard to even tell when you’re italicizing it. Not to mention zero searchability.

If you don’t want to totally switch languages, may I suggest a foreign prefix? Consider “epicenter”. “Epi” is Greek for “on” so it just means “on the center”. Is that a pointlessly jargony version of “center”? No, when talking about earthquakes you don’t want to always have to disambiguate uses of “center” that refer specifically to being directly above the point at which the strain energy in the rock is first released. Similarly, “hypertext” elegantly jargonifies a certain kind of text. Same for “isoline” or “exoplanet”.

But switching languages isn’t the only solution to the jargoneering [1] problem. There’re always portmanteaus. Like “qubit” for “quantum bit”. (And “bit” itself is a portmanteau of “binary digit” — a nested portmanteau! [2]) Or something taken from literature, like “quark”, or astronomy’s “Goldilocks zone”.

The terminological holy grail is a well-understood word that can be given a technical definition without creating ambiguity. My favorite might be the term “overfitting” in machine learning. It feels similar to Beeminder’s “bright red line” — a technical concept that’s fully captured in a sufficiently short plain English word or phrase. [3] But these are rare. Usually you need to make tradeoffs.

Many years ago I wrote a popular post on how to make such tradeoffs for the case of naming startups and other projects (you can see how the name “Beeminder” fares, if you’re curious). So I’ll conclude by adapting that to the case of coinages in general. Here, I claim, are the core neological desiderata:

Evocativity — conveys as much of the technical concept as possible
Univocity — unambiguous (in particular, not pseudovernacular)
Brevity — shorter = better
Greppability — not a substring of common words
Mellifluidity — alliterative, rhymey, or otherwise fun to say

It’s rare to be able to max out all five but you can aim for that and trade the desiderata off against each other. For example:

“Akrasia” nails univocity, greppability, and brevity, sacrificing evocativity unless you know Greek
“Bright red line” maxes out evocativity, is plenty high on univocity and greppability, but sacrifices some brevity
“Onto” (the math term from the previous post on pseudovernacular jargon) fails so hard on greppability and univocity that its decent evocativity and brevity can’t save it
“Pixel” (picture element) comes pretty close to “qubit” for maxing out all five
“Phishing” is a clever misspelling that yields univocity and greppability without too much loss of evocativity
“Bug” also scores quite high across the board, though perhaps the evocativity is a little tenuous
“Quals” I’ve made the case for already
“Commitment dial” is another case of sacrificing some brevity for some evocativity.

Recall Scott Alexander’s “concept handle” concept handle. Packing up a suitcase full of knowledge or insight and being able to invoke it with a single word or phrase is powerful. It’s why jargon is good, on net. The above desiderata make a concept handle easier to remember, easier to find, and easier / more fun / less confusing to actually use.

Footnotes

[1] Jargonautics? Jargonology? Jargonatomy? Just kidding. As fun as it is to make these up, the word Neology (literally: study of neologisms) is actually perfectly adequate. Funny story: my old blog post on how to name startups and projects is titled “Nominology” and it was only after publishing it that I learned (HT Rob Felty) I’d reinvented the word onomastics.

[2] The original/alternate name of Curlminder, Curlex, has portmanteaus/acronyms nested FOUR levels deep:

Curlex
├─ cURL
│  ├─ command-line
│  └─ URL fetching
│     └─ uniform resource locator
└─ regex
   └─ regular expressions

As far as I know, the only way to top this (HT Brent Yorgey) is with infinitely recursive acronyms, like GNU (GNU’s Not Unix) or PHP (PHP: Hypertext Processor).

[3] Benjamin Fox (AKA zzq) rightly points out that this won’t be quiiiiite right until we eventually make the switch to the Bright Red Staircase. In the status quo, the bright red line isn’t exactly a bright red line, in that you can technically/literally cross it as long as you end the day on the right side of it. I think of “you can’t cross red line” as spiritually true even today, but I agree that it’s bothersome that it’s not fully literally always quite true. It’s true if you think of the red line Beeminder draws as a crude approximation of the true underlying red line with stair steps at each day boundary.

Feature Announcement: Dashboard Hotkeys

bsoule — Tue, 03 Feb 2026 00:00:00 GMT

I’ve been telling people in the forum about my work/life dashboard. I keep my Beeminder dashboard open in a dedicated browser throughout the day, and use it like a to-do list. At the start of the day I uncollapse all the goals I intend to work on that day. That will be all of the red goals, and often many of the orange ones too, though not necessarily all of them. Occasionally there are some blue or green goals in the list as well for whatever rare instances of ambition or pre-planning may arise. Then after I finish doing the things and enter the data, I can collapse the goal to make it smaller, and re-sort by deadline, to keep the done things shuffling down and the urgent things bubbling up.

Only problem is, all this collapsing and uncollapsing and data entry etc involves a lot of clicking around, and I’m vaguely anti-mouse. [1] I’ve used Vim for almost the entirety of my coding career, because I like the dichotomy of insert mode vs command mode. And as a Vim fan, I like any other interface that uses h-j-k-l for navigation (in place of arrow keys), like hitting j and k to scooch up and down past emails I don’t want to answer in Gmail, or bugs I don’t want to fix in our GitHub repos.

So after writing that forum post the other day, detailing all the clicking and scrolling and blah blah blah, it got me thinking about keyboard shortcuts again. As you do. I do? And so today, just to please myself, I implemented them. It turns out it was super easy, not just because robot minions, but because there were no UI tradeoffs. If you’re not into keyboard shortcuts, you never need know this exists.

As of a couple hours ago, you can type “?” to bring up a modal with this cheatsheet:

In text summary (because I can’t stand to give an image of text as the sole description of it): use the ↓/↑ keys, or j/k to enter keyboard mode, and move up and down the list. The Enter key or x will toggle the expanded-ness of the current goal row. e to add new data or refetch from the autodata source, if it’s an autodata goal. r refetches from Beeminder’s servers. g goes to the goal page. s toggles super-collapse. Esc or clicking anywhere exits keyboard mode.

Refetch

The first thing I want to highlight here is being able to refetch the latest data from the Beeminder server by selecting the goal and typing “r”. (Mouse people can also do this by double-clicking a goal’s hexy chevron, i.e., expanding and collapsing in rapid succession.) I have a lot of goals and some of them get data automatically from autodata sources, some of them I tend to update when I’m at my computer (often work-related ones), and some of them I tend to update when I’m away from the keyboard — like my decluttering goal, or my flossing goal. But after I put a few things away and floss my teeth, I’m usually back at my computer doing more work and checking on my Beeminder dashboard. So it’s nice to refresh just the one goal that I know I already updated on my phone while I was AFK, rather than refreshing the entire page and reloading the whole dashboard.

Super-collapse

Another thing in my workflow, which I didn’t mention above, is that I’ve been using a browser extension, BeeBrowse written by Benjamin Fox (aka zzq) for more than a year now, that allows you to super-collapse a goal row in the dashboard. So I had to implement that in Beeminder while I was at it with the keyboard shortcuts. This is honestly kind of the secret sauce in my dashboard-as-to-do-list. At the beginning of the day I actually super-collapse anything I’m not going to work on today and as I finish off goals throughout the day I super-collapse them and they’re basically out-of-mind. It makes my workload visibly shrink as the day goes by and that’s as pleasing as crossing out an item in a to-do list. Your mileage may vary.

Anything else?

The dashboard header is also a navigable row, and has its own section in the help sheet for the hotkeys. Hitting a is like clicking the header row hexy chevron — it toggles expansion/collapse of all of the goals at once. And you can use keys 1-4 to select the different sort orders, so if you need to put them in alpha order to find that one goal or something, you can nav up to select the header row and then type 1. Or much more common for me: type 2 to re-sort by deadline order. As in, I’ve just dispatched several goals and now I want to re-sort them into proper order and get them out of the way of the other goals that are still red for the day.

That’s all for now. Power users, go forth, tell us what’s still missing. We haven’t quite sherlocked Benjamin’s brilliant BeeBrowse browser extension but possibly we should?

Footnotes

[1] I swear I’m not being a hipster about it, it’s more like my fingers are suffering agoraphobia and don’t want to leave the home row. So I use Spotlight [2] to launch every application, and command-tab to switch applications. But I don’t use a chording keyboard to build elaborate symphonies of custom hotkeys.

[2] *tilts head and puts finger to earpiece* I’m being told that only Philistines use Spotlight and that I need to get on Raycast immediately. It even has a Beeminder extension, thanks to the amazing Vivian Guillen.

Beeminder ♥ Steam: Announcing the Steam Autodata Integration

bsoule — Tue, 20 Jan 2026 00:00:00 GMT

We’re excited to officially announce our newest autodata integration: Steam!

Yes, the gaming platform. Do you buy too many games and then never get around to playing them? Do you spend too much time on that one game and have regrets? We have a solution for you. Spoiler alert: it’s Beeminder. It’s always Beeminder.

If you’re new to Beeminder, we help you do the things you want to do by bringing long-term consequences right up and into your personal space. We do that by charging you money today if you’re straying from the track to reach that goal by some distant tomorrow.

So what does goal setting have to do with Steam?

Well, what if you have a backlog of 14 games you bought last year that you haven’t touched at all yet? You can set up a Beeminder goal to spend more time playing games on your Steam account. Or if those unplayed games are sitting there staring at you accusatorily while you keep playing Some Other Game obsessively, you can also set up a Beeminder goal to limit your time with that SOGgy bottom.

Then if your game time playing SOG racks up too far and you go over the bright red line, you get charged money. Contrariwise if you have a “spend more time playing”-type goal for the backlogged games, you get credit for playing your games. If you don’t play enough, you’ll also get charged. So if you’re the type of person who manages to feel guilty about spending time doing things you enjoy, or even just if you sometimes forget because you were too busy flicking through you-tok-gram, now you’ve set up an ironclad excuse for doing what you wanted to do anyway. “Sorry, I have to go play video games for 5 minutes or I’m going to get charged $10.” How’s that for self-care?

Detail-ey-doodles

To set up a goal you’ll look for the Steam logo in the new goal page and enter your Steam Id:

We check that we can actually see your profile — your profile has to be public for us to read your info. If the settings are copacetic then we fetch your owned games and show you the next goal creation screen. There are three main things to fill out here.

Select a game to beemind (or All Games)
Choose between do-more and do-less. If this choice is not self-explanatory, you’d better go back to square one.
Pick the daily time you’re commiting to (for now — you can always change it for next week if the rate you pick here is not quite right)

Then all you’ve gotta do is play your games. Beeminder automatically fetches the time you’re spending and logs it on your goals. While you are playing your game, Steam only updates the information available to Beeminder in half-hour increments. It updates immediately once you exit your game.

So if you’ve set up a Do More goal, and you are down to the wire on getting your last few minutes in before the goal deadline, you may need to exit the game for the values to update. And same for a Do Less goal. If you have less than 30 minutes of buffer on the goal, you may need to exit the game to get an up-to-the-minute count of your time in Beeminder. But either way, Beeminder won’t necessarily be accurate to the minute if you’re actively playing your game.

If you’re sold, head to beeminder.com/new, pick the Steam icon from the list of integrations, and follow the prompts to connect Beeminder to your Steam account. Or, here, have a button:

Moderate Steam Ahead

(See also the full documenation of the Steam integration in our help docs.)

Against Pseudovernacular Jargon

dreev — Tue, 06 Jan 2026 00:00:00 GMT

Beeminder is kind of notorious for its jargon. We’ve got beemergencies, an akrasia horizon, maxflux, and, most recently, tare tags. Some of these seem to us perfectly self-explanatory — derail, pledge, ratchet, commitment dial, post-derail respite — but of course they’re not. From a newbee perspective, the site is full of chicken clucking nonsense. [1] We have a whole Beeminder glossary, for the love of Beejeezus.

The downsides of that are obvious enough. Jargon can be pretentious and obfuscating. The upsides are pretty obvious too. Jargon is efficient and precise. At its best, a piece of jargon puts a concept handle on a whole suitcase-ful of hard-won knowledge and insights.

The Worst of All Worlds

If you can say something in fewer words with more precision using plain English, the Loving Beejeezus commands you to do so. That’s obviously the best of all worlds. We might’ve achieved something close to that when we replaced the cute but opaque “yellow brick road” with “bright red line”. (Apologies to those still wistful about the yellow brick road. I guess we can’t call that one the best of all worlds.)

What I claim is the worst of all worlds is pseudovernacular jargon: using plain English as jargon, rather than instead of jargon. There’s a huge irony here. Plain English can be too understandable. It’s like the quote tenuously attributed to George Bernard Shaw: “The single biggest problem in communication is the illusion that it has taken place.”

If you say, for example, as we used to do, “max safety buffer” then users, understanding each of those words, will jump to the conclusion that they understand the phrase. But “autoratchet” (as we now say instead) means something very specific in Beeminderland and it’s less confusing for users to hear “autoratchet” and know that they don’t know what it means than to hear “max safety buffer” and think they know but be wrong. As Mark Twain supposedly said, it ain’t what you don’t know that gets you into trouble. It’s what you know that ain’t so.

Mathematicians are the worst about this: real, complex, imaginary, rational, natural, normal, field, ring, group, smooth, set, function, … They even do things like make technical definitions for “almost everywhere” and “almost surely”. Some of those work surprisingly well, some work once you’re sufficiently inculcated, and others are kind of a disaster.

If you’re a mathematician and you’ve invented a nifty new complete ordered set (don’t get me started on “complete” and “set” — but “ordered” I like) with binary operators that follow the distributive law, as a way to axiomatize the rational (🤨) and real (🤦) numbers, then, before deciding to call that set-plus-operators thing a “field”, at least consider whether it could cause confusion with the thing gravity and magnets do in physics. Not to mention the dozen other definitions of “field” [2].

I don’t deny that natural language is — as the “field” example illustrates — impressively robust to such ambiguity, but first of all, there are limits. I think the worst example I’ve encountered is the technical term “common knowledge”. [3] And the illusion of transparency means it’s dangerously easy to fail to notice these ambiguities.

But my real gripe is how people imagine they’re being less jargon-y and more layperson-friendly by sticking to simple English. That only works if you’re actually translating the technical stuff to simple English. (Which of course is tedious and inefficient among experts — the whole reason we have jargon.) If you’re just co-opting simple English words as your jargon, that’s what I’m calling the worst of all worlds.

If you overhear a pair of doctors talking about gastric emesis, it might be super pretentious that they’re not just saying “vomiting”. They’ve essentially encrypted their communication. But at least it’s obvious it’s encrypted. What’s worse is steganographic encryption — when you encrypt communication and embed it in other communication to conceal the very existence of the encrypted communication. That’s what mathematicians talking about how “in the field of the reals, almost all numbers are irrational” are like [4]. I mean, I exaggerate. It doesn’t take long to realize that two chatting mathematicians are on a different planet from you, but terms like “real number”, “normal distribution”, and “almost surely” [5], if used in an even slightly normie-adjacent context, are ambiguity atom bombs.

Check out the example of Grant Sanderson (of 3Blue1Brown fame) talking to Neil deGrasse Tyson about how in statistics “people will often assume something’s normal when it’s not,” and Neil has to interrupt to clarify for listeners that Grant means a normal distribution, making a bell shape with his hands. Or if a math newbie hears you talking about “real numbers” and presumes you just mean “actual numbers” as opposed to hypothetical ones. I’ve had this happen myself, not for lack of knowing about the reals, but by accidentally saying “real number” to mean “not a variable”, before noticing the confusion I’d unleashed.

It would, ironically, be so much clearer if the math term for the reals were some fancy Latin thing like “continuata” or “fluxorum”. You see that, immediately know you don’t know what it means, look it up, et voilà; now you know. With “real” you have to see it enough times to catch on that it’s being used in a technical sense and then construct a disambiguating search query like “real number math”. (Of course LLMs have made this easier.)

Again, I get that when fields (not that kind of “field”) do this it does mostly work and you can almost (not that kind of “almost”) always distinguish, say, “real” and “real” in context. But there really are so many examples of this causing problems and I want to hammer on them because so many people I argue about this with are determined to defend pseudovernacular jargon, as I’m calling it.

But I don’t want to pick on mathematicians too much. Using common words as technical terms is better than, as John D Cook points out, how business does the complete opposite and coins technical terms to refer to common ideas. I’m not sure how fair that is but it feels true. I think fear of gratuitous jargon is the biggest reason people do things like use the word “group” to refer to one of the most deep and powerful concepts in math. John D Cook cites the term “group” as the candidate technical term likely to be most confusing for his readers. If you don’t know better it sounds like you mean “collection” which, Cook says, “is just close enough to correct to be misleading.” [6] But at least it’s a noun (and a verb, I guess). I think the worst of all (close behind “almost”) might be “onto” to refer to a function that covers its whole range. [7]

Suitcases of knowledge

Turning back to software engineering, and Beeminder specifically, the pseudovernacular “tests” bothered me enough that we now call them quals. That was the topic of the previous Beeminder blog post:

Your software’s meta-software for quality assurance and regression-prevention infrastructure is not “just some tests” […] More pragmatically, the word “test” is just too common and overloaded.

There are many other examples of Beeminder jargon that’s a result of us attempting to thread this needle. Before we shipped the tare tags feature we debated whether the magic string should be “#TARE” or “#RESET”. Ultimately I vetoed “#RESET” because of how overloaded that word is — did the graph reset somehow, like derailing? a fresh start? resetting the commitment in some way? So many conclusions a user might jump to, thinking they understand the word “reset” perfectly well. Which they do, which is the problem.

We’ve given ourselves a lot of experience trying to find the sweet spot between all these competing constraints — precision, concision, evocativity, approachability, greppability, … Hopefully I’ve convinced you that you’ve got to be careful around plain English, and you’ll want to come back around for part 2 where I’ll give my advice on what good alternatives to pseudovernacular jargon look like. It doesn’t (just) mean translating to Latin.

Footnotes

[1] Fun fact: the word “jargon” comes to us from Old English via French “jargoun”, or “gargoun”. It’s an onomatopoeic word to describe the chattering of birds, thence applied to incomprehensible language. Also related: gargling!

[2] Field a question, field of view, battlefield, field of biology, in the field as opposed to the lab/office/classroom, field of candidates, field in a database, field a team, …

[3] “Common knowledge”, ironically, is such a thorn in my side in trying to communicate unambiguously. Unless you have common knowledge [technical sense] that everyone in the conversation is a game theorist, you’re constantly having to disambiguate it. Because it’s common knowledge [colloquial sense] that “common knowledge” is merely something commonly known.

[4] The math fact that “almost no reals are rational” is super cool. It means that, even though there are an infinite number of rational numbers (rational is “ratio”-nal — meaning fractions; this term I’m kind of a fan of) they’re embedded in a literally bigger infinity of irrational numbers (like pi and the square root of two, numbers that can’t be written as the ratio of integers) such that the percentage of real numbers that are rational is exactly zero! But, again, there are still lots of rationals, hence “almost” none are rational. It’s 0% of them and yet not none of them. Infinity makes things weird.

[5] What if instead of “almost certainly” and “almost always” we used “pen certum” and “pen universum” or whatever the proper Latin would be? It needs some more workshopping but the point is that terms like “almost always” are especially hostile to newbies who can be deceived into thinking they’ve understood something when they haven’t. Would it have occurred to you to seek out the “almost surely” Wikipedia page if I hadn’t already linked to it? It almost surely would’ve if we used something in Greek or Latin. Also you’d be able to grep for it in a paper or textbook.

If you’re still skeptical that this is actually a problem in practice, have a Hacker News thread full of people confused by “almost always” because of mathematicians ruining it.

Or consider an example from @Sean in the Beeminder Discord who was very confused about large deviations theory specifically because he didn’t know that he didn’t know what “large deviation” meant.

[6] Here’s a silly idea to get the best of both worlds: Take the ostensibly normie-friendly naming to an even further extreme and use cute phonetic spellings. Reel numbers, groop theory, etc. Now readers can tell again that you don’t mean the words it sounds like you’re saying. Which is good, because you don’t.

[7] Here are my arguments that the jargon-y sounding terms “injection” and “surjection” are superior terms to the pseudovernacular “one-to-one” and “onto”:

You can grep (aka control-f) for “surjection” but you can’t grep for “onto”.
When a newbie sees one of these -jection words they know that they don’t know what it means and can look it up. That’s less confusing than “since f is onto, blah blah blah” which looks like a typo or the author had some kind of stroke midsentence.
After a small upfront cost, the Latin-based terms are more evocative and memorable. For one, they’re themed, by all ending in -jection. (There’s also “bijection” which means both an injection and a surjection.)
“Injection” you can visualize as the elements of X mapping to a subset of Y — the function injects X into Y. “One-to-one” always makes me think it means a bijection — that everything in X has a thing it corresponds to in Y and vice versa. That’s the usual nontechnical meaning of “one-to-one”.
(Which is my more general point: turning everyday words into technical terms is a recipe for confusion.)
“Surjection” is easy to remember once you’re used to it. The prefix sur- means “over/above/onto” — like surname is the name everyone in the family has; surface is the outer face; surmount means overcome; survey means look over. So a surjection maps over the whole codomain, covering all of it.
We definitely need a word for “bijection” and the plain English equivalents of these terms have got nothing here other than “one-to-one and onto”.

Call Them "Quals"

dreev — Tue, 16 Dec 2025 00:00:00 GMT

Attention conservation notice: This is of no actual relevance to Beeminder users. Except the ones who are software developers, which in fact seems to be most of you. (Also AI seems to be drastically lowering the barrier to entry for creating software, so maybe this is about to be relevant for everyone.) Or maybe you just like these random peeks behind the curtain.

Let me get to the point. I dislike the term “tests” (as in unit tests and test-driven development — code that verifies the correctness of other code). What’s my beef with this perfectly innocuous and perfectly descriptive word? First, it has the wrong connotations. You say something is “just a test” to mean it’s a one-off trial. Your software’s meta-sofware for quality assurance and regression-prevention infrastructure is not “just some tests” in that sense.

More pragmatically, the word “test” is just too common and overloaded. You can’t search GitHub for Issues that mention “tests”. The results are overwhelmed by mentions of tests-as-in-experiments, offers to test something out, the Javascript regex checking function, pen-testing, developers with chips on their shoulders saying “don’t test me, motherforker”, … Am I exaggerating? On that last one, yes, but I did test this in Beeminder’s bug database, searching the word “test”, and got back 275 gissues (as we call them, for GitHub Issues).

It’s similar for grepping the codebase for the string “test”: 316 lines. That’s more than twice the number of lines mentioning the thing we actually care about.

How do I know? Because we call them quals. It’s an infinitely better term! “Qual” already means “test” in some contexts, as an abbreviation for qualifier. Like how you have to pass your quals before you’re a Ph.D. candidate. It also evokes quality assurance, which makes sense for software.

Then there’s verbability. With “test” you’ve got “I tested that” but it’s impossibly ambiguous. Did you just try it or did you actually qualsify it? [1]

This is part of my broader jargon rant for a future blog post, about how confusing it can be when technical terms also have everyday meanings. (UPDATE: The sequel has arrived! Against Pseudovernacular Jargon.)

What about “Specs”?

We had a whole debate about this in the forum. I think it’s a fine choice. I’ve come to like “quals” better, mainly because specs are both more specific and overlap with another concept I’m enamored with:

“Spec” definition 1: The document that states the goals or the problem being solved and how all the code will work from a user’s perspective.
“Spec” definition 2: Code that verifies that functions given known input produce expected output, or that some sequence of UI interactions yields the expected program behavior.

But it’s not at all crazy to overload the term to just mean both of those. They’re pretty related. One is a document in English specifying how future code will function and the other is code that verifies the behavior of existing code. Robert Perce argues that thinking of those two senses of “spec” as the same thing leads to design and usage insights that improve both kinds of specs.

Uphill battles

“Spec” in this sense even has some traction in the wider software world and so might’ve been less of an uphill battle than “qual”. We’ve gotten used to saying “quals” now and I like it and hope it catches on. But realistically, it’s hard to argue it was worth the effort, especially if it doesn’t catch on anywhere else. Mostly I was just annoyed by ambiguities we’d run into talking about “tests” and was nerd-sniped by the onomastic challenge of finding something better.

Footnotes

[1] In some engineering contexts, “qualify” as a transitive verb already means running a set of checks to demonstrate that something meets its requirements. So, yes, you could be less weird and verbify “qual” as “qualify”, but we are not in the business of being less weird. (Also I think this existing sense of “qualify” is another point in favor of the term “quals” to refer to a software test suite.)

Writing About Writing: Highlights from Inkhaven

dreev — Tue, 02 Dec 2025 00:00:00 GMT

This post is adapted from an earlier and less Beeminder-specific version on LessWrong.

I returned from Inkhaven (see my previous post about heading there) a week and a half ago. It was intense and wonderful and I highly recommend it to fans of the Beeminder blog, if it happens next year, which it seems like it will. I should clarify that I wasn’t officially a participant myself. The organizers recruited me as a Contributing Writer, to share my decades of blogging wisdom. And to help with writing-related commitment devices, of course. It was quite an honor, given the list of other contributing writers: Scott Alexander, Scott Aaronson, Dynomight, Gwern Branwen, Andy Matuschak, and many others. The participants were no slouches either and included many friends and people I’m a huge fan of (such as Rob Miles) and others who I’ve become friends with and/or become a fan of.

With 40 posts published per day by participants for 30 straight days (1200 total! not counting those by organizers and contributing writers) it feels impossible to highlight samples of them. Fortunately that’s been done for me: the Inkhaven spotlight. And just to semi-randomly pick a single post to highlight, for making me laugh out loud, I’ll link to one by Rob Miles. And to non-randomly pick one because it’s somewhat about Beeminder, I’ll link to Lucie Philippon’s post about Cyborgs vs Mentats. It describes two schools of thought on incentive alignment. There are also myriad poignant, insightful, informative, and otherwise delightful posts. And, sure, plenty that don’t quite work yet. But that’s the point: force yourself to keep publishing, ready or not, and trust that quality will follow.

Which brings me to the two Inkhaven lessons for me personally as a writer.

First I need to follow the advice (#5 in my collection of Inkhaven tips) to dedicate blocks of time to dumping words onto the page. Editing is separate. See the version of this post on LessWrong for an embarrassing illustration, where I started with “here I am on the plane” on my way home from Inkhaven. It’s a terrible opening but the alternative was sitting there agonizing about a better opening, getting distracted, and having nothing written.

The second lesson for me in particular is that sometimes it’s ok to hit publish before something is perfect. In addition to helping the participants, and some amount of work on Beeminder, I committed to the same thing the participants did while I was there: publishing a 500-word blog post every day by midnight. It was hard! And sometimes — as above — something mildly embarrassing wound up in the published post because I ran out of time for the editing. But I also managed to actually publish fourteen posts in fourteen days. I link to the more Beeminder relevant ones below.

Write, publish, repeat.

When I got home I agonized about committing to keep churning out a post every day for the rest of the month. Obviously I needed to have created a Beeminder goal if I were serious about that. So far I’ve decided that my current blogging commitment is enough — biweekly Beeminder posts, plus my new AGI Friday Substack. I do have a pretty much unlimited number of ideas to write about, even sticking to the theme of writing about writing. Here are half a dozen of them:

Complaining about a list of words I’ve been curating for which Google’s built-in dictionary definitions are garbage.
What a work of art the 1913 edition of Webster’s dictionary still is and how to configure a Mac laptop so it pops up those definitions when you hard-press on a word with the touchpad.
Why Overleaf is the bees’ knees for technical writing or collaborative writing (and definitely what you want for technical collaborative writing).
More of my favorite word games (does that count as writing about writing? maybe I can find a way to make it count!).
My ever-growing pile of notes about and examples of redefining everyday words as technical jargon (“common knowledge”, “real number”, “normal distribution”) and how bad this is.
Tips for dealing with trolls (beyond not feeding them, which is rules 1 through 17).

The problem is how daunting it feels to do justice to some of those. But that’s where the writing tip to First Just Write comes in.

(Fun fact: I spent some hours today thinking today’s Beeminder blog post would be the one about my thoughts on jargon before I threw up my hands and realized my Inkhaven retrospective deserved a translation to the Beeminder blog.)

So let me end this with a recap of my at-least-vaguely-Beeminder-relevant posts from my Inkhaven stay:

Against Powerful Text Editors (mindless, repetitive edits waste less time than it seems and avoiding them is more costly than it seems — this is sort of a commitment device for not getting distracted by your own tools)
See Your Word Count While You Write (I made a tool, Tallyglot, to see your word count in various online editors)
Why to Commit to a Writing and Publishing Schedule (it matters for you and for your readers; also covers “how”)
Strategically Procrastinate as an Anti-Rabbit-Hole Strategy (aka Just-in-timeboxing)
The Eightfold Path To Enlightened Disagreement (characterize, crux, ITT, steelman, scout-mindset, etc)
Smarmbots, Secret Cyborgs, and Evolving Writing Norms (new rule: no plagiarizing LLMs)
Mnemonic Exposition (how to name and gender hypothetical characters)
Eat The Richtext (another tool I made for preserving formatting when pasting text)
The Principle of Delayed Commitment (more pro-procrastination propaganda — this one’s already on the Beeminder blog)
Ten Wrong and Dumb Grammar Rules (infinitive splitting, less-vs-fewer, syntactic vs elocutionary punctuation, etc)
Writing Tips from Inkhaven (listicles, curse of knowledge, Hemingway Mode, the out-loud-to-your-friend constraint, etc — two Beeminder users got $15 honey money bounties for two of these tips)

The Principle of Delayed Commitment

dreev — Tue, 18 Nov 2025 00:00:00 GMT

The irony is not lost on us that this post has been languishing as a draft + pile of notes for so long that it has a title image from the era when a human illustrated Beeminder’s blog.

The Principle of Delayed Commitment says to consider whether a decision or task will be worse or harder if delayed. Often it won’t be, so delaying is a no-brainer. Procrastination isn’t inherently bad. It’s bad when it causes actual badness. Consequentialism! People commonly overgeneralize the virtue of prudence/preparedness to cases where it’s blatantly irrational.

Yes, we know, this is Decision Theory 101 and intuitively obvious for some people. Optionality has value, the end. But writing it out for a lay audience is the best way we know of to establish it as a concept handle, and we’ve found it to be a useful one. In particular, principlifying it helps catch cases you might otherwise miss. “By the Principle of Delayed Commitment, let’s not bother to do XYZ yet.” Saying it that way clarifies that you’re not (just) procrastinating. That we might do XYZ differently (or not at all) depending how other things play out.

“People commonly overgeneralize the virtue of prudence and preparedness to cases where it’s blatantly irrational”

This can absolutely be taken too far. Some of us (especially me, dreev) may use it to rationalize procrastination beyond what’s actually rational. (“What if a meteor destroys the city before April 15 and I did my taxes early for nothing?”) As Scott Alexander astutely asks, “Should You Reverse Any Advice You Hear?”. Some people need to be more prudent and pre-planny and others do that too much. But there’s a theoretical sense — and for plenty of people a practical sense — in which it’s true and useful.

Toilet seat toggling

Here’s a simple example to start with: Don’t toggle the state of the toilet seat — up vs down — after you use it. You don’t know who will be next to use the toilet, and therefore don’t know what state they’re gonna want it in, so don’t waste effort lowering it when you’re done. What if you’re the next person to use the bathroom? You’d have lowered it for nothing!

Though huge caveat here: actually toilets are gross and you should put a lid on that germ bowl to separate it from the rest of your bathroom.

But in principle, toggling the seat is wasted effort.

The same applies to other shared toggles as well. Should you switch the TV back to cable input after you finish playing games? Nope. Should you switch the seat position and mirrors back after driving if you share the car with someone who is differently sized than you? Nope.

The kids’ carseats

Real world example from Bee, whose parents drive her niece and nephew around town often enough to have their own child carseats in their car. They leave them installed in the backseat most of the time.

They don’t take the carseats out every time they drop the kids off in case they need to give an adult a ride before they see the grandkids again. And when Bee gets a ride from them to go out antiquing or to a choir concert, and needs to use the back seat, she doesn’t reinstall the carseat when she gets out of the car.

On both ends of the transaction they wait until the next time the backseat needs used, and toggle the state — carseat or no carseat — appropriately. Unless it’s certain who is going to be the next passenger in that back seat, they delay commitment and deal with it in the future.

Bridge crossing

Sometimes when you’re riding your double-decker bike to the neighboring town across the river, you think to yourself, “I need to bike over that bridge. In order to get across the river.” And you may be tempted to get that part of your journey out of the way early.

But we propose that it’s more prudent to cross the bridge when you come to it.

(The related aphorism, about enumeration of pre-hatched chickens, says to not depend on things that haven’t happened yet, as opposed to not doing things it may not make sense to do yet.)

You may be wondering at this point if we actually need the “principle of delayed commitment” concept handle when there’s already the perfectly serviceable “cross that bridge when we come to it”. Well, “need” is a strong word but we use both of them. We’d say the bridge version feels more casual — “let’s not worry about that yet” — while the principle version prompts us to think about what’s decision-theoretically optimal.

Premature optimization

Software devs will be familiar with this. Indexing your database before you actually have any data in it. Setting up geographic redundancy before you even have users outside your timezone. Caching too soon. Adding features or building out too much functionality before you’ve had actual users. See especially the Shirk & Turk Principle.

Pre- or over-planning

As a real-world counterpart to the software version above, it can be tempting, especially if you are an anxious person, to expend a lot of effort planning for events that may never come to pass. Applying the principle of delayed commitment can be useful if overplanning is your tendency.

Don’t borrow chairs from your neighbor for your dinner party until your RSVP count actually exceeds your chair capacity. Don’t buy a full kosher set of dishes and build a second kitchen until the Rabbi agrees to come to dinner. Don’t buy plane tickets to attend your grandmother’s funeral until she’s actually dead.

Some of these are more obvious than others. But, again, some people in some situations are prone to blatantly violate the principle and calling it a principle is sometimes helpful.

Lazy evaluation

Here’s another one from computer science. Suppose I ask you if it’s true that either 248 is an even number or there are infinitely many twin primes. Lazy evaluation means noticing that the or-statement is true as soon as you figure out that 248 is even, so don’t bother solving the twin prime conjecture. That example is contrived and ridiculous but this comes up constantly in programming. Statments like if(x > 0 and long_computation() == x) can be short-circuited and the long_computation() avoided whenever x is not greater than zero.

Delaying those ticket purchases

There are lots of reasons to buy tickets early — for concerts or flights or whatnot. The price might go up, for one thing. And you get more choice in seating or departure time.

But the principle of delayed commitment tells us to trade that off against the advantages to delaying: Something might come up to keep you from going to that wedding. Is there only a 50% chance your cousin will actually go through with it? Are your mother and her brother constantly fighting and your whole family might get uninvited? Are you getting a new boss next month and you’re not sure if you’ll be able to get time off work?

If there’s additional information that might decrease your excitement about attending (maybe the concert set list, or opener), or that might increase your excitement or otherwise change your decisions (you find a friend who wants to go too, but only if you can get seats together), then there’s value in delay.

Ok, the principle of delayed commitment says it can be rational to delay in order to preserve optionality. Ironically, and especially relevant to Beeminder, there’s also a meta-rational reason to delay, in order to remove optionality. I (dreev) blogged about this the other day on LessWrong as part of my stay at Inkhaven: “Strategically Procrastinate as an Anti-Rabbit-Hole Strategy”. It points out that delaying starting a task can serve as a commitment device to cap the amount of time you spend on it. Just-in-timeboxing, we’re tempted to call it.

Final question: Does Beeminder not blatantly violate the principle of delayed commitment, locking you in to a course of action that might turn out to be suboptimal? It sure does! We’ve thought about this forever and our best answer is still Flexible Self-Control. It’s worth “irrationally” pre-committing to thwart your impetuous future self. But retain as much flexibility and optionality as possible. Beeminder does that with an akrasia horizon: You’re only ever on the hook for the upcoming week. So you can change what you’re committed to at any time and that change takes effect with a one-week delay.

Coauthored with Bethany Soule. Thanks to Mary Renaud for helpful discussion. Image credit: Faire Soule-Reeves.

Inkhaven

dreev — Tue, 04 Nov 2025 00:00:00 GMT

Probably some of you will be pretty enamored with the concept of a writing retreat in which you have to publish a 500-word blog post every day by midnight or you get kicked out. Well, the concept is real! The inaugural such thing, dubbed Inkhaven [1], kicked off three days ago in Berkeley with 41 participants. On day 4 we’re down to 40. [UPDATE: Turns out that was incorrect. I’m not sure why it looked like that at the time on the website, but all 41 participants officially made it to the end!] The prediction markets currently expect, as of me writing this, about 34 people to make it till the end on November 30. Here’s a [static] graph:

Or follow along with the firehose of blog posts.

The idea for this thing was born when Scott Alexander made the observation that whenever he sees someone blogging every day, they almost invariably end up successful in some way. Scott called it his best leading indicator of a good blogger.

The Inkhaven organizers are perfectly aware that correlation doesn’t imply causation, but, as the saying goes, sometimes correlation does “waggle its eyebrows suggestively and gesture furtively while mouthing ‘look over there’.” They refer to Inkhaven’s conceit as Goodharting on that correlation and explicitly warn prospective participants that committing to writing every day might merely bring the correlation between daily writers and eventual good bloggers to zero.

Goodharting?

Yes, as in Goodhart’s law, that any metric you try to optimize quickly becomes meaningless because people game the crap out of it. We’ve talked about it a lot on the Beeminder blog over the years. Like in “Ice Cream Truck Loopholes”, where we argue that Goodhart’s law doesn’t tend to sting you too badly when you’re the one making up the metrics. Trying to game them is like pulling yourself up by your own petard? Since you care about the underlying goal, you can just change the metrics if Goodharting is ruining things.

DIY Inkhavens?

I’m proud to report that Beeminder is a minor sponsor of the event. And I’m especially opposite-of-humbled to report that I myself have been recruited as a mentor/”Contributing Writer” for the middle two weeks of Inkhaven. My objective is to help participants set up their own Inkhavens after the retreat is over.

The foundation is, naturally, setting up a goal to graph your wordcount over time, automatically, and commit to some number of average words per day. (Unlike at Inkhaven, with Beeminder you can write more on some days and build up safety buffer. Unless you don’t want that, in which case there’s the autoratchet feature. Beeminder is very flexible.) See our old Newbee Corner blog post, Beemind Your Writing (By Word Count, Automatically), for the basics.

Finally, I should clarify that I’m not technically a participant myself. But I would crush it if I were. Inhumanly astute readers will notice it’s 11:59pm and this blog post (including this sentence, including this parenthetical) is exactly 500 words.

Footnotes

[1] Yes, “Writehaven” would’ve been a better pun on the name of the retreat venue, Lighthaven, but the name was taken by a different tool they built.

The Protein Dial

dreev — Tue, 21 Oct 2025 00:00:00 GMT

Background: Mindful Munching with Metrics and especially Gauges and Dials.

The short version of the background here is that there are a bunch of smart things you can do to manage your weight (more to the point: your size) and you should focus on those things more than the number on the scale. Also don’t get stuck in diet mindset. But also, Beeminder is all about bright lines and obsessing about numbers and we think there’s a way to get the best of both worlds. Mindfulness and healthy habits and moderation and all that as the foundation, along with numbers-based guardrails.

Commonly we focus on scale weight as a proxy metric for a fitness goal (but there are other options). We call such a measure of your progress a gauge. You also need a primary metric under your direct control that affects your gauge. We call this a dial. Net calories is a classic dial. Reduce your net calories, see your scale weight trend vaguely down.

One big problem with net calories as a dial (besides how much some people hate tracking them) is that you can create a vicious cycle. The less you eat, the more your body clings to every calorie you do give it. Maybe you find yourself sleeping more, or feeling generally low-energy so you move less.

A related problem with using scale weight as a gauge is that you might lose weight by losing muscle instead of fat. We strongly recommend doing resistance training [1] while trying to lose bodyfat, to avoid that.

But also: protein!

Getting more protein makes everything easier. It helps ensure you don’t lose muscle, of course. And it fills you up, making it easier to run a calorie deficit or avoid a calorie surplus.

So I thought, what if we ignored calories and focused just on protein? Maybe the right things tend to naturally happen when you do that. Instead of reducing net calories when your gauge is in arrears, just up your protein. Is that not abusable, you ask? Would you just eat even more calories in order to hit the protein minimum? Our solution to that is to make your dial metric be, not the absolute amount of protein you consume, but the fraction of your day’s calories that are from protein. (More on this in the “couldn’t you game this” section below.)

Nitty gritty

Alright, the first thing to decide is the bounds (extrema) of the dial. I’ve picked 25-50%. That is, maximally lax is 25% and hyperstrict is 50%. The latter is what hardcore gym types sometimes recommend for what they call a mini cut. (See the related reading below.)

“When your [weight] is not near the bright red line then you just ignore all of this”

Of course, per usual with the Gauge/Dial system, if your gauge is below Beeminder’s maxflux line (think: not near the bright red line) then you just ignore all of this. So even though the “maximally lax” setting of 25% protein is not exactly trivially easy, you don’t even have that restriction when your gauge is far enough in the green.

What we do recommend as general guideline regardless is to aim for at least twice as many grams of protein as your lean mass in kilograms. Like if you weigh 155 pounds and have 30% bodyfat, that’s 49kg of lean body mass, so your target is >98g of protein. This is hotly debated, maybe somewhat less is fine, but all our research sugggests that at worst excess protein is kind of wasted (or can make it hard to get a calorie surplus if your goal is to gain weight) so might as well err high.

At the hyperstrict extreme of 50% it’s actually hard to eat a balanced diet. There aren’t a ton of foods that have more than half their calories from protein. We’ll see an example with chicken breast (77%) in a moment.

Being bound by the protein dial — when you’re in the red on whatever your gauge metric is — means following one rule:

Say your protein dial is set to D, something between 0.25 and 0.5. And say P is the grams of protein you’ve eaten so far today. Then your total calories for the day, C, must always satisfy C ≤ 4P/D.

That’s the bright-line feedback control system part. And of course you let the spreadsheet worry about the math for you, but for the nerds, here’s where that limit comes from:

Your fraction of calories from protein is 4P/C (each gram of protein has 4 calories) and the dial constraint is that this must be at least D. I.e., 4P/C ≥ D. So solve for C and Bob’s your uncle.

“Your total calories for the day, C, must always satisfy C ≤ 4P/D”

For example, if D=1/3 and you have 100g of plain chicken breast for breakfast, that’s 32g of protein and 166 calories. So your calorie cap is 4×32×3 = 384, of which you’ve had 166. So 218 more non-protein calories until you have to get more protein.

Again, this gets hard as the dial approaches D=0.5. But the idea is that your gauge metric will improve with these high-protein days and, with a bit of mindfulness, you’ll keep your gauge in the green and not need these abnormally high protein days often. Of course it’s still great to follow the general guideline every day, to hit your protein minimum. Just that strictness isn’t strictly required when your dial is all green.

Couldn’t you game this by…

Yes, suppose you’re in the red (so the dial rule is in effect) but you get your heart set on a 730-calorie Crumbl cookie, which, sadly, is only 2.7% protein. No problem, even at the hyperstrict D=0.5, if you gulp down (math math math) 896 calories of pure protein powder first, you’re all clear for the Crumbl cookie!

But any system can be gamed and thwarted if you try hard enough. Hopefully that’s an ice cream truck loophole. Also, would you even still want the Crumbl cookie after 896 calories of protein powder?

The Snackwell effect and the so-called Big Fat Lie

Speaking of gaming the crap out of things… Wavy flashback lines to the 1990s, when conventional wisdom was that dietary fat was public health villain number one. Eating fat would clog your arteries and give you a heart attack. But if you take, say, yogurt and add a bunch of sugar then the percentage of calories from fat goes down and you can call it LOW FAT and that sounds healthier. Oy.

One company (or brand of Nabisco I guess) that cynically exploited this confusion was SnackWell’s, which made sugary treats marketed as health food because they were FAT FREE.

The Snackwell effect refers to people eating more of something because it has less of something they think is bad.

I’m particularly amused by the irony here. I grew up not questioning what Gary Taubes dubbed the Big Fat Lie. [2] Then I spent a couple decades shaking my head at how dumb I was to think skim milk was healthier than whole milk. And now here I am, treating skim milk as almost twice as good as whole based on the percentage of calories from protein.

Not that “fat is the devil” has been vindicated. Just that fat is very calorie dense and crowds out protein.

Trying this in real life

I’ve been logging what I eat (and burn) in Google Sheets like so:

It’s pretty slick, I think. I can enter the number of calories directly and ignore the multiplier column (it defaults to 1) as in the 150-calorie protein bar above. If I have a 2nd bar I can put a 2 in the “mult” column. Or I can enter a formula like “=100/113” (shown as 0.8849 above) if a serving has 100 calories and 113 grams, as happens to be the case for 2%-milkfat cottage cheese. Then I can use a kitchen scale to see how many grams I’ve eaten and put that in the multiplier column. Either way, the actual number of calories consumed is shown in yellow.

What about home-cooked food or restaurant food with no nutrition labels? For this I use the Macrofactor app. It lets you take a picture of any food and magicAIally guesses all the nutrition facts. (Or if you’re eating something with a bar code, it knows all the bar codes. You just scan it.)

(ADDED LATER: You people are relentless. Yes, you can drop a stick of butter in your spaghetti sauce and the AI calorie guesser will be none the wiser. The solution to that is, don’t do that. The AI is making a guess based on what it can see and it will sometimes be over and sometimes be under and on average it will be… pretty good, I think? Unless you introduce a systematic bias by making deceptive-looking meals. Again, maybe don’t. And let us link again to our post about ice cream truck loopholes.)

Of course Macrofactor is its own whole system for nutrition, fitness, and weight control. I think it actually has a similar control system deep inside its black box. It shows you your trend weight (if you tell it your weight) and adjusts your calorie and protein recommendations to nudge you towards whatever your goal is. It’s all too opaque for me though, as I suppose it has to be to be usable by normal humans. Still, a Beeminder goal for adhering to its recommendations most days might well work as effectively as this protein dial system.

But back to the protein dial, I also have this gauge/dial dashboard on the same spreadsheet:

As you can see, today my scale weight is slightly above the maxflux line on my Beeminder graph so the target for my dial is 29%, slightly above the minimum (maximum laxity) of 25%. Of the 483 calories I’ve eaten so far, 285 are from protein, so my actual dial is at 59%, far above what it needs to be. I can then enter a hypothetical protein percentage for the rest of the day to see how many more calories I can eat such that my dial doesn’t dip below the 29% target.

If I wanted to reward myself with Crumbl cookies at this point, I’d change that 27.5% to 2.7% and I’d see that final line change to 550 calories. So I could eat like three quarters of a Crumbl cookie and I’d be done. If I, in gross violation of this system, ate the whole 730-calorie cookie, I’d see the final two lines as follows:

2.7% protein for remaining calories
−180 remaining calories eatable

In other words, I exceeded my allowed calories by 180. But the situation is salveagable if from here on I exceed the dial target’s 29% for my remaining calories. Suppose I decide to start eating non-fat Greek yogurt, which has 69% of its calories from protein. I put that 69% in the protein percent cell and now the final two lines show this:

69% protein for remaining calories
119 remaining calories needed

So 119 calories of yogurt and my dial will hit 29% on the nose. Perfect. For the rest of the day I can eat what I like as long as it’s not below today’s dial target of 29% protein.

The Five Theses of Dials & Gauges

Melanie and I have been debating this endlessly in the weightloss channel of the Beeminder Discord. I gravitate strongly to quantified systems and bright lines; Melanie’s all about flexible rules and addressing one’s underlying psychology. She worries that my approach can engender an unhealthy relationship with food. (Bethany has very gamely experimented with both of our approaches and may have more to say about her own happy medium in a future post.) But Melanie and I managed to converge on the following five principles for getting the best of both worlds — mindfulness and healthy habits along with a feedback control system.

(One more review: you monitor a proxy metric of your health called a gauge and have another metric you control (like protein percentage) called a dial. Adjust the dial, per a formula, to control the gauge. And critically, if you’re far enough in the green on your gauge, you ignore the dial altogether.)

Adding dial&gauge guardrails rarely hurts. In theory they can be a crutch, like in that Batman movie where he couldn’t manage to climb out of the pit until he ditched the safety rope and was nice and motivated by a fear of death. Just learn to not let the graph psyche you out rather than ditch the graph.
If you get past Thesis 1, adding guardrails is just a backup system. You can and should use mindfulness to avoid ever hitting the guardrails. (And if in doubt, and especially if using scale weight as a gauge, set your red line much higher than you may think you want it. That way you have plenty of breathing room to practice mindfulness without pressure.)
If you do hit the guardrails, they help. They do not backfire by putting you in a what-can-I-get-away-with mindset or make you feel guilty for eating “bad” foods or any of that. If you’re prone to those psychological traps, address them separately. The guardrails are a more systematized and distilled version of mindfulness for people who can benefit from bright-line rules.
If the rules that kick in when you hit the guardrails are counterproductive in any way, well, we’re all adults. You should be trusted to perceive that counterproductiveness and construct better rules.
Or even simpler: dial up (in the informal sense) the strategies Melanie teaches to mindfully minimize bumping into the guardrails in the first place.

Protein in various foods and food-adjacent products

As a handy reference, here are some options for upping your fraction of daily calories that are from protein. To compute these protein percentages, take grams of protein times 4 (usually) and divide by the number of calories. (Sometimes this can get fussy, either due to rounding on the label or because technically some sources of protein have a bit less than 4 digestible calories per gram. This is called Atwater specific factors.)

Thanks to Melanie and Bethany who helped compile these.

83-96% for whey protein isolate protein powder. I get pretty sick of this pretty fast.
80-91% for liquid egg whites. I haven’t tried this.
80% for tilapia.
78-90% for canned white tuna packed in water.
77% for skinless chicken breast. (50% for skinless chicken thighs.)
75% for David protein bars which I think taste better (no worse anyway) than Cliff bars. They’re very processed, of course, but the ingredients seem fine enough. I doubt it’s much less healthy than protein powder.
72% for turkey lunch meat.
69% for non-fat Greek yogurt.
60% for non-fat cottage cheese.
47-59% for tofu.
59% for salmon.
58% for Musashi bars which have grown on me and I think taste at least as good as the David bars. The ingredients also seem fine enough. Both Musashi and the David bars use fake sugar, which I think is fine.
53-54% for, what — spinach! Who’d a thunk it?
49% for Built Puff bars (brownie batter flavor) which taste, bizarrely, about as good as normal candy bars. Suspicious.
43-47% for dry roasted edamame (too dry for me). And also for non-dry-roasted aka soy beans.
44% for Quest protein bars (chocolate chip cookie dough flavor).
40% for skim milk.
34% for a hard-boiled egg.
33% for Snickers Hi Protein bars (not palatable IMO).
28% for brussel sprouts. These brassicas and leafy greens keep surprising me. Kale, kohlrabi, cauliflower, collard greens — they’re all in here from ~25-32%.
27% for lentils.
26% for black beans.
24-27% for RXBARs.
24% for Gatorade protein bars (chocolate caramel flavor).
23% for broccoli!
23% for cheddar cheese.
22% for chickpeas.
22% for whole milk (note skim milk all the way up at 40%).
20-23% for cabbage.
20% for Mealsquares, which are minimally processed.
14-22% for whole wheat bread. (We looked up a handful of our local supermarket brands to get a range.)
14-17% for Cliff bars (and they don’t even taste good, what the fork).
15% for quinoa.
14% for oatmeal.

Footnotes

[1] Melanie would like us to emphasize here that you need progressive overload, meaning that you keep increasing weight and reps. In the wise words of Greg LeMond, it never gets easier, you just go faster.

[2] My robominion is pushing up its glasses and saying that technically it was the New York Times Magazine that came up with that title — “What If It’s All Been a Big Fat Lie?” — for Gary Taubes’s article.

Feature Announcement: Tare Tags

dreev — Tue, 07 Oct 2025 00:00:00 GMT

As promised, tare tags are live! And the old “odometer reset feature” is dead, thoroughly subsumed by the new tare tags.

Background

Besides knowing that taring (aka zeroing) is what you do to a scale when you want to weigh stuff not already on the scale, you need to know that Beeminder really likes cumulative graphs. See the classic post from Grayson Bray Morris explaining why, for Beeminder goals, cumulative graphs are Good and Correct. (Very briefly: it’s how we allow you to accumulate safety buffer, getting ahead of the bare minimum you committed to maintain as an overall average.) But the important thing for now is that Beeminder graphs are cumulative whether or not you enter cumulative data. Let us explain.

Most Beeminder graphs, like standard do-more or do-less graphs, don’t expect cumulative data. These graphs are auto-summing. That means you enter the additional amount (“the delta”) that you did each day and the cumulative total is plotted on the y-axis for you. [1] Odometer-style graphs do not auto-sum. Whatever value you enter is directly plotted on the y-axis.

(Ignore weight-loss and weight-gain goals for now. They’re neither auto-summing nor cumulative, exactly, but also they’re not relevant to taring. Not yet anyway. We’re intrigued by a use case where you tare your weight after getting dressed so you can log your true weight throughout the day without actually getting naked for each weigh-in. But it’s weird and messy — with the numbers and the taring algorithm, not the nakedness — so we’re not officially supporting that yet. If you really want to experiment, you’ll need to change your weight-loss goal to use aggday “last” instead of aggday “min”. Beeminder experts only!)

So usually you want auto-summing. Like if you ate 3 vegetables today, you enter a +3 on your veggies goal. Easy peas-y. But sometimes the convenient number to report is the new total. Maybe you’ve read 7 pages today but to figure that out you’d need to subtract the page number you started at from the current page number. Easier to just tell Beeminder your current page number! Especially since — if you started on page 1 (more on this shortly) — the current page number is your total number of pages read, exactly what’s plotted on the y-axis.

Quick version if you don’t want to learn any (more) new things

It used to be that a zero datapoint on an odometer goal would be treated as a reset of the odometer. Maybe you were beeminding numbers from a literal odometer and it literally got reset. Like you tracked your miles driven and your car died at 123,456 miles. If you want to keep tracking your cumulative miles (let’s pretend you got a brand new car with 0 miles on the odometer) then it would be pretty annoying to have to add 123,456 to the reading on the new car every time you reported the number to Beeminder.

Instead, Beeminder would presume that any zero datapoint was an accidental odometer reset and magically add the previous total to all new datapoints from then on. It was very handy for a lot of things, like beeminding total pages read by reporting the page number. Starting a new book is like getting a new car with zero on the odometer.

But it was also a gross violation of the Anti-Magic Principle, as we talk about in the second half of our recent post about magic strings. I may have mentioned punching my past self in the face.

So now everything is exactly the same except that if you want that to happen, you have to explicitly tag the datapoint with “#TARE” in the comment. See our previous blog post about magic strings in datapoint comments for background on how that works in general.

Ok, this concludes the quick version. You used to implicitly get an odometer reset with a zero datapoint. Now you explicitly get it by tagging the zero datapoint with “#TARE”.

Also we took the liberty of converting all your existing data. Zeros on odometer graphs now have the tare tag appended. (We used the @TARE version instead of the #TARE version, for reasons explained in the previous blog post.) Expect an email about this shortly if it applied to you. [Now sent.]

The wonderful generality (and explicitness)

What’s really new is that you can tare any datapoint. Maybe the shiny new car you bought was test-driven by some grubby grubkins and you only start driving it when the odometer already says “7”. Gasp. Here’s how you’d enter the datapoints (the carets are Beeminder’s shorthand for “today”):

^ 123456 “RIP my old car” [123456]
^ 7 “New car acquired with 7 on the odometer #TARE” [123456]
^ 107 “Inaugural 100-mile road trip” [123556]
^ 999 “About to hit 4 digits on the odometer but 8 more miles till I’ve driven this car 1000 miles” [124448]

In brackets we’ve put the actual values plotted on the y-axis of the graph. Notice how the 7 miles that were already on the new car are never added to the running total — which is just miles you’ve driven — thanks to taring the graph. But all that you, as the user, ever have to worry about is reporting the actual odometer reading.

As a simpler example, maybe you want to beemind your way through a book but skip the boring introduction. Say chapter 1 starts on page 30. When you enter a “30”, that should mean you’ve actually read just the first page of the meat of the book. You can now enter data like this:

^ 29 “Skipping the first 29 pages before chapter 1. #TARE” [0]
^ 30 “Finished page 30, ie, the first page of chapter 1” [1]

Here’s a more convoluted example if you want to really make sure you’ve got your head around it:

data entered		value plotted
0	#TARE	0	It doesn’t actually matter if there’s an explicit TARE tag on an initial 0 datapoint
20		20	First real datapoint
50		50	If this were auto-summing we’d plot “70” but it’s not
0	#TARE	50	A traditional odometer reset
10		60	Odometer shows 10 + previous 50 = 60 total
15		65	Again, add previous 50 to current odometer
100	#TARE	65	Ignore current reading of “100” but remember it
130		95	30 more on the odometer means 30 more than the 65 previously tared at

“We’re relieved that you now have to be less of a supergenius to make Beeminder behave as you want it to”

The general algorithm (feel free to skip this if you’ve got the idea already): Until there’s a taring, the y-values plotted on the graph match the entered datapoints. Now say a datapoint with value v is marked as a tare and let u be the previous y-value (or 0 if this is the first datapoint) before v was entered. Then the actual value of v is disregarded (but remembered). The plotted value corresponding to v is still u and subsequent datapoints are measured as the delta from v and added to u. When that happens more than once, those deltas just accumulate.

(Fun fact: All of this was technically possible with the old odometer reset feature but it involved outrageously clever / excruciating abuse of the feature. Credit to Scarabaea for the ingenuity there. We’re relieved that you now have to be less of a supergenius to make Beeminder behave as you want it to.)

Whittle-Down use case

We don’t know if this one’s a good idea yet, but… As an alternative to the schemes we’ve blogged about for backlog-minding, you could beemind something like your inbox with a whittle-down goal, but every so often, maybe even at the end of every weekend, you just tare the graph at whatever value it ballooned up to.

In this scenario you are still beeminding the size of your inbox, entering the current size and always trying to make that number go down. But you’re kind of giving yourself a free reprieve periodically. Your inbox size can jump up but the plotted y-values will keep going down. Possibly into negative numbers.

Like we said, it could be a bad idea. It seems to violate the Quantified Self First principle. And unless you have a principled rule for when it’s ok tare your inbox at a higher value, that could be too much of a loophole. (Or maybe it’s an ice cream truck loophole and it’s fine?)

Probably you should mostly think of tare tags as applying to graphs that go up. Book reading, bike riding, word writing, Anki reviewing. Those sorts of things. We assume someone will do something wildly creative with this though.

Oh my goodness the sheer number of things this fixes

Here’s a dumb one: Sometimes users would create an odometer goal, which would naturally have an initial datapoint of zero. That would technically yield an odometer reset — what we now call a taring — but when you do that to the first datapoint, it’s a no-op. Fine. Then maybe the user would add a datapoint of 10 for today, in addition to the initial zero. Still fine. But then maybe they’d backfill a datapoint for yesterday of 5. Do you see the problem? The person doing this probably didn’t. The 5 yesterday, followed by a tared zero today, would mean that today’s 10 is now added to yesterday’s 5. So the graph would plot 15 today instead of the expected 10.

That one at least is fairly corner-casey.

How about this disaster that happened to my own URLminder goal, for automatically fetching wordcounts of documents and beeminding my total words written:

What is going on there? Well, the documents I’m pointing to sometimes fail to load when Beeminder requests them, which means Beeminder sometimes fetches a zero datapoint. Now you see the problem. All those zeros got processed as odometer resets, so each subsequent non-zero fetch got added cumulatively to the previous total. (Btw, tarings are indicated visually on the graph with faint vertical dotted lines, same as odometer resets were.) This is especially tragic because it just silently inflated my total wordcount higher and higher until I had infinite safety buffer and the graph was buried at the bottom of my dashboard, out of sight, out of mind.

All these problems are now mercifully a thing of the past.

You could say we’re zeroing them out and making a fresh start. #TARE

Footnotes

[1] We sometimes, like in the API, call auto-summing graphs kyoom graphs, or kyoom=true. It’s phonetic for “cumulative”.

Magic Strings In Datapoint Comments

dreev — Tue, 23 Sep 2025 00:00:00 GMT

This is a followup to our previous post on magic strings.

There are three (soon to be four) magic hashtags that Beeminder can add to a datapoint comment. They’re reasonably self-documenting and if you’re a newbee you probably don’t care about any of this nitty-gritty. But we just finished cleaning this all up in the codebase and we want to document how everything works now. Also we have a heads-up for veterans who may have been counting on some crufty backwards-compatibility for wild use cases that even we can’t fathom. You’ll need to get with the program, as laid out here. (But of course if this is ruining your day or murdering children, definitely let us know and we’ll help get you sorted.)

#SELFDESTRUCT (or #THISWILLSELFDESTRUCT)

We’ve talked about this magic string extensively in the forum and in our previous blog post, but we’ll repeat everything here for completeness.

First, a quick review of Pessimistic presumptive reports (PPRs). Think of them as the do-less analog of flatlining on a do-more goal. For a do-more if you don’t enter any data, Beeminder assumes you did nothing, and soon enough that’ll derail you. If you don’t enter anything on a do-less goal, it’s pretty critical that Beeminder not presume you did nothing, since that would have you safe forever and you could just stick your head in the sand and pretend the goal didn’t exist. Instead Beeminder presumes you did twice the daily amount you committed to stay below, on average, if you don’t report anything. Meaning that, as with a do-more goal, not reporting any progress means you’ll soon derail.

The other thing to know about PPRs is that they automagically self-destruct when you enter an actual datapoint. And the mechanism by which they do that is to include the string #SELFDESTRUCT in the datapoint comment. (Or #THISWILLSELFDESTRUCT — we use that variant to make it as self-documenting as possible.)

That means you can make your own datapoints self-destruct if you want! Why would you want that? Well, superuser Alys has a very clever use case. Suppose Alys has a lot of safety buffer on a goal, but wants to get herself to do at least some work on it today. She enters a #SELFDESTRUCT datapoint with a large negative value (for a do-more goal), putting the goal into the red, which sorts it to the top of her dashboard. Once she’s done some work and enters the data — voila! The #SELFDESTRUCT datapoint is automatically removed and her safety buffer is safely back where it belongs.

Now the fine print and a heads-up.

If for some reason you try to add multiple #SELFDESTRUCT datapoints for the same day, separately or as a batch, each will annihilate its predecessor and only the last of them will remain. Probably that’s the logical, natural thing to happen, but, again, wild use cases we can’t fathom, so we thought we’d spell it out.

And the heads-up is that in the past, datapoint comments that started with “PESSIMISTIC PRESUMPT…” were yet another way to make a datapoint self-destructing. That’s officially gone now and we appended ” #SELFDESTRUCT” to all such datapoints so nothing changes on you retroactively (we don’t think). (And actually we used @SELFDESTRUCT with an “@” instead of a “#” in this case, for a reason we’ll talk about at the end.)

#DERAIL

This one essentially marks a dummy datapoint indicating when a derailment happened. Such datapoints are displayed on your graph as a red triangle, pointing up or down depending on which side of the bright red line was the bad side to cross into.

We want this recorded as if it’s a datapoint in order to record exactly where you were at the point when you derailed. There’s not necessarily a real datapoint at that point due to flatlining. That is, there’s a good chance that if you derailed today, it’s due to not entering any data. For a do-more goal, we show a faint triangle today with the same y-value as yesterday, indicating a presumed zero for today. So the #DERAIL datapoint reifies that into an angry bright red triangle.

(This one also had some backward-compatibility that we ruthlessly excised. Derail datapoints used to be marked by a datapoint comment that started “RECOMMITTED ON”. No more!)

#RESTART

Restarting a goal that’s been archived is very similar to derailing a goal in terms of the dummy “#RESTART” datapoint, and what we do with your bright red line. First we lock the red line in place up until now, so we aren’t changing the past. Then we make the line jump to whatever your current y-value is and add an initial flat spot and the new rate. We also add a #RESTART datapoint, analogous to the #DERAIL datapoint, and as extra insurance that we don’t accidentally trigger the derail condition.

In the case of an ordinary do-more goal that was properly archived it’s probably superfluous, though still nice to have it demarcated.

In other cases it can be totally fluous. Take the case of restarting an odometer-type goal. Your current datapoint might have no correlation to your last datapoint at all. You might have gone back to start your book over again because it’s been so long, or you stopped beeminding your email inbox, and it ballooned back up from the optimistic 10 messages you’d committed to the last time you beeminded it. Or maybe the goal wasn’t archived in the usual way — say you lost your credit card and had to cancel it, and then an ordinary derail caused the graph to freeze because your payment didn’t go through. In any of those cases, the usual flat-lined datapoint from whatever your last entered value was might not be safely on yesterday’s red line. That’s when a #RESTART datapoint is required to keep it from insta-derailing when you restart. Because “red yesterday” is the core criterion Beeminder uses to decide if you derailed. A Beeminder graph matrix has to be continuous, so there’s no way to indicate that yesterday didn’t count because the goal was inactive so we have to retroactively make it have-been active and safe yesterday.

Ok, phew, that was really more than you wanted to know. Probably as a user you only care about this one as a marker of, as it says in the hashtag, when you restarted a goal.

Coming soon: #TARE

As in taring a scale. Tune in next time for the whole story on this one.

More Fine Print, The Hashtag Feature, and Alternate Syntax

All of these are case-sensitive — they have to be in all caps. And if there’s anything else in the comment, it has to be separated from the hashtag by whitespace. So if you make a datapoint comment like “I’m gonna #SELFDESTRUCT!” it won’t work unless you stick a space in front of the “!”.

Ok, do you know about the hashtag feature? It’s in the privacy section of graph settings: “Show hashtags from comments on the graph”. It lets you annotate your graph with any hashtags you like by including them in your datapoint comments. This includes all magic hashtags above. Mostly we think that’s right and proper, explicitly labeling derailments, PPRs, restarts, and tarings. But if don’t want those annotations, only your own custom-crafted annotations, we finally have a solution. Namely, all the magic strings work equally well with “#” or “@”. If you use the “@” versions — @SELFDESTRUCT, @DERAIL, @RESTART, and (soon) @TARE — then everything we’ve said about these magic strings still applies, but they won’t be hashtags and so won’t be shown explicitly on your graph, whether or not you have the hashtag feature turned on.

For now, those who want only their own hashtags annotating their graphs will have to manually change the “#” to “@” on the instances that Beeminder generates. We’re reluctant to add an explicit setting for this unless there’s enough demand for it. So let us know!

Magic Strings are Anti-Magical

dreev — Tue, 09 Sep 2025 00:00:00 GMT

A magic spell is an incantation that, just by being incanted, makes something happen in the physical world. You say “avada kedavra” and someone dies — that sort of thing. Did you know that’s a literal real thing in programming and it’s called a magic string? [1] We use them in Beeminderland occasionally. The source document from which this blog post was generated uses them. That means that I absolutely cannot tell you what those magic strings are in this blog post. If I did it would literally break the blog and you would not be reading these words. Sounds dangerous, you say? Kind of! But it’s pretty ok with a couple ground rules:

Only pick a magic string that can never possibly be uttered accidentally.
Treat magic strings with some reverence and don’t casually type them out if you don’t mean to invoke them.

Like how in the Harry Potter universe people refer to “the killing curse” rather than actually utter “avada kedavra” in casual conversation.

Magic strings done right are, ironically, kind of the opposite of magic in the sense of the Anti-Magic Principle. [2] Namely, they’re a way to have something happen transparently, consistently, and predictably. Never accidentally, opaquely, or silently.

An example in Beeminder (besides the blog post ones we can’t tell you about on the blog) is certain hashtags in datapoint comments. You may know about pessimistic presumptive reports (PPRs) and how they automagically self-destruct when you enter an actual datapoint. Did you know that the mechanism by which they do that is to include the string #SELFDESTRUCT in the datapoint comment? And that you can include that string yourself if, for reasons (HT superuser Alys), you want any particular datapoint to self-destruct when a new datapoint for that day is added?

The worst anti-magic violation in all of Beeminder

Let us pause to tell you about the odometer reset feature. It’s so bad that I (dreev) want to punch my past self in the face for having been the one to come up with it. It’s the feature where, if your datapoint is ever zero we just silently, magically start adding your cumulative total so far to every future datapoint.

(There are mitigating factors: (1) It only applies to goals specifically created as odometer goals and so is not super likely to confuse normal users. (2) It really is exactly what you want to happen most of the time and is super handy for things like beeminding your way through multiple books and being able to always just tell Beeminder the page number you’re on. (3) We did this before we figured out the Anti-Magic Principle. We’d never implement something like that today.)

The way to fix that (coming soon! PS: ok, now) is with, drum roll, another magic string in the datapoint comment. In this case the plan is to use #TARE. [3]

The way it would work in the book reading example above is you complete your first book and enter the final page count as your datapoint value on Beeminder:

^ 349 “finished Adventures of Tom Sawyer”

And then you pick out the next book and add a #TARE point like so:

^ 0 “starting Huckleberry Finn #TARE”

This can also work for other more literal odometers. Say a goal tracking your total cycled miles across multiple bikes and bike computers over the course of your life. And things like taring your weight graph so you can weigh in multiple times in one day without getting naked each time. Also nebuminding, where you want to beemind words added to a document but not let words deleted count against you.

We’re not saying a magic string in the datapoint comment is the best implementation of this tare feature, but it’s expedient and a huge step up from the anti-magic violating abomination that is the current odometer reset feature.

Footnotes

[1] See also in-band signaling which is mostly what we mean here. The Wikipedia article on magic strings is mostly about ways magic strings are abused. Possibly this means we should find a different term!

[2] Not the opposite of magic in the sense of “science”.

(From the Moste Excellent Webbe Comik, Girl Genius, by Phil and Kaja Foglio, et al.)

[3] Like when you zero a scale. There was some debate in the Beeminder Discord a while back about how common-knowledge the term “tare” is.

Time Bridges: Beeminder on The Future of Life Institute Podcast

dreev — Tue, 26 Aug 2025 00:00:00 GMT

This is embarrassingly out of date, but since it’s literally about Time Bridges, that makes it all the more apropos, right? (If you’re wondering how we even dug up something this old, you might like our recent series on backlogs and freshenable collections.)

The Future of Life Podcast is mostly about AI these days, reasonably enough. Actually it’s been particularly prescient in having that as a focus for 9 years or so. But back on the eve of 2019, they did one called “Existential Hope in 2019 and Beyond”. They interviewed several experts, including Beeminder fan Gaia Dempsey who talked about Beeminder and related strategies for what we call incentive alignment.

Since it’s a beautiful bit of Beeminder evangelism (and entirely organic and unpaid, we hasten to add) and because it coins a handy term, we wanted to preserve the relevant bit of the transcript for posterity. We’ve edited it for clarity and concision but, to keep us honest, the original recording is hosted on SoundCloud (from 20m38s to 23m59s).

Gaia Dempsey: My favorite type of tool I think is very rare: the kind that support us developing the capacity for longterm thinking, and for being true to the longterm intentions and goals that I set for myself.

Ariel Conn: Can you give some examples of those?

Gaia Dempsey: One example comes from the book Ready Player One. The main character is interacting with his VR system that he lives and breathes every single day. At a certain point the system asks him, “Do you want to activate your health module?” [It’s called the “Fitness Lockout protocol” in the book.] And without giving it too much thought, he says, “Sure, yeah, I’d like to be healthier.” And it instantiates a process whereby he’s not allowed to log in to the OASIS without going through his exercise routine every morning.

This is an interesting system design choice, because he didn’t actually do that much deep thinking about “oh yeah, this is a choice I really want to commit to”. But the system’s saying, we’re thinking through how your decision-making works, and we think that this is something that you really do want. And we think you’re going to need about three months before you make a final decision as to whether this is something you want to continue with.

So that three month period (or whatever it was in the book) is what’s known as an akrasia horizon.

Which is a term that I learned through a different tool that is sort of a real-life version of that, which is called Beeminder. The akrasia horizon is a time period that’s long enough that it will circumvent a cognitive bias that we have to really prioritize the near-term, at the expense of the future.

In the case of the Ready Player One example, the near-term desire that would circumvent his longterm health is, “I don’t feel like working out today, I just want to get into my email, or I just want to play a video game right now.” And a very similar setup is created in this tool, Beeminder, which I love to use to support some goals that I’m very motivated to meet. So it’s a tool where you can put in your goals and you can track them, either yourself by entering the data manually, or you can connect to a number of other tracking capabilities like RescueTime and others. And if you don’t stay on track with your goals, they charge your credit card. It’s a very effective motivating force.

I have a nickname I call these systems: “time bridges”. Which are really choices made by your long-term thinking self that in some way supercede the gravitational pull toward mediocrity inherent in your short-term impulses.

It’s about experimenting, too. This is one particular system that creates consequences and accountability, and I love systems. For me, if I don’t have systems in my life that help me organize the work that I want to do, I’m hopeless. So that’s why I like to collect and am an avid taster of different systems. And I’ll try anything to see what works. I think that’s important. It’s a process of experimentation to see what works for you.

Amen to all of that.

Downtime and DEFCON Levels

dreev — Tue, 12 Aug 2025 00:00:00 GMT

A couple weeks ago we had close to 9 hours of downtime. Some kind of meltdown in the datacenter in Newark where our servers live. A lot of websites/apps were affected, which I guess lessens the shame of it, though it’s embarrassing we’re not more robust to this kind of thing. Anyway, check out status.beeminder.com for a link to the gory details. And keep that URL in mind to check in case Beeminder is down in the future.

But let’s not dwell on that. It reminded us that we have a system for conveying the priority of bugs and other brokenness that’s sometimes handy. It goes like this:

DEFCON:pS — seconds matter, the servers are literally on fire
DEFCON:pM — minutes matter, the servers are figuratively on fire
DEFCON:pH — hours matter, brokenness we have to fix before we can sleep
DEFCON:pd — days matter, it’s something that preempts all other normal work
DEFCON:pw — weeks matter, lower priority
DEFCON:pm — months matter, no hurry
DEFCON:py — years matter, i.e., maybe/someday, i.e., wishlist

In practice, we never use anything beyond “pd” (days matter). See our old post on our system of bug labels and the ill-fated “OMG” label for why we mostly don’t assign priorities to bugs/tickets. (Except for regressions aka zombies, which we talk about in Control Systems For Backlogs.)

We do combine the seconds/minutes/hours/days levels to get finer-grained priorities. Like DEFCON:pMH means “minutes or hours matter”. So definitely don’t go to sleep before it’s fixed but it’s not quite at the point where you should hold your pee. Or DEFCON:pHd means “hours or days matter”. So don’t literally lose sleep but get back at it as soon as you roll out of bed.

I don’t think we’ve ever used DEFCON:pS. No, wait, there was that time we ran a bad query that started deleting the database row by row. But that might’ve predated this DEFCON nomenclature.

For a burgle bug we’d probably say DEFCON:pM. For a merely embarrassing bug, either DEFCON:pMH if it affected all users, or DEFCON:pH or DEFCON:pHd if it was more niche. Or I guess :pd or even :pdw if it was niche enough.

We’re telling you this because having this shorthand has been handy for us, so maybe you’ll like it too? I think the advantage of it is that it straightforwardly combines priority and severity in a way that’s intuitive to set a value for.

Why Danny Hates the Beemium Plan

dreev — Tue, 22 Jul 2025 00:00:00 GMT

We keep raising the price of Beemium (currently $64/month as I write this). When we do, we grandfather existing users for a year. Most businesses warn everyone when they raise prices. It’s a classic Act Now inducement: lock in the old price before it’s too late. We don’t do that for the Beemium price hikes. Why not? Because we don’t want more people getting Beemium. Do we hate money, you ask? Not exactly. We actually have a list of reasons we want to wean people off Beemium and discourage new users from opting for it. Setting a high price is saying “don’t go for this one unless you really, really want it”.

So here are the reasons.

1. It’s unbeeminder-y

I, as an avid Beeminder user (as opposed to ex officio as CEO), personally dislike Beemium and have never paid for it as a user. Bee (my cofounder and CTO) is the same. We do both pay for Bee Plus, and would pay much, much more for it (were it to cost much, much more). Beemium’s zero-dollar pledge caps feel especially wrong. A Beeminder graph with nothing at stake is hardly a Beeminder graph. And the 50% charity option: see our old post on why we hate anti-charities, which includes a bit about why we don’t think commitment devices with (good) charities as the beneficiary are ideal either.

2. We might kill it eventually

See our old Strategy Memo: Beeminder Is Pledge-Focused. Though more likely Beemium is the principled exception, the thing we would keep charging for even if we made everything else free. Beemium is where the revenue-eating features go. Which brings us to…

3. It’s expensive for us

In particular, Beemium includes quasi-real-time support and the charity option which is partially shirk-n-turked so we’re a bit averse to creating more Beemium users especially if they don’t care much about those expensive features.

4. Pledge short-circuiting is a honey trap

Not that we intended it to be. It just, in our pretty vast experience, is something people think they want but tend to be wrong about. When someone jumps to a huge dollar amount at stake because they’re feeling all gung ho and hard-core, they’re more likely to weasel when they derail. Or freak out and quit when it gets hard. Climbing the pledge schedule like God intended is, empirically, more awesomeness-inducing. But this is admittedly highly individual; if you’re sure that you want pledge short-circuiting, you could be right.

In conclusion

Mostly we could call this a boring business decision. Beemium is expensive for us and expensive for you. Also the cool kids don’t need Beemium. Bee Plus is the coolest plan, in our humble opinion. And look how cheap it looks, next to Beemium! 🤑

Thanks to Alys for encouraging us to blog about this.

Deprecation Warning: Using “Deprecated” To Mean “No Longer Supported”

dreev — Tue, 08 Jul 2025 00:00:00 GMT

Welcome to the Dreevpeeve of the day. I’ve actually seen “deprecate” misused so often that I was worried that, as usual, the prescriptivists would soon have to concede defeat. But so far all the dictionaries are holding firm. This is merely in the category of Common Misconception and so I’m doing my part with this blog post to hold the line. We don’t want another “literally” on our hands here.

First, what it actually means to deprecate something:

To express disapproval of it
To play it down or belittle or disparage it
To withdraw official support for it or discourage the use of it in favor of a newer or better alternative (chiefly of software)
To seek to avert it, or (archaic) to pray against it

Definition 3 is the one people are confused about. But as you can see, they’re all variations on the same theme. Google’s dictionary (which I hate, but that’s a story for another blog) groups the software definition of “deprecated” with their main “disapproved of” definition:

(Chiefly of a software feature) [to] be usable but regarded as obsolete and best avoided, typically due to having been superseded. “This feature is deprecated and will be removed in later versions.”

“Deprecated” just means “disapproved of”

The Common Misconception is betrayed, for example, in this request (edited to protect the innocent) from one of our integration partners:

We’d appreciate it if you can update Beeminder to not use [thingamabob] so that we can hopefully deprecate it.

You’re not hopefully deprecating it, you’ve deprecated it, right there in the first half of the sentence. What you hope is to actually remove the old thingamabob! [1]

Here’s another example I found — someone talking about a thing from OpenAI called the Assistants API:

They promise more to come, and that chat completions will be supported going forward but they plan to deprecate the Assistants API mid-2026.

What OpenAI actually says:

[After the Responses API subsumes the Assistants API] we plan to formally announce the deprecation of the Assistants API with a target sunset date in the first half of 2026.

It’s admittedly confusing, talking about a plan to formally deprecate something. I even found an example of us falling for this ourselves, culled from Twitter back in 2013:

@fitbit you deprecated activeScore a month early! The api is returning -1 as of Sept 28th, not Oct 29 per [rotted link to Fitbit support forum]

I’m almost surely the one who wrote that, and am duly embarrassed. [2] Presumably I was following Fitbit’s misuse of the term.

I polled beemail subscribers on this a few months back. They’re super savvy and mostly didn’t actually recall hearing this kind of misuse. [3] But I predict that now that I’ve pointed it out you’re going to hear it all the time. Please glare disapprovingly when you do.

Footnotes

[1] In the case of deprecating old URLs, we recommend just adding them to an eternal list of legacy redirects and not worrying about how big that list gets. Even over decades it’ll stay perfectly wieldy. We’re old enough to know! The failure to create permanent legacy redirects for old URLs is definitely another Dreevpeeve.

[2] Conceivably it was Bee. She’s the one who was (still is) dealing with Fitbit’s API. But I’ve almost always manned the Twitters and whatnot.

[3] One of those savvy beemail subscribers came up with a steelmanning of at least one of these supposed misuses. You could read “we’ll hopefully deprecate it” as shorthand for going through a formal deprecation process, with the usual warnings in the documentation, culminating in eventual removal of support for the thing. Perhaps this conflation of “deprecation with scheduled removal” and mere deprecation is the source of the Common Misconception.

Freshenable Collections

dreev — Wed, 18 Jun 2025 00:00:00 GMT

Welcome to the next post in our Freshening Series. Before we get to that, let’s review our related posts on clearing and preventing backlogs:

Redqueening, Inbox Zero, Backlogs, and Fluid Dynamics describes Mark Forster’s Backlog Method — “isolate and redqueen” — using lots of analogies.
Control Systems For Backlogs lays out a particular beemindable system for whittling down a backlog.

Freshening is for the case that you have something like a backlog except you have no illusions of ever clearing it. So a collection more than a backlog. Here’s the Freshening Series so far:

Backlog Freshening introduces the core idea: a beemindable system for ensuring nothing in your collection ever gets too stale, focused on a GitHub use case.
Backlog Freshening For Humans by Beeminder Support Czar Nicky broadens the idea beyond tech nerdery, focusing on the example of keeping Beeminder’s help docs fresh. (This continues to be a smashing success.)
Rolodex Goals gets specific about how Bethany and I use a freshening system on our database of contacts, i.e., how we beemind being less neglectful of our friends and family.
This post, Freshenable Collections, in which…

…we start with a partial list of other collections we have ongoing freshening goals for on Beeminder, in case anyone’s inspired. Some of these may be worth their own future posts; just ask if you want details.

Beeminder’s Operations Manual
Beeminder blog post ideas and drafts
My and Bethany’s relationship repo aka conversation stack
Post ideas for my other blogs/newsletters
Beeminder’s main bugtracker
BeemiOS’s bugtracker
Beebrain’s bugtracker
Omnitask aka my personal tasks/notes (yes, I use a collection of gissues the way other people use Notion or Obsidian)
Math puzzles (but actually this is currently just part of Omnitask — gissues tagged PUZ)
Beeminder’s Tips of the Day that we auto-include in bot emails
Bibliophilia aka books I want to read
Household projects

I’ve been on a tear lately with freshening goals, and my protocol to bootstrap them has been like so (this parallels the “Phase 1: Migration” section of the Rolodex post):

I notice I have something like math puzzles or AGI Friday post ideas that I want a freshenable collection of.
Create the empty collection, which for me usually means creating a repo in GitHub.
Create the freshening goal on Beeminder.
To get the +1, look for an existing puzzle or post idea, wherever it currently lives, and migrate it to an item in the new collection.
If all the pre-existing stuff is already migrated, then make an epsilon improvement to the oldest item, i.e., freshen it. That’s where all +1’s come from in the steady state.
Creating new items doesn’t give you +1’s — freshening is all about the old stuff.

The short version of all those steps is that migrating pre-existing items to your collection counts as freshening.

Sidebar: Blog Dogfood

I’ve been doing this for Beeminder blog post drafts/notes/ideas for over three years. At the moment there are 135 future potential blog posts in the works! Most are extremely low-fractionally-baked ideas and probably most will never and should never see the light of day, but it’s really nice to have a way to curate the collection sanely and not just have it be a black hole.)

Finally, thanks to brainstorming help from many of you, here’s a meta-collection of ways to maintain a collection that all support the critical feature for freshening: a way to sort or query for the least-recently-edited item.

(Optional additional feature: a way to mark items as snoozed, meaning they’re immune from freshening. Which means your query/sort-by-stalest needs to be able to exclude snoozed items. For example, if you’re using a kanban tool like Trello, you can manually drag items to the bottom of their column when you freshen them, and move them to another column to snooze them.)

Without further ado, the meta-collection:

GitHub Issues (I use this for evvvverything (and maybe this is not crazy?))
The Things 3 app on iOS, with hackery from Philip Hellyer
Kanban apps like Trello or GitHub Projects (see parenthetical above)
A spreadsheet with a “last freshened” column
Plain text files in a directory sorted by last-edited
Emacs Org mode, probably
Airtable, almost surely
Obsidian with the Dataview or Tasks plugin
Taskwarrior
Mark Forster’s Autofocus on paper
Any collection of paper, like sheet music for songs in one’s piano repertoire

Thanks to Alys, Marcin Borkowski, lanthala, Brent Yorgey, and Robert Perce for contributing ideas for this post.

Time Stream ♥ Beeminder: A New App by a Long-Time Beeminder User

Mary Renaud — Thu, 05 Jun 2025 00:00:00 GMT

We’re thrilled and honored to welcome back to the blog the esteemed Mary Renaud, PhD. Though for now, only iPhone people can reap what Mary has sown…

I’m excited to officially announce my first iOS app: Time Stream!

What is Time Stream?

Time Stream is a routine management app that adapts when your day doesn’t go as planned. Routines will wrap around things that get scheduled into your day or adjust when something takes longer than expected.

I’ve had a lot of trouble with rigid scheduling apps and calendar templates that broke in the face of life’s little interruptions or when my schedule changed a little… So I built something that lets my routines kind of ride the current of the day.

You can create personalized morning, evening, and custom routines, each with activities with estimated durations. The app estimates when each routine will be finished and those completion time estimates update as you go. When the inevitable happens and things change (something runs late or gets interrupted or procrastinated), it automatically recalculates when the other activities and routine can fit in, so you can see exactly what you’ll still have time for, and you can adjust without losing track or spending a bunch of time fiddling with changing today’s plan. It also shows you exactly how your routines will wrap around your calendar events, and will give you visual cues if your routines are going to run past important critical times in your day, like when you need to leave for work. And it keeps me honest about whether “I’ll just do that later” is actually feasible, because I always know how much buffer I have in my day between my routines and my events or important times thresholds.

What’s The Benefit of Adding Beeminder Goals to Time Stream?

As a Beeminder user of over 12 years, it was critical to me that it work with Beeminder. Beeminder has had a huge effect on the shape of my life. But, given I tend to beemind a lot, I’ve also had a hard time being able to visualize when my day was getting off the rails and my infinitely many Beeminder goals wouldn’t all be accomplishable if I didn’t get moving RIGHT NOW. (I used to use the fantastic waterfall method, but things changed a little in my day’s structure, making it harder to make that work.)

Each activity can be linked to a Beeminder goal so that, when you check it off in Time Stream, it adds a +1 datapoint to that Beeminder goal immediately (or, as of a recent update, if you check it off while offline, it will add it as soon as you’re back online).

And since I’ve never seen an over-engineered system I didn’t love, I also added “critical times” which are visual representations of thresholds in the day that I want to be aware of. We can use this for things like making sure morning routines are done before the “critical time” to leave the house or that evening routines don’t extend past bedtime. Beeminder users can also, if we want, set the deadlines for activities in a given routine to a specific deadline, and then set that deadline as a critical time in the app. The app will then flag if a routine connected to that critical time is going to go past that deadline, so you know if you’re at risk of derailing any of the goals in that set.

Setting Up Your Time Stream + Beeminder Goals

In the Time Stream app, go to Settings > Integrations > Beeminder. You’ll need to authenticate with Beeminder. This does not get sent to or saved to any Time Stream servers or anything (nothing does). Then, select which Beeminder goal should receive +1 data from Time Stream activities by selecting the goalname and the activity.

That’s it. Done.

You can connect more than one activity to a goal. (I use this, for example, because my Weekend routine and Weekday routines are different, but some of the activities overlap, and I don’t want two different Beeminder goals for the Weekday & Weekend versions of that commitment.)

Caveats

A New App from a New Developer: I’m brand new to developing for Apple devices, so there are still a few bugs being worked out. I’m fairly confident there are no bugs left in the Beeminder integration, though. Since those are potentially costly to users, they’re top priority. The price will go up between 50% and 100% down the line but, for now, I’m keeping it at the current price ($8 USD), in case there is the occasional bug that might be frustrating to users as I learn.

Upgrades won’t be free, but there’s no subscription cost: There are no server costs, so I’m going with a no-subscription model. You buy the current version and don’t have to pay for it again. When major updates happen, you can choose between sticking with what you’ve got, or upgrading. Bug fixes will be included for two years for each version (as long as we’re still in business!) but new major versions or fixing older version when new a iOS break things won’t be.

In the End…

Building Time Stream has been my own answer to years of life’s unpredictability clashing with my “perfectly” planned routines and Beeminder goals.

If you, too, know the pain of frantically calculating whether you can still hit all your goals when your day goes sideways, maybe this will be helpful for you too.

Want to get started with Time Stream? Download it at time-stream.app.

Rolodex Goals

dreev — Wed, 21 May 2025 00:00:00 GMT

We have a pair of blog posts from 2022 called “Backlog Freshening” and “Backlog Freshening For Humans” that we’re still very pleased with. To recap, say you have a backlog of something — tasks, emails, blog post drafts, bugs, you name it — that it’s not realistic to clear. (If you do need to clear it, see “Control Systems For Backlogs.”) Which is to say, you have a collection of items. And you don’t want the collection to be the place where items go to die. Enter freshening, in which you sort the collection by least-recently-touched, and then you beemind regularly revisiting the collection, stalest item first. Every +1 that Beeminder demands is satisfied by making progress on or improving in some way that stalest item. You can also think of it as doing spaced repetition on your collection.

It turns out we have a lot more to say about this, most of which we’re saving for a future post about Freshenable Collections generally. Today we want to share a particular example we think this works great for: your rolodex.

Oh, sorry non-ancient people, that means your database of contacts. As in friends and family and colleagues. Fellow humans with whom you have relationships.

Being weirdos, Bee and I keep ours in a GitHub repository as a set of gissues (er, GitHub Issues — we call them “gissues”; did we mention we’re weirdos?). You need something that lets you sort or query by least-recently-updated, and gissues are such a thing. So here’s the protocol we use.

Phase 1: Migration

Assuming you don’t already have your address book in a collection that’s sortable by least-recently-touched, you can make the migration part of the Beeminder freshening goal. Here’s how that looked for us:

Export your Google Contacts to a big text file
Create an empty private GitHub repository called “rolodex”
Create a freshening goal on Beeminder (also “rolodex”)
When Beeminder demands its +1, satisfy it by moving a contact from the text file into a newly created gissue for that person

In other words, migrating pre-existing items to gissues counts as freshening.

Note: In the event you someday make a new friend you should certainly make a gissue for them, but that doesn’t count as a +1 on the freshening goal. Freshening is all about the old stuff. Eventually the new friend will become the stalest gissue and you’ll freshen them then.

Phase 2: Steady State

Ok, suppose there’s no one left to migrate. You keep right on going with the same Beeminder goal, just that how you get those +1’s changes. Now you get your +1 by pulling up the stalest gissue and freshening it, i.e., updating it so it’s no longer the least recently updated one.

Things that change the updated-at date on GitHub include editing the description or title, changing tags, adding or editing a comment, and assigning the gissue to someone.

(That last one matters for Bee and me, sharing a rolodex. She can assign me people on my side of the family, for example. Then when sorting by least-recently-touched, we can also filter out gissues assigned to the other person. Also we’re currently doing this with individual goals but this is a great use case for group goals.)

Emoji reacts and external references don’t seem to update the timestamp.

That said, and possibly especially because there are two of us beeminding the same list (consistency! accountability!), we like to have some guidelines for what counts.

Adding or updating contact info (addresses, phone numbers, etc)
Adding any notes about birthdays or children
Editing keywords or labels/tags (maybe you want to be able to search up all the lawyers or nurses you know?)
Adding notes about your history together
And of course: actually pinging the person

Of course, contacting a person IRL doesn’t update the timestamp of the gissue, so either leave a comment with a brief description of how/why you pinged them, or add a list of dates you talked.

What if there’s someone whose entry in your rolodex has reached quiescence/efflorescence and you don’t have it in you to reach out to them? (Hopefully this isn’t because it’s been so long that you’re embarrassed to, but that’s all the more reason to get a rolodex freshening goal up and running!) Whatever the reason, there’s one other option for freshening them, which we call snoozing them. Technically, that means applying a special label that you exclude when you query for the stalest contact in the rolodex. Pragmatically/morally, it means admitting that you’re ok with that person going out of sight and out of mind if they don’t initiate contact themselves. They’re still in the system, still searchable, but you’re taking them out of your freshening rotation. Probably permanently, since Beeminder will never prompt you to ping them again.

Dialing It In

I’m at 316 freshenings and counting, dialed to 0.29 per day. It doesn’t really matter how steep your bright red line is but one way you might want to think of it is that, if you dialed it to 1 per day and you have, say, 350 unsnoozed contacts, that’s almost a year between freshening each contact. If you have 700 contacts, maybe commit to 2/day (or 1.9) if you don’t want to neglect anyone for more than a year. If you’re ok going a few years between freshening any given person, well, you can do the math. (Namely, dial the bright red line to $\frac{n}{d}$ where $n$ is how many contacts you have and $d$ is your preferred staleness cap in days.)

We’ve been evolving this system for three years now and hope others can get value out of it as well, or take inspiration from it. We’ll end with Beeminder superuser Lanthala’s description of her rolodex system, since it’s more normal-person-friendly and generally much simpler than ours:

I keep a spreadsheet called Friends & Contacts, where each person is a row. One of the columns is “last pinged”, and I usually keep the sheet sorted by that column so I can see who has been neglected. It is very low lift and high usefulness, especially for former work colleagues who I’d normally lose touch with. And I have a Beeminder goal to ping a person on my spreadsheet about once every 10 days, which keeps me checking the sheet.

Beeautiful!

Maximal Motivation At Minimal Cost: A Calculus Problem

dreev — Wed, 07 May 2025 00:00:00 GMT

The golden mean of Beeminder: If you never derail, dial up your bright red lines — if you’re derailing all the time, dial them down. Thanks to felixm and others in the forum for inspiring this post.

The previous blog post in our series on how derailing is good-actually (see the sidebar for a review) ended thusly:

The (meta) goal is to be pushed to do as much as possible — or whatever maximizes the motivational value you get from Beeminder — at minimal cost.

Shall we do math to that?

Backing up, we’ve been making a gradual shift in Beeminder philosophy from the early days. We used to lean in to the punishment framing, where pledge payments were penalties for falling short of your commitments and quantified how bad of a person you were. Just kidding. But we’re now pretty serious about treating it as the exact opposite of that. The pledges you commit towards your goals are helping you make progress on your goals, even when you pay them.

Sidebar: The “derailing is good-actually” series

“Bee Nice To Yourself” (2014) planted the seed for the rest of this list. It’s our cofounder, Bee, pointing out that treating oneself to a derailment now and then is ok. It even helps clarify the value you have for various behaviors. Bee asks herself, for example, “how much do I want to not go for a run right now?” If it’s less than $10, she’ll run. If it’s more, she’ll pay. And if she gets up to $90 at stake and still does’t want to go running, she’ll re-evaluate why she’s trying to get herself to run in the first place.
“Derailing Is Not Failing” (2019) argues that Beeminder revenue is proportiional to user-awesomeness — that pushing yourself hard enough that you sometimes derail is great for us and great for you. You don’t know how much more you could be accomplishing unless you sometimes find your limits!
“Paying Is Not Punishment” (2022) is a prelude to the subsequent announcement of No-Excuses Mode and advocates for a generally less excuse-making and more results-oriented mentality with Bee minder.
“Derailing It Is Nailing It” (2023) turns the concept up to eleven and gives it a positive spin.
“Beeminder As Your Personal Pigouvian Tax” (2024) argues for a reframing from a punitive to a taxing mindset, where you treat Beeminder’s stings as a behavior-shaping tax and accept that some derailments are inevitable. You can view that tax as the cost of the service Beeminder provides: nudges or rumble strips keeping you on track.
This post (2025) refines the derailing=good advice. The ideal amount to derail on Beeminder is not never and it’s not constantly. You don’t need to solve a calculus problem but do dial in the slope of your bright red line and your pledge cap to find your happy medium by feel.

Why not not maximal motivation at zero cost?

This is theoretically possible! Nick Winter advocates for it in his 2013 post, Spiraling Into Control. And see especially his classic book, The Motivation Hacker. We’re in awe of Nick but we don’t think this is sustainable (for anyone but Nick?). Or at least that it entails non-monetary costs, like stress and elaborate setup. Nick had to literally commit to writing a book about it to make that all work.

The extremes

If we don’t think the best of both worlds is realistic, how do we optimize this? Let’s first consider two extremes.

At one extreme is a total lack of ambition: A flat red line, no risk, no cost, nothing accomplished beyond what you would’ve accomplished with no Beeminder graph at all.

At the other extreme is maximal ambition: your red line is as steep as is humanly achievable, your pledge is at the edge of affordability, and so you get the maximum accomplished at high cost.

Neither of those sound great and they suggest a happy medium in which you accomplish a lot and derail sometimes but not too often.

So the final section of this post is just for fun. We don’t actually have to do math to this. In reality, you can and should dial in your sweet spot by feel. If you haven’t derailed a goal for months, make it a bit harder. If you’re derailing every week, ask yourself: is it that the goal is too hard, or is it too cheap to be motivating? Adjust the stakes or the steepness of the bright red line accordingly. If it’s stressing you out, drop the pledge and/or dial down the commitment. Maybe keep reassessing week by week.

The calculus problem

Ok, but pretend you’re a robot, or homo economicus, and can model everything about your life with a nice clean equation. (Even I wouldn’t actually do this; like I said, this is just for fun.) We’ll assume that:

$s$ is your stakes
$r$ is the daily rate of your bright red line — the amount of work you’ve committed to do per day
$R$ is the maximum possible value for $r$
$v$ is the value you get per unit of work accomplished
$u$ is the probability of an unavoidable derailment (we’re assuming No-Excuses Mode here)
$\lambda$ and $\alpha$ are tunable parameters determining how steeply your risk of derailing drops as your stakes ($s$) go up and how much it increases with your rate ($r$).

So we’re treating $v\cdot r$ as your total daily motivation, assuming you don’t derail. Next, assume your daily probability of avoidably derailing is (why not?) like so:

$$ d(r,s) = \left(\frac{r}{R}\right)^{\alpha} e^{-\lambda s}. $$

So your total probability of derailing is $d(r,s)+u$. Now we can work out your expected motivation per dollar:

$$\text{MP\$}(r,s)=\frac{\text{motivation gained}}{\text{dollars lost}}.$$

Which is:

$$ \frac{(1-d-u)\cdot v\cdot r}{(d+u)\cdot s}. $$

Inserting $d(r,s)$ and simplifying yields:

$$ -\frac{r v\left(\left(\frac{r}{R}\right)^\alpha+(u-1) e^{\lambda s}\right)}{s\left(\left(\frac{r}{R}\right)^\alpha+u e^{\lambda s}\right)}. $$

That’s strictly concave in $r$ if $0<\alpha<1$, so a unique interior maximum exists. Finally we’ve found our calculus problem! For given stakes, the rate that maximizes motivation per dollar is the one satisyfing

$$ \frac{\partial}{\partial r}\text{MP\$}(r,s)=0. $$

Differentiation, whee:

$$ -\frac{v \left((\alpha+2 u-1) e^{\lambda s}\left(\frac{r}{R}\right)^\alpha+\left(\frac{r}{R}\right)^{2\alpha}+(u-1)u e^{2 \lambda s}\right)}{s\left(\left(\frac{r}{R}\right)^\alpha+u e^{\lambda s}\right)^2} = 0. $$

And algebra, whee:

$$ r^{\ast}(s) = 2^{-1/\alpha} R \left(-e^{\lambda s}\left(\pm \sqrt{4 \alpha u+(\alpha-1)^2}+\alpha+2u-1\right)\right)^{\frac{1}{\alpha}}. $$

Here’s how it looks in Mathematica:

So there you have it, gruelingly Goldilocksed. Under a blizzard of contrived assumptions, you now know that when your stakes are at $90 you should dial your bright red line to 29.9% of the maximum you can do, in order to maximize motivation per dollar spent on derailments.

Beeminder ♥ Maayot

Maayot — Tue, 22 Apr 2025 00:00:00 GMT

We’re excited to officially announce our newest integration partner: Maayot! We’ve even got the Maayot folks here in their own words to tell you about it.

Want an extra push to stay consistent with your Chinese reading? We (Maayot) are thrilled to announce our new integration with Beeminder, a powerful tool that helps you stick to your goals using commitment pledges. You can now:

Track stories you read directly in Beeminder, and graph out your progress.
Set goals for yourself, such as to read your daily story, every day; or a couple of times a week.
Add real accountability with Beeminder’s pledge system to keep you motivated: Pledge a certain amount of money that will be debited by Beeminder if you don’t meet the commitment you set.

Keep your learning sharply on track and build lasting habits.

As a word of advice, if you find committing to a story a day too much, you can enter, for example, “5/7” in Beeminder to commit to read 5 stories a week.

Us bees chiming in again. If you’re sold, head to beeminder.com/new, pick the Maayot icon from the list of integrations, and follow the prompts to connect Beeminder to your Maayot account. Or, here, have a button:

小心蜜蜂

(See also the full documenation of the Maayot integration in our help docs.)

Image credit: The MET

Beeminder Blog

CGP Grey's Weekend Wednesday

Binge and Purge: A No-Good Very Bad Anti-Akrasia Strategy

Counterarguments

Lanthala Remains Unconvinced

Nathan Arthur with the Synthesis

Greppable Errors

A hierarchy of errors

Forster Lists: Or Mark Forster's Final Version

Quick Start

Quicker Start

Introduction

The FV Algorithm

A Longer Example

Additional Tips

Why It Works

Posthumous Postscript

Related Links

Coupled Sliders for Pledges and Pledge Caps

Wait, One Wee Weirdness

Akrasia Horizon Immunity: Or Getting Dark Green

Quick Review: Akrasia and the Akrasia Horizon

Beeminder ♥ BoardGameGeek

Um, I just wandered in from BGG; what is Beeminder?

The Sheeple Strategy

Generalizations

Related Concepts

Gresham's Law of Beeminder Deadlines: Or Death to Deadline Snoozing

“Noooooo, I am unmoved, you can take deadline snoozing from my cold, dead hands”

The real best of all worlds

Footnotes

Neology

Related Reading

Footnotes

Feature Announcement: Dashboard Hotkeys

Refetch

Super-collapse

Anything else?

Footnotes

Beeminder ♥ Steam: Announcing the Steam Autodata Integration

Detail-ey-doodles

Against Pseudovernacular Jargon

The Worst of All Worlds

Suitcases of knowledge

Footnotes

Call Them "Quals"

What about “Specs”?

Uphill battles

Footnotes

Writing About Writing: Highlights from Inkhaven

The Principle of Delayed Commitment

“People commonly overgeneralize the virtue of prudence and preparedness to cases where it’s blatantly irrational”

Toilet seat toggling

The kids’ carseats

Bridge crossing

Premature optimization

Pre- or over-planning

Lazy evaluation

Delaying those ticket purchases

Inkhaven

Goodharting?

DIY Inkhavens?

Footnotes

The Protein Dial

Nitty gritty

“When your [weight] is not near the bright red line then you just ignore all of this”

“Your total calories for the day, C, must always satisfy C ≤ 4P/D”

Couldn’t you game this by…

The Snackwell effect and the so-called Big Fat Lie

Trying this in real life

The Five Theses of Dials & Gauges

Protein in various foods and food-adjacent products

Related Reading

Footnotes

Feature Announcement: Tare Tags

Background

Quick version if you don’t want to learn any (more) new things

The wonderful generality (and explicitness)

“We’re relieved that you now have to be less of a supergenius to make Beeminder behave as you want it to”

Whittle-Down use case