Navigating Tube Fares

A bit of an additional post for the week, as I’ve had a little bit more spare time! This post is a more fully-fleshed out response to a question my friend Andrea had, about the value of an annual travelcard.

I’ve started doing my preliminary accounts for 2016, and one of the things I examined was my transport expenditure. I typically try to use what’s known as zero-based budgeting (that is, each category and the value assigned to it is justified from fresh assumptions, rather than say raising the previous year’s data by RPI and calling it a day). Of course there’s some flexibility (I’m not going to pass up a social gathering just because of finances, unless it’s insanely expensive – which is unlikely given the background of my friends, or at least the activities we take part in together).

There’s a column of 86.50s, corresponding to a string of monthly zone 1-2 Travelcards purchased on student discount. We then have a crash to two low months as I was in the US and Singapore respectively, a figure just over 100 for November, and December looks to be closing around 50; I didn’t purchase any Travelcards after August. At the time, I made these decisions because I was unsure if going for the annual Travelcard was a reasonable idea, especially given that I would frequently not be in London owing to international travels, both for work and for personal affairs. The total cost for the category for the year was 894.68; this is lower than normal because I didn’t purchase any flights this year. I’ve been a bit cautious having been deployed internationally on quite a few occasions; I didn’t realise that you can refund the remaining value of a Travelcard!

This would have been 924 if I bought an annual zone 1-2 Travelcard (sadly, I’d now need 1,320 as I’m no longer a student); that said, with one I might have travelled more as well. Also, I was out for two months and started occasionally walking to the office in December. You can get refunds on the remaining value of a Travelcard – that said, I’m not sure repeatedly canceling and then repurchasing annual Travelcards is permissible, and it seems like it would certainly be inconvenient. Loss shouldn’t be too major of a concern, as Oyster cards can be registered to an online account which one can use to transfer a season pass away from a lost card. (I’ve done this before, though with a monthly pass.)

I think a question would then be as follows: exactly how frequently (in terms of number of days) do I need to use the Tube to make pay-as-you-go (PAYG)/monthly/annual Travelcards the best choice? We can examine that under a few assumptions:

  • The traveller is an adult.
  • All journeys are within Zone 1.
  • PAYG is implemented through contactless, so weekly caps apply.
  • The year begins on a Monday (this matters for weekly capping computations).
  • 16/7 trips per day (that’s reasonably realistic for me).
  • (Somewhat cheeky) If one travels for N days one travels for the first N days of the year.
  • Journeys on day are made between 0430 of D and 0430 of day D + 1.
  • The “greedy monthly flexible” (GMF) strategy works as follows:
    • It buys monthly travelcards as long as there are full months remaining.
    • For the partial month (if one exists), it uses the cheaper of:
      • a monthly travelcard
      • PAYG (with weekly capping)

Obviously GMF dominates a pure PAYG strategy, because for full months a monthly travelcard always beats PAYG (consider February), and for partial months GMF considers PAYG, so it does at least as well as PAYG. If I’m not wrong GMF is optimal under these contrived conditions: it intuitively seems difficult to recover from burning through February, the shortest month, without buying the monthly travelcard as you’d need four weekly ones. However, in the general case GMF is certainly not optimal (consider the period February 28 – March 31; you can buy the Travelcard on February 28, which expires March 27, and then pay for four days of fares, or pay February 28 and buy the Travelcard on March 1; the optimal strategy saves three days of fares).

The fare if one has to travel for N days is reflected in the graph below; and unsurprisingly the flexible methods are superior for small N but inferior for large N. Our model has a break-even point at about 314-315 days.

The final decision, unsurprisingly, boils down to the level of certainty you can have about your travels. If you don’t expect to be spending more than around 50 days outside of the UK, the annual travelcard seems like an idea worthy of consideration especially if you know when said days lie. That said, we have made two key assumptions, one of which favours the monthly strategy and one of which favours the annual one:

  • An upfront lump-sum payment is needed if you’re using the annual scheme. Our analysis did not account for the time value of money (you would need to discount the monthly payments to today to get a fairer comparison of the two).
  • However with the monthly strategy we’ve assumed that plans are known well in advance (at least a month) and implementation is done perfectly. In practice, there are likely to be some minor errors or plans not aligning neatly on month boundaries that will result in slightly higher fares.

I personally don’t expect to travel more than that, but I won’t be getting an annual card next year, for other reasons. (In particular, that “16/7 trips per day” assumption is unlikely to be valid, but that’s a subject for another post.)

Jeremy’s Annual Review 2016

As mentioned in a previous post, I’ve been using the system of objectives and key requirements (OKRs) to keep track of how I’ve been faring, looking at various metrics. I think OKRs do tell a significant part of the story, but they certainly don’t cover everything; a year is certainly long enough that things can change direction massively. There may be unexpected things that have come along for better or worse.

Why am I doing this? Reviews in general help me to reflect on the direction I’ve been taking, and allow me to consider how I should orient myself in the next period under consideration. I also find that being held publicly accountable is useful in spurring myself to perform better.

I’ll split this into three main sections: what went well, what did not go well and what major lessons were learnt. There’ll be another post to come concerning targets for the next year, though I’m sure some of the information here will feed back into that.

Things that went well:

  1. Academics at Imperial. There is still certainly room for improvement, but scoring 100 percent in the project and a 94.5 average for the final year blew even my best expectations away (95 and 92, respectively). I wasn’t too happy with some of the scores for the modules I took, but I think all things considered this was a very solid finish to four arduous years.
  2. Contracting at Palantir. I think working part-time as a software engineer during the term was great, though I realise the long hours (mainly because context switching became super expensive) had nontrivial costs. The main drivers behind this involved maintaining the currency of my skills as a developer as well as keeping in touch with the team at Palantir, and I think both ends were achieved here.
  3. Friendships. I was expecting the worst after we moved on from Imperial, but I’ve been keeping in touch with a fair few people. It hasn’t always been the easiest thing to do and it’s certainly caused me a lot of stress (unfortunately, it might have also had that effect on said friends), but I find maintaining good communication very worthwhile and I’m happy to have friends who also (at least seem to) believe this is important.
  4. Travels. I don’t mind a small amount of travel, but for various reasons was faced with a London – San Francisco – Palo Alto – Washington DC – New York – London – Singapore – London trip which ordinarily is more than I would like. Nonetheless I broke this down into small chunks and handled each leg of the journey smoothly. Besides the aforementioned trip I also had another visit to Palo Alto earlier in the year as well.
  5. Writing. I think at least over the past three months or so when I started here, I’ve been a lot more disciplined with sticking to a schedule and forcing myself to express my thoughts.

Things that didn’t go so well:

  1. Acquaintances. I’d have liked to keep in touch with more people from uni. I know this goes against the third point above, though that focuses more on the closest friends I had at Imperial whilst this focuses more on quantity.
  2. Working hours. Subsequent to a previous post where I explained how I tracked time at Imperial, there have been spikes above 80 and approaching 90 even, which is something I need to learn to control. I think I tend to have a very strong bias towards action, plus I do know that I can be very determined; but this can lead to such situations.
  3. Shifting standards / “the problem of never settling”. I find that I’m usually able to identify weaknesses and then address them (good), but there will always be more weaknesses to find, and a high quality bar very often has pretty heavy costs too. I’ll spend some time over the next two weeks to clear my head on this. As always there’s the flip side to this which probably leads to my current attitude, that settling for less-than-great performance isn’t ideal as well.
  4. Investments. I’m largely a defensive investor, as Benjamin Graham would call it. I invest every month when my paycheck comes in, and diversify into a portfolio of passive and active funds (this is needed in some cases, such as for access to small-value). Yet there were many occasions this year where the markets kept me up at night or had me worried, when they really shouldn’t. I have a tendency to be very aggressive with these (I bought in after Brexit; not so much after Trump since there wasn’t really a significant drop there once the markets opened).

Key lessons I learned (largely chronological):

  1. “It’s supposed to be hard. If it wasn’t hard, everyone would do it. It’s the hard that makes it great”. (You might recognise this as a quote from Tom Hanks’s A League Of Their Own.) I think I’ve generally liked to put myself through my paces, but this came out of the depths of working with MCMAS-Dynamic. In a way finishing that project gave me some kind of further validation that the 90%+ grades and the strong performance reviews I had were warranted. Sure, it can be painful, but the sense of accomplishment I often get when successfully pulling off something really difficult is great. And even at the end (before the grades) I was still concerned the project was not hard enough!
  2. Sometimes I need to take the first step. I’d say I learned this most clearly in what I call the post-Imperial crash period, when I started realising that a number of my friends would no longer be in London. I was somewhat concerned about how things would go from then on, and this caused me a fair bit of stress. I became considerably more proactive with many of them, and it seems things have worked out better than what I expected.
  3. “If you’re made to wait, it’s for your own good”. Performing high-quality work takes time. During MCMAS-Dynamic I found that after 8 hours or so per day I had difficulty maintaining my concentration; I thus switched my strategy from firing off those 11 or 12-hour days during the term that required comparatively less abstract reasoning to an 8 hour a day 7 day a week model. I was pretty drained out by the end, still. I’d be inclined to think that the pure technical difficulty of MCMAS-Dynamic is higher than anything I’ve had to face so far at Palantir, but I’ve similarly run into seeming brick walls with some of my work (though generally have not been implementing the 7 day a week thing). The quote above was introduced to me by a teammate who was concerned by the hours I’d been working; I think it was intended to be in an outgoing direction (that is, I might be making others wait for their own good), but it could also apply to some extent in the other way (that is, doubling down on effort in an attempt to rush something out is not always a good idea; being forced to slow down might be better).

The Problem of Never Settling

There’s still a little bit more of the year (I’d say we’re about 95 percent through). However we’re sufficiently far along that I think it’s time to take stock of what has happened so far, and evaluate what has happened.

Of course, this has been a year of shifting gears, at least in professional terms. At the turn of the year I was struggling with the Immerman-Szelepcsenyi theorem and how to write static analyzers; in the middle I tackled probably some of the most intellectually challenging work I have ever faced, dealt with leaving Imperial (in spite of the aforementioned challenges – there were other things), and set off around the globe. And now at the end I’m left thinking about how to best manage my time and energy across a seemingly unbounded spectrum of professional and personal responsibilities.

The continual pursuit of improvement, even if incremental, can be a great thing. It’s of course difficult to assign suitable metrics, but the mathematics of compounding makes a 0.5% daily improvement more than 5x if sustained over a year. Familiarity with, say, the Parable of the Talents (on being a good steward of what one has) drives the point home further – I’m thankful for the opportunities that I’ve been given so far, but that inevitably comes with some sense of responsibility, that said opportunities are suitably managed and capitalised upon.

An issue with that, then, is distinguishing what constitutes responsibility and what constitutes going beyond (the technical term, especially in a moral or ethical context, would be supererogation). For me at least, the standards I set are somewhat dynamic, and they’ll tend to rise further on strong performances or fall back on weaker ones (most obviously academic targets, also a couple of personal ones). I seek to make these standards difficult but achievable, for I find this spurs growth; yet, it’s way too easy to forget about that and then perceive missing a challenging target as a complete failure (when, actually, pursuing said target probably had a positive effect on the overall outcome, just that it set an anchor at an even higher point).

I tend to push hard to meet what I’ve set for myself. I have a practice of doing weekly reviews, and I think this increases my awareness of how I’m performing; I thus tend to put in a bit (or a lot) of extra effort if something doesn’t look like it’s tracking its target. However, as I’ve mentioned in previous posts, these standards can be and often are blunt instruments especially because they frequently are not entirely under my control.

There are two fairly well-known aphorisms that I find applicable to this – one that’s pretty general (perfect is the enemy of the good) and one more contemporary and specific to software engineering (launch and iterate). Indeed, these challenging targets can sometimes appear overwhelming, though generally I find myself able to focus on what I can do and proceed.

It’s important to keep a clear head through all of this, and taking a bit of time out over last weekend has helped. I think what I’m getting at here is that there can be a dark side to the pursuit of continual improvement, possibly because it leads to greater monitoring and self-accountability, and with some success that can lead to expectations being rapidly revised upwards (at least in my experience). In spite of that, I still believe it’s worth doing.

Stepping Back

I met up with a couple of my closest friends from uni over the weekend. At the end of what was a rather tough week (plugging away at debugging several issues regarding distributed systems) where everything seemed to center around getting a bunch of servers to behave as I wanted them to, it felt very different and somewhat refreshing to take a step back. I’m usually quite capable of focusing aggressively on a task at hand, which usually is good as far as said task is concerned but may not be optimal in general terms.

We played Loaded Questions, and one of the questions that came up was what we didn’t like about our professions. Being a bunch of Computing alumni, the set of answers was probably not too surprising:

  1. The salary.
  2. It’s difficult to measure performance.
  3. The algorithms are too complex.

I contributed #2 (though to be fair, thinking that I submitted either of the other answers is not entirely unreasonable – from an earlier post you can see that I investigated what looked like a 1 basis point shortfall in interest payments, and I just said that I had a tough week with debugging). Though I’ve tried to consider frameworks for evaluating this, I frequently find myself using outcomes and deliverables as primary measures of performance. This leads to me assessing myself based on my ability to get things done regardless of the costs or means required, and there are many factors beyond my control that can influence these.

I think this is a bigger issue when dealing with areas where I tend to believe I’m largely in control of the volume and quality of “output”, whatever that means. For example, as far as my investment portfolio is concerned, I tend to prefer to set goals along the lines of “set aside at least N for investment, incurring fees less than F” (largely controllable), rather than “portfolio net worth to be at least N” (I don’t believe I have the edge or insight to be able to be in control of such goals). I like to think software is a domain where I do exercise quite a bit of control over what I write, so it certainly is an issue in that sense.

In any case, I was happy to have had the opportunity to cool off a little. I think it’s a good thing that I can and do take my work pretty seriously (it has led to reasonably solid results in the past), even if it comes with the occasional tradeoff of getting excessively absorbed in it. On balance I think it’s a positive trait to have, but it’s important to remember that there are many things beyond whether an invariant holds in a bunch of servers.

Interest on the Interest

midpoints

I don’t remember the early years of my education that well. I do remember that maths was consistently my favourite subject back in primary school, though I wasn’t particularly good at it.

Anyway, it was around year 4 (so I was about 10 years old) when I started to take a bit more interest in personal finance. I’m not sure why this happened (I don’t remember young Jeremy being very interested in material things, and although the dot-com crash was in 2001 I’m not sure I knew about it at all back then!). I think at the time I viewed the stock market as very speculative (clearly hadn’t heard of mutual funds or ETFs); the childish me probably saw it as an “adult thing” to do as well (to be fair, if manually picking stocks that’s probably a reasonable view). I was thus more focused on what the older me would recognise as fixed-income investments.

However, in any case, I had saved some money from birthdays and the Lunar New Year, and given that I wasn’t going to be using it immediately I thought it would be good to put it to work. I was vaguely aware of how banks worked, at least as far as retail banking was concerned (i.e. the bank takes your deposit at rate x and lends out your money at y > x; the delta is for the service of matching depositors and borrowers). I was also aware of other schemes such as fixed deposits and other types of savings accounts. Interest rates at the time were about 2 to 3 percent, and knowing little else I thought that was not too bad for a start; my account at the time had an annual equivalent rate of 3%.

I remember looking through my bank statements then, and noticing that interest was paid twice a year, at the end of June and December. It didn’t take long for me to figure out that the December figure was bigger, at least partially because it was calculated including the interest from June. I then started wondering what would happen if the interest payments were made monthly, daily … or even billions of times per second. With some research I learned about continuous compounding; even if you were able to do this compounding at 3% infinitely often you’d still “only” get a rate of e^{0.03} - 1 = 0.0305 for your efforts.

However, the figures didn’t tally up with my calculations for a long while. I remember initially wondering why I wasn’t paid exactly 1.5% on each payment. Nevertheless, by then I had some familiarity with exponents, and I realised that 1.015^2 = 1.030025 > 1.03 and really we should be expecting \sqrt{1.03} - 1 = 0.01489 each time, rather than 1.5 percent. Still, this didn’t square up with the figures (it was getting down to cents, but still). I let the matter rest at the time, since it was broadly correct. Also, I noticed that the June payments tended to be a little small, the December payments a little too big – so I thought it averaged out in the end (which it did – that’s the point of an AER!).

Anyway, 15 years later I found the reason why, as part of prep work for a reading group I’m doing with Stan. I’m surprised I didn’t think about it back then especially given the observation about June and December payments (at the time, I made the oversimplifying abstraction that the payments were made “every six months”). The key is that the interest was calculated using what is known as an act/365 daycount which factors in the actual number of days for the period you were earning interest, and the first “half” of the year is shorter than the second “half”! Consider that in a non-leap year:

  • From 1 January to 30 June you have 3 \times 31 + 2 \times 30 + 28 = 181 days, but
  • From 1 July to 31 December you have 365 - 181 = 184 days!

With this, we can calculate how much should actually be paid each time. We need to solve

 \dfrac{181}{365} r + \dfrac{184}{365} r \left( 1 + \dfrac{181}{365} r \right) = 0.03 \leadsto r \approx 0.0297783

And so for the January-June period, on a $1 investment you would expect interest of

 \dfrac{181}{365} r \approx 0.0147668

which is notably less than the 0.01489 figure that we have treating each month to be the same length.

Note that a wide variety of daycount conventions are used, depending on which financial instruments are concerned! There is the 30/360 daycount, where every month is treated as 30 days and the year as having 360 days, which makes month-level abstractions valid but becomes unpleasant when you go below that; you also have the act/360 which like act/365 seems computationally nice. There’s also act/act (used for US treasury debt, notably), which guarantees identical value per day within a period at the expense of dealing annoyingly with leap years and/or the fact that the number of days in a year is odd, and many further variants of what I’ve discussed so far as well including a few particularly nasty ones that scale on business days as opposed to calendar days.

ScheduledExecutorServices

Scheduled Executor Service and Quota time chart

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.

Up All Night

“Knew we would crash at the speed that we were going
Didn’t care if the explosion ruined me…”
– Charlie Puth, “Dangerously”

The quote above is from a song that I’ve been listening to a fair bit recently, and I’ve picked up on those two lines although in a different context (as you might expect, the original song is concerned with a reaction to a breakup). I’ve been thinking about how my work practices could work in the longer term and what would be sustainable. Nonetheless, hearing those two lines makes me think of deep surges; some of the most short-term of these could perhaps take the form of all-nighters.

I’ve been fairly lucky in that I haven’t had to pull many all-nighters for quite some time. I think I only did this once for MCMAS-Dynamic (during the report-writing stage; generally given the technical complexity of the work I don’t think it would have made sense), and I don’t think I did one during the third year group project. I also remember having executed one during second year when revising for the exams, though that was thankfully well before said exam period. There have been several hackathons, of course, as well as other occasional personal surges but generally I find that I perform best if I have adequate sleep, and even in the relatively short run I’d be better off doing three say 15-hour days, punctuated by relatively normal sleep (well, as normal as that can be given such a schedule) than plugging away in a continuous stretch.

Anyway, besides the Charlie Puth song I’m also writing about this now because I voluntarily did one this week, though for a rather different reason: watching the US presidential election. I had a couple tabs open with various election newsfeeds and a couple watching market futures and GBPUSD. On hindsight I’m not sure exactly why I did it since it was pretty apparent midway through (I think around 2-3 am in London time) that things were going Trump’s way, and I wasn’t trading through the night (by the time markets opened in the morning there wasn’t too much of a cheap-buying opportunity). That’s a subject for another post, though.

I think the negative effects of sleep deprivation are well-documented; I’m not sure exactly why I pulled the all-nighter for the MCMAS-Dynamic report (probably wanted to rush something out for a supervisor meeting the next day), but I do distinctly remember that the two or three pages that I cranked out, while probably not bad per se fell particularly far short of my quality standards in a later proofread. The problem I’m trying to address with an all-nighter involves not having enough time to deal with a short-run (typically next-day) requirement, and in less extreme cases it’s not the only solution; where possible, I’d also like to try an alternative of waking up abnormally early to work on the issue. Understandably, there are risks that one might fail to actually wake up early, though I think this can be mitigated with suitable (read: loud and highly dissonant) alarms.

However, there are cases where I find this to be the best solution anyway. Some of this might involve external time constraints (for example, if it involves live following of current events – the aforementioned US election is one, or the recent World Series if one’s so inclined; examples from software engineering could include firing off long-running performance or integration tests, or meeting sudden customer requirements). Also, for suitably short time spans this is likely to be an optimal or near-optimal solution (even then, a 1.5 hour nap could potentially be useful in such cases). I think another useful factor to bear in mind would be the activities planned for next day (an exam or interview would be very bad, for instance).

Once the decision to forego sleep has been made, I usually don’t find the direct implementation of all-nighters to be too bad, perhaps because for things to have reached that point there must have been a compelling reason. Typically, by then the outcome-oriented side of me takes over and decides that it would be a night of crushing things (though it doesn’t always calculate the costs appropriately).

I think for me at least the most challenging part of this is managing its costs the next day. I personally don’t perform well if I haven’t had enough sleep, and there’s also a risk of overcorrection (that is, sleeping too early, which messes with the sleep schedule for the next few days). I guess caffeine can be deployed to some extent to address this, though I’ve been on the wrong side of that as well. I find that removing access to a bed at least until only a few hours before one’s normal bedtime can help as well – in fact, staying outside is probably even better (I can sleep on a chair if I’m at home).

In summary, it’s a very useful tool in my experience, and there are circumstances where it might be necessary or optimal, but generally speaking where possible this should be avoided.

Tracking Times at Imperial

Graph of my work time at Imperial

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.

Charting Courses

I had lunch at Nando’s with a friend 2 days ago, and I mentioned that I had been doing my planning for the month of November before said lunch. We had a brief discussion concerning the scope and methodology behind this, and I thought it might be interesting to share how I approach it. I’ve been iterating on this approach since starting fourth year at Imperial. I figured explicit planning was important for two reasons:

  1. I had a lot more flexibility as to how I could schedule my time, with projects spanning multiple terms, and
  2. I had more on my plate as well, having to manage 2 part-time jobs and my own personal development in parallel.

Now that I’ve graduated from Imperial, I find this is arguably even more important:

  1. There isn’t even a “term” unit now. I might have to answer questions, do emergency investigations/dev work, and even be an SME about things I implemented on previous projects. (Though that’s validation that my code’s still in production!)
  2. Personal development is still an issue, and there might be even less of an obvious driver or reminder that it’s important (the part-time jobs introduced weekly quotas and scheduling, in a way).

I have tried to be careful to avoid excessive planning for quite a fair bit of time, mainly because I want to maintain some degree of flexibility and also because it’s difficult for me to measure how long certain tasks will take (especially creative tasks; cue Hofstadter’s law). I thus don’t view the plans as absolutely prescriptive and dynamically redraft them as needed.

Typically, I have an annual planning exercise, which largely involves developing objectives and key requirements for the year across various domains, both professional and otherwise. This has been in place since year 2 at Imperial, actually, and was typically written at the start of the academic year, though I plan to realign it with the calendar year starting from 2017. Here’s an excerpt from what I wrote at the beginning of year 4 (note that there were more objectives as well as more subgoals within each objective):

  1. To be an accomplished student for my final year at Imperial.
    1. Obtain a solid overall average for the fourth year at Imperial. The score is measured by linear interpolation with 84 as 0.0, and 94 as 1.0. (So 0.7 is 91.)
    2. Complete a strong final individual project. 85 is 0.0, and 100 is 1.0. (So 0.7 is 95.5.)
    3. Successfully train a group of PMT students to develop aptitude and, hopefully, interest for the subject. Measurement involves giving the students a feedback form at the end of term 2, asking them to rate the sessions for quality on a 7-point scale. 3.5 is 0.0 and 6.5 is 1.0.
    4. Challenge said group of PMT students. The survey should ask how difficult the sessions were, again on a 7-point scale. 4 is not good (the sessions should challenge them). In fact I’d target 5.25 as an average, for 1.0. 4.0/6.5 would be 0.0.
  2. To manage one’s finances in a coordinated and efficient way.
    1. Max out my Stocks and Shares ISA for the 2017 tax year. 9,000 is 0.0, and 15,240 is 1.0 (obviously). This is allowed to wait for my start at Palantir.
    2. Earn a sufficient income from part-time work over the course of the academic year. 2,000 is 0.0, and 10,000 is 1.0.
    3. Read books concerning finance and financial management from (a reading list I defined at that time), with extensions allowed should I find other quality texts along the way. 0 would be 0; 9 would be 1.0.

The next finer-grained level of planning would be academic terms, which corresponds to quarters in the post-Imperial world. I think I started this from year 3. (I treat the summer holiday as Term 4/Q4, and would do planning for what I wanted to achieve during those as well.) This would include slightly more information about what I planned to do, though it would still be at a very high level (no/minor concrete action planned). I normally didn’t do any planning beyond that.

For monthly planning, there is some degree of executive function that’s involved. I block out time for certain time-inflexible important events or things I need to do, where feasible (for example, making sure to attend the BCS award presentation ceremony, or the graduation at Imperial). It’s also a good time to pencil in anything that should be done monthly, even if it’s not necessarily the case that it’s time to do it. For example, in the absence of shock events I typically have a look at my investment portfolio once a month on the day after payday – this is used to make potential movements and have a quick look as to whether there’s anything in particular I need to position myself for (for example, getting a chunk ready to toss at the market in the wake of the Brexit referendum; similarly, I’m keeping an eye out for November 8th this month).

I also review the quotas that I’ve set – that is, things which I set out to do N times every time interval T (thanks to John Sonmez’s book for the word). Some of these involve meeting or talking to certain people whom I value highly and wouldn’t get to see otherwise (>50% of the guys I regularly talk to are not or no longer based in London or the UK for that matter); others involve financial planning, or personal learning and development objectives.

It’s also a good time to reflect on how things have gone in the previous month, and whether my OKRs and things I’ve wanted to get done for the quarter are tracking or not – and possibly to react to these should things not be going well and/or be overheating (as tempting as it is for me to try and run my winners, in some sense). In any case, I find allocating a decent chunk of time to plan this out (usually around 90 minutes) useful for helping me to decide what to allocate the rest of my time for the month towards, without imposing an excessive overhead (that I suspect would otherwise be amortised over the course of the month anyway). I’ve found it to be a useful exercise, though of course its applicability will depend on the individual.

New Home

I thought I’d establish a little corner of the Internet to document some of my work, as well as my individual profile. The site’s still under construction – watch this space for updates.