I briefly touched on this in my first post, but I find that there are quite a few things which I aim to carry out (at least / at most) N times per time interval T. This is described by John Sonmez in Soft Skills as a quota. You may have been able to infer this from the frequency of posts here – I’ve been aiming to write at least 1 blog post per week.

On another note, scheduled executor services are a part of the Java concurrency libraries (introduced in Java 5). They allow clients to submit one-shot tasks wrapped in callables (possibly with some delay before execution), as well as tasks with a fixed rate (more similar to a quota, though not quite – mainly because quotas are concerned with getting things done, while executor services are concerned with enabling tasks to run; also because a scheduled executor service won’t start concurrent tasks). Clients can also specify tasks with a fixed delay; this differs from a fixed rate in that the countdown to the next execution starts after the current task has completed.

If one assumes that the tasks complete relatively quickly, then quotas are, in a way, less restrictive than scheduled executor services; they give flexibility as to when in the time period T the N events occur. This is especially important for tasks that require 2-way synchronization (for me, that largely involves spending time with friends) – it would be even more so for barriers involving multiple people though I haven’t actually planned any such arrangements.

A downside of this is that it delays the decision of deciding when in each period T the events should be scheduled; it’s arguably simpler to schedule them at the same point in each period. Also, if one follows the letter of the quota, then this can lead to very uneven intervals between occurrences – for syncing up with friends, blog posts and quite a few other things, while this certainly isn’t bad it’s also less than ideal (imagine if I had a “weekly sync” with a friend, but actually spoke to them once every 2 weeks at 23.35 on Sunday for 20 minutes, and then again at 00.05 on Monday for 20 minutes). I find that a good way around this is to normally target the same point, but allow for flexibility; I’m not sure you can readily do this in ScheduledExecutorService (you’d have to cancel the old task and reschedule a new one with the correct delay, I think).

The diagram above more succinctly illustrates the difference between the timing semantics for the various things I’ve described. More often than not, at least for meeting up and/or syncing with people, the pattern is closer to the second or fourth above (i.e. with random variation, plus the occasional additional occurrence; perhaps the occasional missed occurrence as well, though I didn’t include that in the diagram).

Another way I’ve modeled this in the past is on the concept of a failure detector in distributed systems. Servers/subsystems can arrange periodic heartbeats, suspecting them of failure if a heartbeat is not received (and “un-suspecting” them if one is subsequently received). Though because of the aforementioned flexibility, a pattern that conforms to a quota could result in a heartbeat interval of 2T. I guess the idea I had previously was I didn’t want to lose contact with friends, bearing in mind that I was still in Imperial at that time and thus would quite naturally and easily meet many of my friends in lectures or in labs – on the other hand, I’m the only person from my class to go to Palantir (at least at this point). I find using a system based on quotas is certainly much easier for me to manage, as well.

The graph you see above reflects the number of hours I spent on “work” each week, from the week starting 5th October 2015 (I finished my internship at Palantir on the 2nd of October) up to the week starting 5th September 2016 (I started full-time at Palantir on the 12th). Obviously, this includes all time spent explicitly on academic work, at Palantir (social events do not count) as well as time spent tutoring (inclusive of marking and preparing the problem sheets). There’s more to it, though – I place work in quotation marks, as there are quite a number of activities that people might not classify as work that I do count towards the total, such as having 1:1 syncs with people and personal reviews.

I’ve annotated the significant peaks and troughs on the graph with some of the events that had taken place around then that contributed to why I worked so much (or so little). You’ll see that I’ve shaded the part of the graph above 70 on the y-axis in red; for me at least, I think I instinctively start feeling some degree of push-back at that point (and I’ve been cautioned that 70 is already pretty far on this).

Typically, when I look at a graph, I try and identify things that I find to stand out as unusual, and then seek explanation for them. Initially, what does stand out to me is the relative lack of height of the peak labelled (6), the weeks leading up to the end of the Final Project; I would have expected something quite a bit more. I’d attribute this to the sheer cognitive difficulty of the final stages of said project; I remember finding that I would be drained very, very quickly when working on it. I guess for the final project I worked at it pretty consistently over the year, so there was no need for a massive surge at the end as well.

I notice extremely sharp drop-offs (A) and (B) after the end of term 1 and 2, yet no such drop-off exists after term 3. Perhaps, this is a signal that the 58.95 or 61.25 averages in those terms are too harsh (summer term was a relatively tame 52.33), and this does already factor in exam week or week 11, which tends to be less intense as I need to conserve my energy for the examinations themselves. I tend to think of week 8 or 9 as the busiest week in each term, owing to exam revision, and this pattern is reflected in peak (5), but seems absent in term 1 which, in fact, exhibits a convex sequence. This might feed back into the earlier point about considering 70 hours a week as a dangerous point to be insufficiently prudent; there is a crash even after a series of weeks in the 60s.

Although I recompiled this graph recently, I first performed the labelling in September just before I started at Palantir. Nonetheless, looking back at it about two months later, one of the labels stands out to me, that being (A) perhaps because in and of itself it does not seem to give a proper explanation of why the trough (or peak, in the other cases) was there. I did return to Singapore to spend time with my family and a few friends, but it wasn’t really the case that I did very much on that front – in fact, a fair chunk of my time in Singapore went towards MCMAS* (which explains that mid-50 spike, which is actually the week starting 28th December) and Fallout 4 (which, of course, did not count).

It’s heartening for me at least to see that I have a fair degree of intrinsic motivation, as shown by the red line. Over the roughly two months, I managed to work on MCMAS-Dynamic, program extensions for Keep Talking and Nobody Explodes (and, in doing so, revisit programming in C#), set up this website, complete a full retrospective round of the first and second year examinations and learn more about personal finance and investment.

Clearly, the data may be analysed as a time series; in fact, I have bucketed this graph into weekly aggregates, but I do have data down to a daily granularity. An alternative way of handling the daily data could have been to compute a simple or exponential moving average of the data, though I don’t really like doing this at a daily granularity is because of very clear seasonality (in particular, I tend to work the most on Tuesdays, or Wednesdays part-time at Palantir; I work the least on Thursdays and Sundays).

I only did this in year 4; it would be interesting to see how the time profile would have looked like in previous years and how similar it might have been, though the different structure of each academic year would probably have made the series look somewhat different (for example, the beginning of the third term in year 3, very near the (B) trough, would have been a very high peak as I aggressively ramped up for the industrial placement at Palantir).

This was a rather interesting exercise, even without looking into the distribution of time across modules and/or activities. If that is factored in, there are other interesting patterns; for example, the amount of time spent on MCMAS, which involved considerable surges after each set of exams was dealt with, and the time spent on 1:1s and syncs, which was generally a few hours per week but had a 12.5 blip in the final week of the summer term (before people dispersed) and a 10 somewhere later on (maximum likelihood guess would be meeting three of the guys I regularly sync with nowadays for meals on three distinct occasions).

I haven’t been doing this as rigorously ever since I started at Palantir, mainly because the initial impetus behind this initiative was actually understanding which modules I was spending a disproportionate amount of time on (Computing for Optimal Decisions, Software Reliability), and also because I had ready access to my personal email accounts (I tracked the data using Google Calendar); also, my work is far more reactive to changes that may happen because some high-priority issue appeared. Perhaps using it for spare time could be useful, but then the administrative overhead is much larger relative to the time actually being tracked – to a point where I’m not sure it’s worthwhile.