Because Slack Broke My Flow... Again

I’m getting stuff done again. Concocting possible next steps to be able to present a well thought-through battleplan to the team. Yes, I’m awaiting that moment the metrics demonstrate that we are set to move forward; that moment when we have discovered the wave we are to ride :surfer:. Suddenly I’m jolted out of the zone by this one sound that I have come to dislike intensely :rage:. Crap :shit:, that’s what you get for forgetting to kill Slack before getting started!

Generally I start my sessions by setting my phones to the silent mode (the one that doesn’t even vibrate), turning on the “Do Not Disturb” mode on my laptop and occasionally wearing my headphones just to keep possible smalltalk hungry fellows at bay.

What we all seek is that flow. It takes energy to get into the flow and interrupting someone in flow should become something we try our best to steer clear of. Once a interrupt occurs task switching often follows and for many of us, returning to whatever it was we were doing before can often cost a significant deal of effort after such a interruption.

Task switching is hard and humans don’t shine at performing this trick (neither do computers by the way1). The great Joel Spolsky wrote about it multiple times (read Human Task Switches Considered Harmful, Where do These People Get Their (Unoriginal) Ideas? and The Multi-Tasking Myth) and a [lot of brilliant researchers][ama-multitasking] have empirically studied the costs of task switching. Task switching is not unrelated to interruptions and everyone who has ever written code with a non coder nearby knows how frustrating it is to lose a train of thought to hear about another oh-so-funny cat meme.

Many startup spaces that I’ve visited don’t seem to understand the damage caused by pulling knowledge workers out of the zone. This post just covers a few remedies I use to deal with that.


My fellow team members and I have an understanding. Whenever they ask for a minute and I pick up the audible mumbling or gestures, I either redirect my attention to them when I’m available or signal a time-out if I’m really close to cracking a nut :chestnut:.

This allows me to get stuff done, while acknowledging their need to be heard in a short while. Most of the people I have worked with understood this. It just took me explaining my flow to get them to understand, but at the end of the day no one wants to be responsible for getting you out of that getting-things-done flow… just let them know :wink:.

Talk with your team members about the types of issues they can trouble you with.


I must admit that I often have nothing playing in my headphones :headphones:, because at some times music kills my focus (especially when I’m reading papers2).

The cool thing about the headphones, however; is that most people seem to understand that one is not to be bothered for small matters whenever the headphone wall has to be broken.


Whenever a workspace gets really noisy, I often crank up the white noise which works well in drowning out the noises of pingpong, the laughs of meme watching folk and the funky beats of the one person who just has to play that through his Sonos.

In the spirit of live and let live I don’t bug Mr. S about his music, heck sometimes his playlists are great. When I need to focus I’ll turn up my noise. Everybody happy :smile:.

Kill Slack

Slack is a wonderful tool to communicate within teams, but until they introduce a silencer I will have to kill it before I venture into my focus zone. Today I forgot to do that and it’s probably the fact that it really startled me that I jumped on the rant bandwagon.

Since last year, some users have been begging for this feature.

Apparently we haven’t begged loudly enough, so I’m giving it a try as well :mega:. At some point they will have to make our day, right? Come on people at Slack don’t be slackers (couldn’t resist using the demonym pun), :shipit: ship it!

Time to get back to work…

  1. Multitasking in computing requires a context switch which is a rather expensive operation. Registers, stack pointers and program counters are modified as the context is altered for the one task to be properly suspended and another task to be initiated or resumed. Just running a single task is generally more efficient as there is no switching overhead. A processor with multiple cores isn’t multitasking if every core is handling another task (it is in fact multiprocessing) and humans aren’t multitasking if every member in the team is doing one thing at a time from start to finish. It’s that simple and there is more to read on this matter by the Crazy Programmer

  2. Speaking about papers, I just stumbled upon Emre Karagozler’s work (whom I just learned about through the Google Soli project). I read his Harnessing Capacitance for Inter-Robot Latching, Communication, and Power Transfer paper and would recommend it to anyone who tinkers with electronics. It’s pretty remarkable material and just being aware of this method of latching modular robots is worthwhile.