I will try something weird.
Background
I have many time-tracking goals using toggl—do more, X minutes/day. I am generally glad I have these goals, but one negative side effect is that when I am edge-skating, they tend to promote spreading my time thinner than is optimal—if my work goals for all 3 ongoing projects + my two hobby goals are all in the red, I basically end up having to do all the things today, when it would probably be better to focus on fewer things.
Thus, I would like a goal that explicitly requires me to spread the day over fewer things.
The quantification
For a categorical random variable, something like “variance” is ill-defined. Instead, the standard notion of “how spread out” a categorical variable is is the entropy
S = - \sum_{i} p_i \ln{p_i} \geq 0.
We may adapt this idea to define a daily “entropy” of time spent. If a fraction f of our time (i.e. 24 hours) is spent on each task i=1,2, 3, ..., as S = - \sum_{i} f_i \ln{f_i}.
The point of this quantity is that it generally measures how “spread out” my time is. For example, if I do 6 things in a given day, then S is highest if I spend the same 4 hours on each of them, and lower if I focus on one and only spend a bit of time on the other 5. Similarly, if I spread my time evenly between N activities, then making N higher makes S higher.
The goal
Thus, we make a do-less goal on this “entropy of time spent”. Each “project” in toggl counts as a separate activity. If I have time where I do not record any data in toggl, I will treat that time as split into unique 30-minute activities, which should act as a penalty for not tracking time.
Possible objections
Doesn’t this require you to track almost all your time?
Yeah, I don’t consider this a deal-breaker.
Since entropy increases when you increase the resolution with which variables are defined, doesn’t this disincentivize making more precise toggl projects?
Yes, but that’s effectively a bad incentive that acts on the other side of the akrasia horizon, so I don’t think it’s too big a deal.
Aren’t most of the properties that make entropy useful irrelevant here? So, for example, there is no reason to favour S over any monotonic function f(S)?
Yes.
But I think S grows at roughly the right rate. For example, if I decide to set the rate so that an “acceptable” day was 8 hours sleep, 3 hours each on 5 activity, 1 hour on a 7th, that would be S=1.8-ish. My “no data” day, with the assumption that no data = a bunch of half-hour activities, would give S=3.9-ish, or closer to 3 if I at least logged sleep. So just using S roughly satisfies the principle that a bad day should be about two acceptable days used by the PPR system.
Isn’t it stupid to count sleep?
Maybe, I dunno.
Won’t it be insanely hard to build buffer?
Yeah, kind of. The only way to get 0 for a day would be to sleep all day. Getting even a half-day of buffer in a single day would require something like spending all of my waking hours on only two activities. But who knows, maybe it would be good to sometimes spend a day doing something like that.
Worst case, I will consider replacing S with f(S) for some f that changes rapidly at small values of S and becomes linear for large S, to allow for days with datapoints closer to 0. Or stop counting sleep…
In conclusion
So yeah, I’ll start this goal with a slope of 2.5 nats/day.*
The only issue is coding the script. Unless I make beeminder goals for all of my toggl projects (which would be nuts) in order to use my existing machinery, I’m going to have to learn to use the toggl API. It shouldn’t be too hard…
*Entropy/information sort of has units, because if you change the base of the logarithm it changes the number by a constant factor. Entropies computed with base-2 logarithms are in units of “bits”, and if the natural logarithm is used, “nats”.