The more I’ve delved into the darkest corners of optimizing compilers, the more that incessant urge to optimize things has leeched out into my day to day life. I’ve found myself ever more obsessed over what the most optimal method to do things is. A few examples:

  • While brushing my teeth twice a day I know I have a full two minutes where I can make use of my spare hand to do things. Like I might pack the dishwasher, lock the doors, turn off lights, put stuff into the recycling - anything that means I’ve double buffered another activity while I’m stuck brushing.
  • I got really obsessed with the number of trips from the dishwasher to put things away, versus the time taken to load up on extra dishes for a lower number of trips. I kid you not I’ve experimented and mostly realised that (if optimizing for time taken as your primary metric) the number of trips is much less important than the time taken to load/unload dishes in an individual trip.

One other area of my life where I’ve adopted this philosophy is the structure of my workday. I thought it might be interesting for people to see if there is any tips in how I lay out my day that they could adopt to optimize their own experiences also.

Booting Up⌗

The first step in any day is the process of booting up. I follow the same routine each morning:

  • I wake up.
  • I use the facilities.
  • I weigh myself.
  • I take my dog outside so he can relieve himself.
  • I put on my running gear.
  • I make a coffee. Caffeinated. I only have a single with-caffeine coffee each day as I’ve experimented and found it to be the optimal balance of getting that ‘wake up’ feeling versus the affect it can have on sleeping at the other end of the day.

Once I’ve performed these most basic tasks in a mostly pre-coffee zombie state, I’m ready to load up on the problems of the day.

Dealing with the Urgents⌗

Once I’m at the computer I do a full parse of slack / work email, answering any of the easy questions and dealing with the easier tasks.

Then I tend to filter through to see if there are any urgent bugs that I need to take care of. These bugs are generally of the ‘stop the world’ kind - EG. I’d only drop whatever main feature I’m working on for a bug if it is truly some sort of regression / ship stopper. My number one aim for any of these bugs is to reproduce them (not always easy) and then give the user a temporary workaround.

Because of the natural cadence of software releases it means that even if I rush to fix a users issue, there is still some time lag between me fixing it and them being able to get access to that fix (while everything is tested for release). Workarounds are a key part to unblock a user while the real fix is deployed.

Urgent Bug or Feature⌗

Once I’ve loaded up on a specific urgent bug to fix, or a feature I am developing, I spend thirty minutes or so acclimatizing myself to the issue.

If it’s a bug - can I reproduce it? Can I check our logs? Can I use a debug build of our Burst compiler to give me more information? Generally at this stage I’m only trying to work out what is the cause not what the fix is.

If it’s a feature - I’m just paging back in what I was doing the day before and trying to get started up again. I have long followed a philosophy of lacing #error’s throughout my code before I leave it for the night so that the next day it won’t compile but I’ve left some breadcrumbs for where my thinking was the night before. Again - all I’m trying to do here is page back in all the problems I was trying to solve at this stage, not do any actual work.

Run Run Run⌗

Then I go for a run. I grab my dog (he runs with me every day!) grab my headphones, and listen to any of my favourite podcasts while I’m exercising. I do at least a three mile run every day, and try to run at least thirty miles a week. What is important at this stage is to get into the monotony of the exercise, don’t think about work, enjoy the podcast and get a sweat on.

Benji and myself running

There is now a pretty hefty set of scientific evidence that states that the right kind of distraction from a problem actually helps you solve it (for instance here is a BBC article about just that. The TL;DR is that as long as you have some monotonous task like sorting things (sorting lego blocks by colour, putting the dishes away, hanging out washing on a washing line, etc) or more broadly where your brain can mostly power off from any in-focus intensive task, your brain kicks off an asynchronous process in your head to actually solve the problem while you are doing the thing. This is why you hear so many stories of people solving problems in the shower, or waking up with a solution - you are using the same technique.

I’ve found myself that by loading up on the problems and then immediately context switching to exercise, I generally solve them better and faster. I could sit at the screen for hours and get no-where, or I could go for an hour run and solve it in the thirty or so minutes after I sit back down. Nearly every time I engage the crunch like behaviour of trying to power through to a solution it sets me back on actually solving it - so this technique is something I’d definitely recommend trying.

The Rest of My Day⌗

I get about four or five good hours in a day of active problem solving coding. It might be more or less for other people, but aslong as I can get some peace, have my favourite music blaring, and can distract myself occassionally to make a decaf coffee or throw the frisbee to Benji, I’ll get a solid block of good work done in an average day.

Benji with a frisbee in his mouth

Since the my team is split mostly between EU / US, I generally have most of my big meetings in my afternoon. So by that time I’m already pretty tired from the solid work block, and ready to engage in the meeting instead.

When I’m done for the night? I’m done. I work my eight hours a day, and walk away from the machine. I like to cook so I generally make dinner as the bridge between work Neil and home Neil (even though they inhabit the same house!).