It seems strange that if I choose to make my goal more difficult, that I can’t decided to make the change go into effect straight away, but have to wait a week.
If this feature was implemented then it would be easier to dial a goal in - first you start with something easy, then you make it harder as you get more data on what you can actually do, but you don’t have to wait a week between each adjustment (unless you overshoot, but then you only have to wait one week).
NO. Increasing difficulty should have the same waiting period as decreasing difficulty by default, almost all the time. If you allow for increasing the rate immediately, you introduce a bunch of potential problems. I don’t think it’s a good suggestion even for advanced users.
What if I increase the difficulty to impractical levels today, but after one day see that was completely dumb, even unfair? I’d then have to wait a week to reset the rate. Fixing exceptions puts too much burden on support supposed to distinguish this from weaseling. (They are already overwhelmed by my poor data entry habits!)
The current method for temporarily increasing difficulty, retroratcheting, avoids these problems. Since it cuts down on existing buffer, one is a good bit less likely to screw oneself over, except for goals that are very chunky/steppy. There is a big warning that says, “We will eat your buffer now!”
Why not a big warning for making goals harder now? I think most users like me are too damn biased to really extrapolate what a rate increase would look like over the next few days. With retroratcheting, it’s only going from not having to do anything right now to having to start doing stuff again sooner.
If you really want to increase your rate now–I think there’s a mathematically equivalent way of retroratcheting to simulate the rate increase until the actual YBR slope increase (or decrease for Do-Less) goes into effect.
Anyway, I vote against an instant-increase feature being anywhere near the default options. I think it would be a profitable addition if Beeminder decided to become really Evil.
That is indeed a valid concern that the button is dangerous, but at the same time how does me changing the work rate today be more dangerous than changing it a week from now?
Either way I have to wait a week to change it down again.
With a week delay I am tempted to dial the road harder, because otherwise it will take too long for me to find a good spot (I can only make one change a week) whereas if I can make another change a day from now I am probably not going to dial it so hard because if the cost of undershooting is so much less than the cost of overshooting.
If on January 1st I make the rate more difficult but then come to my senses and change it back on January 3rd, I’m only on the hook for two days of extra difficulty.
Days on the hook at a higher difficulty: January 8, January 9.
But on Jan 10, things will go back to normal. I have January 3 to January 8th to prepare for that extra burden. Maybe I can increase my efforts in those days in-between to compensate.
On January 1st I decide to make the goal more difficult, effective the next day, Jan 2nd. Early on Jan 2nd I decide this was a bad idea.
Sadly, I am on the hook at that higher difficulty for the following days: January 2, January 3, January 4, January 5, January 6, January 7, January 8. That’s many more days for something unforseen to screw me up.
And now I have zero days compensate for my mistake.
But you can make another change a day from now! Change on day 0 kicks in on day 7, then change on day 1 kicks in on day 8. The Akrasia Horizon is just a delay for your changes to take effect. It’s not a maximum quota on how often you can modify your YBR.
Or, if you know that it’s a delay and not a quota, are you really saying that the delay causes you to be more biased about how much you can do every day? You talk about how you’re okay with undershooting tomorrow–what makes that so different from undershooting starting a week from now?
I find part of that plausible, but I want to make sure we know where you’re coming from exactly.
Sure I could stack them, but there would be little point since what I really want to do would be to evaluate for a day and see whether the goal rate was tough enough, increase it to something I know I can do, then see if that is though enough.
Under your proposal if I find the fourth adjustment to be a bit too hard, I am fucked because tomorrow is going to be even worse.
Your point with only being on the hook for a few days means I have to cancel the tougher limit, before it goes into effect, meaning before I know how though it is going to be.
I don’t really see how you end up setting the risk of getting a goal set too high to be the same for both scenarios - in one case a goal undershoot has the same penalty as a goal undershoot and both cost a week, in the other case a goal undershoot is 1/7th of the price of an overshoot goal: which side are you going to error on?
You could argue that one could just work at the higher limit, build up a bit of safety buffer and then this discussion would be moot: my friend, if I that was how I worked I wouldn’t need beeminder in the first place.
I actually thought that retroratcething would apply the new rate immediately (if it’s harder than the previous rate) in addition to cutting down your buffer to at most two days. I just tried it, and I was wrong.
But maybe retroratching should work like that? Retroratcheting is already supposed to make a goal more dangerous by messing with the YBR, and users should already know to use it with caution.
I’ve been wondering and frustrated about this issue in the past too. Here are some of my thoughts:
Would it be an idea, to introduce an Undo feature? So if you made a mistake and noticed it in X hours, you could still revert and there would be no harm done.
I’m kind of afraid of the Retroratchet button. If it would leave me at the top edge of the YBR, it would be fine. But the middle is just too small a buffer to feel comfortable. And I’ve had multiple times, that I retroratcheted after inputting my data for the day, resulting in a minimal buffer the next day.
However, lately I started a new goal and I’ve found new ways to manage this problem. The last few days, I’ve had 7+ days of buffer. But instead of focusing on that, or retroratcheting, I am mostly looking at the turqoise swath at the moment, which does a good job of predicting your future progress once it has some datapoints. Right now, the rate of my goal is too shallow, so I’ve ranked it up a notch. When I see the turquoise swath and the YBR colliding, I know I’ve probably set my rate too steep; when they divert from each other, it’s too shallow. This way, I can safely experiment with finding a good rate, while still maintaining a healthy buffer.
Edit: Now that I think about it, the Take a break option might allow even more finegrained control. Have an especially productive day? I can schedule a bump in the road 7 days from now, while in the meantime I will have a bit more buffer.
Sorry we’re slow on this thread. This is all highly relevant to our generalized road dial, still in development. Stay tuned! And keep the ideas coming in the meantime!