If I derail due to a scheduled meeting or appointment or because of a sleep problem AND I get my daily requirement - 21 units of work (5.25 hours) - done by midnight, the derailment is not legit. (5/14/20)
I set it up this way because I want an earlier deadline, but there might be some days where I can’t get it done by then due to some prescheduled appointment, or have a sleep problem and need to adjust the deadline back to midnight.
I got flamed a lot for a similar - but more lenient - idea a while back, so I was wondering what people (e.g. @philip@phi@dreev@narthur@apolyton@zzq@alys@shanaqui) would think of this one. This is a little more stringent because it only applies under certain conditions.
Having a soft and a hard limit on anything is an extremely common practice. It is often done on project deadlines, it is done in quota management in operating systems, it’s even in sport (yellow and red cards in football )
I see no problem with it.
I haven’t done user support for Beeminder for quite some time so take this with a grain of salt, and it’s definitely not any sort of official comment!
It sounds like a way to take up support time that could otherwise be avoided. :-/ If it’s predictable that you’ll sometimes fail to meet the goal for those reasons, then the early deadline doesn’t sound suitable for this goal.
If I were doing this for myself, I’d have two goals. One would require maybe 4 or 4.5 hours per day with an early deadline, and the other would have the remaining time with a late deadline. It would force me to do the bulk of the work early, but give more leeway for the rest to account for appointments and sleep issues.
(At least that’s the simple version. What I’d probably do is have just one goal with a late deadline that I’d enter all the data into, and then a technological solution for populating a second goal with an early deadline with some or all of that data, probably with a setting that prevented any safety buffer being built up on the second goal.)
I’m afraid I’m one of the people who “flamed” you for your last attempt.
It’s bothered me ever since I realized just how unpredictable your schedule is to think of a way you could use Beeminder effectively. But I think the approach you’ve outlined a great start.
It avoids entering fake data. It gets support in the loop for accountability. The rules are clearly defined.
I’m inclined towards something like what Alys is suggesting, myself. I think that if the early deadline is something you’ll predictably have to miss, then I’d have the main goal with a late enough deadline that getting it done will always mean getting it done on time according to that deadline. Then I’d probably have a basic +1 goal that has an “OR” in the success conditions. (I’m really getting into these disjunctive success conditions, actually; let’s see if that sticks.) The second goal would be “Finished Goal_1 on time OR had a meeting OR derailed Goal_1”, for instance. That would be the one that keeps me on track time-wise, and the other would be the main one that collects the data. (That "OR derailed Goal_"1 part is to make sure that you don’t pay twice for derailing the same in-the-world goal.)
This way, your derailments aren’t exceptions (which can proliferate like nobody’s business when you have to decide about them on the spot); they’re pre-planed plan Bs that you can predict and set up contingencies for. The in-the-world goal itself can flexibly meet expected real-world contingencies, and the Beeminder goals can still be very bright-line-y.
I think that’s the general shape of the kind of thing I’d try for this.
a lot for a similar - but more lenient - idea a while back, so I was wondering what people (e.g. @philip @phi @dreev @narthur @apolyton @zzq @alys @shanaqui) would think of this one. This is a little more stringent because it only applies under certain conditions.
)