I’ve started using stochastic time tracking, and have a couple of questions:
How do you manage minding time on activities that you do infrequently and/or for very short periods of time? It seems like it would be super hard for TagTime to notice that you’ve done it at all.
I remember seeing somewhere that since, unlike @dreev, @bee doesn’t like edge skating, she has some system set up to ensure she has enough buffer on TagTime goals to prevent her from derailing due to randomness. How is that buffer calculated and enforced?
@zedmango For some reason TagTime doesn’t work with my Beeminder account, so I built my own solution using Android Automate. So far the tags I’m using:
one tag for each of my major work responsibilities
Yeah, that problem I just live with. You need to accumulate hours of time doing something before TagTime’s estimate means much. But give it long enough and that will happen.
(Apparently I’ve averaged 6 minutes a day answering TagTime pings since I first thought to use a tag for that 9 years ago. That should be a pretty tight estimate since it’s based on a total of 439 pings or 329 cumulative hours of ping-answering! I think @bee’s TagTime overhead time is much less since her ontology is simpler and she I don’t think she often refactors old tags or cleans up possible errors and stuff.)
@bee’s solution is just to have a tocks goal that’s a little steeper than her tagtime-based hours goal. I can confirm that having emergency pings, as we call them, is very stressful. For me that’s wonderful. It creates a huge amount of focus and productivity. Also I kind of love watching the probability of surviving the beemergency tick down at http://mind.tagti.me
How does accruing time on something over a long period of time help with minding the estimates? Maybe I’ve implemented the algorithm wrong, but my implementation is memory-less outside of the present day. Are you minding the global average, or just the estimated time spent in the current day?
Oh, it doesn’t help with beeminding it! Sorry, I was answering the wrong question there. So, yeah, I don’t think it works to beemind something with TagTime as the data source unless it’s something that you’re ok being forced to spend hours at a time on.
The cumulative total number of hours, where each ping counts as 0.75 hours.
Couldn’t you just give yourself a large buffer and then you could beemind it with TagTime since the buffer would give the randomness enough time to work?
As a side note, TagTime seems interesting, but using it as a data source would be very unsatisfying for me - a big part of using Beeminder for me is the “check off the box; cross it off the list” feeling of satisfaction when I do something and enter data.
I think that’s incompatible with edge-skating. If you need to do something for 5 minutes a day then you’d need to get really serious about putting in those 5 minutes for weeks ahead of the actual beemergency. Generally you should be prepared for up to 4 or so hours of work for a single ping, in case you’re unlucky and have ping drought. There’s a table with confidence intervals at the bottom of http://mind.tagti.me
I implemented my own algo without really understanding how TagTime did it. So mine calculates the time I may have spent on a given tag for the current day and posts that. Roughly:
That is, percentage of today’s pings with tag X multiplied by the amount of time elapsed today. And this is calculate for every tag on every ping, regardless of whether or not it was selected.
I’m sure this is probably worse than what TagTime is doing in some fundamental ways. But other than complexity I’m having a hard time figuring out how.
What’s your actual algorithm for when to ping next? I have so many opinions about this! I think your pings/total_pings formula can also be improved but it might depend how you implemented the ping distribution.
Either way, I think it’s better (or no worse? I’m not sure) to estimate time spent as simply 45 minutes (or 50 in your case) times the number of pings you got, without caring about when the day started or how many total pings happened.
Yeah, seems like the most efficient work schedule using @narthur’s system would be to only work for the few seconds around each potential ping - so like 11:59:55 - 12:00:05, then 12:04:55 - 12:05:05, and so on.
That would give you the exact same time logged by the pings, with only 1/30 the amount of work, making you 30 times more efficient!
Here’s an extreme example illustrating how your formula can bias your statistics:
Imagine there’s an uncanny ping drought. Nary a ping all day and the end of the workday is approaching. If you can get the next ping then you’ll have gotten 100% of today’s pings! So you buckle down and work with laser focus for the last hour and probably that ping is yours. Your formula now says you work 8 hours today.
Of course my version can be just as wrong (you could happened to get pinged 10 times in an hour) but the difference is there’s no bias. With your formula you can adjust how hard you work depending on the ping history.
It’s not nearly as big a loophole as @zedmango’s (work for a few seconds every 5 minutes) but if you tend to focus more the fewer pings have happened – a natural enough thing to do – then your estimate will be inflated.
Using the official TagTime algorithm and counting every ping as exactly 45 minutes of work makes it totally ungameable.
Say I switch to setting the datapoint values all the same. What if, whenever I get pinged, the flow set a timer randomly between 1 second and 1.5 hours, and then pinged me again at that time? It would be just as random, and still work out to a value of 45 minutes per ping, yes? But it would eliminate the possibility of ping droughts.
interval?
