Beeminding work from a queue

I have a queue at work that is sometimes empty and sometimes very full. It fills up at wildly different rates throughout the year; there is no limit on how large it can get when we’re busy, or on how many weeks in a row it can stand empty when we’re not; and similarly, what counts as a reasonable turnaround time on an individual queue item varies dramatically depending on what time of year it is.

My tendency is to ignore my queue when it’s only a little full, and then to panic and binge-work when it’s very full. My goal is to be more consistent about working slowly-but-steadily at my queue any time it’s got anything in it.

If I just set my beeminder goal to “clear X things from my queue a week,” or “spend X hours a week working on my queue,” I will automatically fail at times when the queue is empty. And if I set my beeminder goal to “keep queue under X length” or “attend to queue items within X days,” I will automatically fail at times when the queue spends weeks or months filling up faster than any human could empty it.

What might be a better metric to use for this?

(I suppose I could do something like “clear k items from my queue every day, where k is the lesser of X or the queue size at the start of the day,” but I don’t feel great about having a goal with subclauses like that. Is that an aversion I should get over?)

3 Likes

I believe in cultivating that aversion! :slight_smile: It’s part of the QS First principle.

Is there a natural generalization/expansion of “working on the queue” that could include work that makes sense to do when the queue is empty. Like “working through queue or improving queue infrastructure” or something?

A pie-in-the-sky long-term answer could be something like automatic triggers that can instantly flatten a yellow brick road. So as soon as the queue is empty there’s a break in the road. Another example of where this could be nice: “bike/skate 5 miles per day that it’s sunny” and then use a weather API to add flat spots to the yellow brick road whenever it rains.

I don’t know how to implement that in a non-abusable way yet but I bet it’s possible! But, again, current Beeminder doesn’t support that.

So the answers I can think of so far are:

  1. generalizing “work on queue” to include something you can do when it’s empty
  2. subclauses to make a +1 mean “worked on queue or the queue was empty”
  3. reply to legit checks that the queue was empty so you couldn’t do the thing
1 Like

Personally I think the subclause idea sounds totally reasonable and not problematic at all: it’s straightforward, intuitive, and impossible to weasel, and it solves the problem at hand perfectly.

1 Like

All true, but it makes the graph be wrong! And having it feel aversive that the graph be wrong is a common weasel prophylactic.

Of course we could quibble about what “wrong” means here. My claim is that a Beeminder graph with subclauses doesn’t let you glean interesting facts and insights about, in @leahvelleman’s case for example, things like number of queue items processed per week on average. Or whatever other metrics may be relevant to the actual work and not just the commitment device.

Ideally you want a graph of a fundamental metric and then find a way to beemind that. Both the commitment device and the graph are important. Contort the yellow brick road however you like for the commitment device to make sense, but don’t contort the underlying data.

To be clear, many hardcore Beeminder users totally disagree with me on this. I think there are two legitimate schools of thought on it.

See, to me it doesn’t make the graph be wrong at all! It still marks all the days when you’ve done the required minimum amount of queue work, which is what it’s supposed to track. Tracking “number of queue items per week” is interesting, but an entirely different set of data, and not one that would be useful here, given that THAT metric isn’t under @leahvelleman’s control.

Myself, I have a VERY effective beeminder goal – possibly my most useful one – of “do everything on my daily to-do list”, and I sure as heck consider it successfully completed on days I have nothing on my to-do list! It’d be darn silly to judge it otherwise, imo. I could, like @leahvelleman, track “number of items on my to-do list done”, but that would, again, be a completely different metric, and not nearly as helpful, motivating, or flexible for me.

(But then, my alignment is Lawful Neutral, so I’m extremely unlikely to weasel regardless of setup; making my goals weasel-proof has never been an issue for me.)

2 Likes

I think this type of use case is very common, and that Beeminder doesn’t do a great job of supporting it right now.

A power-user way of sort of simulating this might be to use aggday = count and have a personal rule that every data point is either 1 or 0, with 0s only allowed if the queue is empty, and only enough of them to barely avoid derailing. Though then your graph doesn’t mean much either, but at least your data does…

2 Likes

That’s roughly what we do with beeminding the support queue…

There’s something that I do with my emails that might work for you if a) you’re fairly good at assigning a reasonable (not too much, not too little) amount of work to yourself the day before the work has to be done and b) there’s a way to flag/star/mark certain cue items.

I have a goal called “Starred” for starred emails. At the end of the day (which is past the Beeminder deadline for the goal), I go through my inbox and star emails that I want to work on by the deadline tomorrow. Each starred email is a +1 in my Starred goal, and then, on the day of, I go through and handle them and put a -1 datapoint for each once it’s been handled. The road rate is 0, so I have to come back to zero by the deadline by handling anything I starred the day before (and anything I star on the same day, which I occasionally do to force a quick turnaround on some emails).

I don’t know if that would be helpful for you, but it was helpful for me in the past, which is why I just restarted it a couple of days ago.

3 Likes