At work I often make changes to our data pipeline, changes that can take a full day to build and get feedback on if they're successful, but which can also fail at any time. With wait times that long, I have to multitask to be productive. This post is about a technique of recording your context, to try to lessen the costs of switching between tasks.
Losing context
When you start work on something new, it takes a little time to fully engage and be productive. During this time, your mind is loading up the details, accumulating all the information you'll need to be able to make quick decisions and to keep you moving forward. This is basically what's needed in order to enter a flow state.
How long this takes depends on the task. I can delete useless emails without any prep time, but it takes me 15-30 minutes uninterrupted to engage with a new data task or a new piece of writing. Back when I was working on my thesis, real progress from where I left off wouldn't start until I'd been at it a whole hour.
All this preparation your mind has done is lost when you switch to a new task. But, I've found that for technical tasks I can maintain some of it by writing it down before I move on.
Writing it down
For each task I'm working on, I need to recall four things before I'm truly productive again:
- The end goal: What was this piece of work even for? What was it hoping to achieve?
- Previously: What did I do in the recent past on this?
- Currently: What's in-progress, what is the thing I'm waiting for right now?
- Next: If the thing in progress succeeds, what would be next?
Each of these seems to be important. By writing these down before I stop a task and reading them as I resume it, I'm much more productive than when I had to recall and reconstruct this information from the other pieces at hand.
Workspaces
The best place to write this down is right where you're working on your task. I think of this has having a workspace for each task. In my normal development, these workspace take one of a few forms.
Virtual desktops
On my Mac, I standardized on one virtual desktop per task, with a sticky note in that Desktop containing the context. This is a great route if you have a large monitor. The main pain is launching new application windows into that Desktop instead of to a desktop they're already in.
To solve this, I launch applications with Alfred, and have AppleScript targets which launch a new iTerm or Google Chrome window in the current desktop. This is a perfectly workable setup.
Screen or tmux
On just my laptop screen, using a sticky note was too wasteful of screen real-estate. Instead, I moved to running a terminal with GNU screen, and keeping vim open in the first screen window with a README file. If you use some other editor, like Sublime Text or Atom, you might open a copy for each task and keep the task context open in one pane the whole time.
Remote servers
If a remote server is spun up solely for the purpose of a task I'm working on, and it's where that task lives, I put the task context in a README in that that server's home directory. This is also a useful thing to find if you forget to terminate the server, and later need to work out what it was for.
Capture, resume, complete
By capturing the context explicitly and updating it whilst I work on a task, its details come flooding back much faster when I resume it. 15 minutes to switch between tasks becomes 5 minutes, meaning I'm more productive and can afford to work on more things at once.
If you find yourself getting lost in context switches, try this technique out and see how it works for you.