Interrupt timers

I’ve seen a lot of talk about using timers during work. There is the well-known pomodoro technique. The time-block method is an abstraction of the same concept. However, I have not seen anyone discuss using timers to deal with interruptions.

My work environment is inherently disruptive. My desk is in the office area of a working research laboratory. When I am doing experimental work, there are other researchers around me. The Platonic ideal of a deep work lifestyle is tricky to achieve. I occasionally work from home to get some uninterrupted time, but my work desk is better than my home desk when it comes to most work that I do. Throughout a typical workday, I will get asked questions and given tasks without a predictable schedule. My deep-work hours are scheduled and most of my colleagues respect my boundaries. I am finding the writing group helps to set boundaries, with the excuse of ‘sorry, I’m in a work meeting’ and pointing to the zoom call enough to deter all but the most oblivious colleagues. However, sometimes things don’t go to plan. Sometimes unexpected urgencies arrive. And sometimes, people leave things until the last minute, requiring a quick response from me.

During my non-deep work hours,¹ where I am not in a dedicated work session, but am still trying to get work done, I have started using an idea I took from coding/electronics: the interrupt. When something gets put onto my plate which is relatively urgent, I acknowledge the distraction, write down any salient information, set a timer on my phone, and get back to what I was doing. The setting of the timer allows me to return to my work, knowing that the distraction was handled sufficiently for the time being. I can get back into the flow state, as I have ‘closed the loop’.

In electronics, particularly microcontrollers² an interrupt can be assigned to an input (such as a button). The computer will run its main program on loop, executing whatever has been coded. If the input on the interrupt pin is triggered (the button is pressed), then the program is halted, and the interrupt function runs. The alternative approach (and the one most people implement) is to run the main code on loop, and during that loop to have a check on whether the button is currently pressed. For many applications, this coding approach is easy and still works. But it has the cost of having the microcontroller constantly have to check whether the button has been pressed.

Likewise, if I don’t set the timer then my subconscious constantly has a little check-in with whether there was something else I was supposed to be doing. I set a timer based on either estimating how long I need to finish the task I was working on, or how long I can wait before swapping to the new task. This minimises context switching, and makes the interruption much less intrusive. I think a lot of people will switch to the new task, and try to get it done as quickly as possible to allow them to get back to what they were doing. This saves the constant monitoring for whether there is something else to be worked on (the checking if the button has been pressed), but brings with it the mental cost of switching tasks.

I recommend giving the interrupt timer technique a go.