Embracing Distractions
We have all been there.
You are working on a bug fix in an arcane piece of legacy code. Headphones on, dark-wave music pumping in your ears, you are focused. You notice a piece of duplicated code in a related function and you make a mental note to refactor it in a separate commit. In the meantime, you notice something else in the code. What is that? Oh, that’s another lurking bug. You will have to fix that, too. And so you will have to remove those trailing whitespaces which are staring at you with their red arrogance in the middle of your Emacs buffer. A long-running Jenkins job is running on a browser tab and you are waiting for its result before you can merge your pull request which needs to go to production by the end of the day. The job is not done yet and auto-merging is not enabled, better not to forget about it. There’s a Reddit tab next to the Jenkins one. You click it. Videos from the CodeBeamSF conference are already out. Wow, that was fast, weekend is sorted. Someone pings you on a Slack channel. It seems important, so you open Slack. Something weird is happening to the production system and it seems related to a feature that you just released. Luckily it takes you only two minutes to understand what is going on, so you suggest a recovery action and you can go back to your bug fix.
“What was I doing?”
You look at the branch name in your prompt. Right, that was it. But wait, there was something else you noticed a few minutes ago. You cannot remember. Frustration levels raise. Someone comes by your desk holding a cup of coffee.
“Leave whatever you are doing and join us for a fika.”
Thanks Science you live in Sweden. Frustration levels go back to normal during the fika. Coffee spreads through your veins and life is good again. But the sense of frustration and that feeling of not remembering what you were doing will eventually come back when you sit back at your desk.
This post is about distractions and how to deal with them, trying to minimize their impact. This post does not pretend to be the ultimate guide to boost your productivity, but it simply presents a methodology which I adopted and refined over the years to cope with the multi-tasking life of a developer and the amount of information which we are exposed to every day.
“Preachers say: do as I say, not what I do”
- John Selden (1654)
Despite of all the tips and suggestions that I may share here, I occasionally do not follow them myself. I am not a machine and so aren’t you. Use this methodology with care and don’t be obsessed by it. After all, the word distraction - which comes from the latin distrahĕre (to separate) - also has a connotation of recreation, entertainment. Never take life too seriously.
I have been coding Erlang for most of my professional career and if there is one single thing that Erlang taught me is that whenever you have a big issue which seems tricky to solve, you are probably looking at it from the wrong angle. So let’s try to take a step back and meditate about distractions.
What is a distraction? A distraction is something that interrupts our execution flow, forcing us to do something else than what we originally planned. Are all distractions inherently bad and evil? Not necessarily, if you handle them properly. Distractions are just the consequence of living in a concurrent world, where people asynchronously communicate among each other and continuously interact. A distraction usually comes in the form of a message, be it a notification, an email, noise from the background. It’s just a matter of consuming the right distraction at the right time (selective receive comes to mind). Humans are a bit like Erlang processes, with their inbox where distractions get piled up. I am terribly biased, but life sounds a lot like an Erlang system.
Erlang learnt from life. Can life learn from Erlang?
One of the main principles that the Erlang philosophy pushes for (and that many other programming languages are trying to adopt) is that failure is a matter of life, so it does not make sense to fight against it. Instead, we should just accept that in a large, distributed system failure will happen. Better to embrace failure, accepting we can’t always avoid it. So, what would happen if we take the same approach and apply it to distractions? It would mean accepting the fact that distractions will always occur, in the form of Slack notifications, emails, Reddit posts or colleagues holding a cup of coffee. And that we should embrace the fact (not the distractions themselves!). Put in other words:
Distractions are un-avoidable. Let’s deal with them.
I started wondering what other people felt about the topic. Googling for “embrace distractions” revealed a bunch of related articles and opinions, but the main point of those was that distractions are not always negative and that you should look at their positive aspect. This post is not about that. This post is about minimizing the impact that distractions have on our execution flow. Before we can do that, we need to understand distractions a bit more.
Distractions are asynchronous by nature, like any other form of communication. Whenever we receive an email, the sender is not (hopefully!) sitting on the other side of the monitor waiting for a reply. Life goes on. This also apply to physical distractions (i.e. colleagues coming to your desk asking for help). We often have the option to respond that we are busy and kindly ask if we can come back to them. As long as we always follow-up and not forget about it, this is perfectly ok. Never ignore colleagues who ask for help. It’s just a matter of focus and priority. If you help your colleagues at the appropriate time there will be higher chances that you will be actually focused and friendly while helping them, instead of considering them a distraction. Postponing the help a bit also has the advantage that whoever is seeking for help will have the chance to try that one more time that will allow them to solve the issue by themselves (which can be extremely rewarding) or at least have the opportunity to better formulate the problem in their head.
Distractions are also bi-directional. We are not just the target of distractions, but often the source of them. Every time we send an email or raise a pull request, we create a potential distraction for someone else, without even realizing it. It does not matter how disciplined or respectful we try to be. Someone will be interrupted because of our actions. And that’s perfectly fine.
Distractions can be distinguished into relevant and irrelevant ones, often depending on the moment when a distraction is received and handled. Reading an email which reminds us to submit our tax return before the end of the week while at work, despite of the importance of the email itself, is an irrelevant distraction. Being called by a live operator on the phone because the production system is misbehaving is a relevant one.
Finally, distractions often lead to tasks, be them a paper to read, a bug to fix, an email to reply to. And tasks can be prioritized.
Now that we understand distractions a bit more, let’s see how we could deal with them. The first obvious thing to try is to actually reduce the sources of distractions. This includes taking the time to unsubscribe ourselves from that old mailing list which keeps sending messages every week (and that we never read anyway), to create filters for un-actionable incoming emails and, most important, to disable notifications. Yes, you’ve read correctly. Instead of being constantly bombarded with updates, videos and links, try to have a sane routine, where you only check news, Twitter and Reddit only at specified times of a day. This will dramatically reduce the amount of time your attention get diverted by irrelevant distractions. Will you miss important stuff happening? Probably not. I have been using this strategy for a couple of years now and I can ensure you that I didn’t miss any big news or update for things I really care about. Checking a Facebook timeline or a Twitter stream is becoming more of an obsessive-compulsive instinct than a necessity. I generally look at news twice a day (in the morning, while I travel to work, and in the evening, when I travel back home). I have notifications disabled for all social networks and messaging systems, including Whatsapp, Messenger and email. Only exceptions are phone calls, pages and explicit mentions (e.g. Slack mentions). In this context, I loved Joe Armstrong’s quote from the Code Beam SF keynote:
“as for England, almost the last significant scrap of news from that quarter was the revolution of 1649.”
- Henry David Thoreau (1854)
Occasionally, distractions will reach you via official channels. For example, a colleague may send you a link to an interesting Erlang library over Slack. Do not open that link. Instead, quickly acknowledge the distraction (e.g. by replying that you will look at it in the evening) and save the link for later. There are a tons of applications and extensions that allow you to save for later links and pages. I personally use Pocket for this, which is free and simple. Spend a couple of seconds to tag the link that you received using a keyword that will help you to categorize distractions into buckets of interest. Having a curated list of stuff to read is great for occasions where you have nothing better to do (e.g. when you are waiting for a flight or you are sitting in the waiting room of a dentist). Letting distractions rest a bit into a bucket of interest also helps to identify what is really important and what can be skipped. Periodically go through the list of links that you saved (I try do it once a week, but often fail) and delete (or better archive) items that are not necessarily worth reading. Don’t be afraid of deleting stuff. Interesting, important things tend to come back and it’s important to keep the list contained, rather than an append-only list including every single academical paper published in the past decade.
Probably the most problematic part of a distraction is related to the unavoidable context-switch that it provokes. Let’s go back for a second to the story in the incipit, where our developer, while trying to fix a bug, faces three little distractions: an unrelated bug, duplicated code in a related function and some evil trailing whitespaces. What the developer did in that occasion was to try and avoid those distractions, while focusing on the main task: fixing the bug. Whilst this may sound like a sensible approach, it turned out not to work very well. It provoked stress - after all stress is about what you still have to do and never about what you are actually doing -. It also revealed to be a bad decision since it was too much information to keep in memory. The opposite approach would have been to try and fix all issues while they were discovered, diving into every single distraction. That would have caused the developer to lose focus on the original task (the actual bug fix) and probably polluted the code change with two bug fixes, some refactoring and various cleanups all-in-one, which would have made, among other things, a review of the changes un-necessarily complicated and distracting for other developers. A better approach would have been to write down the issues discovered and to keep focusing on the actual bug fix. Working inside Emacs, I make extensive usage of org-mode and I find its capture system terrific for situations like this. Of course, other mechanisms to obtain the same goal work as well, including a good old style agenda or a post-it. The whole point is that distractions can happen at any time. The trick is to always save enough context so that, in case of an interruption, we can always switch back to our original task in a painless manner. A corollary of this approach is that we do not necessarily have to fix everything ourselves. The lurking bug found by our developer could have been a potential candidate for a new ticket for the team.
In the context of distractions, the snoozing concept deserves a special mention. Many modern applications, such as Google Inbox or Slack allow you to snooze emails and messages. This can be an extremely dangerous practice, since it often results in recurring distractions that will end up diverting your attention not once, but multiple times. If the snoozed event is not actionable, delete it. If it is actionable and small, just get it done. If it’s actionable but big, prioritize it accordingly. Snoozing it for the sake of snoozing it is pointless and stressful.
I would also like to reserve a special note about calendar reminders. Many people tend to have a 10-minutes reminder before a standup or a meeting. Chances are that, after getting distracted by the reminder, they will just ignore the notification and dive back into their code, to be distracted again after 10 minutes when it’s time for the actual meeting. You can be smarter than that. When the reminder triggers, save as much context as you can from what you are doing so that you can easily resume it after the meeting. Then, prepare for the meeting. Reflect on what you are going to say or what you want to hear. If it’s about a standup, ensure that all tickets that you want to discuss are on the board and up to date. You may be able to transform a distracting standup into something actually useful.
So, to recap:
- Distractions are un-avoidable, so better to embrace them
- Remove sources of un-necessary distractions
- Selectively receive distractions
- Store enough context at all times, so that you can context-switch back after a distraction
Have fun!