What is the most annoying thing at work? If you ask developers, it is getting interrupted in the middle of a difficult programming task. That reminds me of the classic cartoon strip that made the rounds on HackerNews a few years back:
This is the perfect illustration of “flow state”. Your mind is clear and you feel you are in a natural rhythm where your knowledge, motivation, and concentration magically align. It is the heart of optimum performance and creativity often referred as “being in the zone”.
Flow state is particularly important when programming as there are so many variables you are juggling (pun intended). It is also a precarious state as even the slightest distraction can wreck your productivity. Unfortunately we live in a world optimized for distractions.
The workplace is often the destroyer of getting work done. An article in the Harvard Business Review showed the depressing state of workplace interruptions:
One workplace study found an average of almost 87 interruptions per day (an average of 22 external interruptions and 65 triggered by the person himself). Then, on average, it takes over 23 minutes to get back on task after an interruption, but 18% percent of the time the interrupted task isn’t revisited that day.
The first thing to recognize is that sometimes the enemy of flow is ourselves. The founder of Stack Overflow, Joel Spolsky, shared candidly that he can be massively unproductive. Mental inertia makes it hard for us to get started.
Second, sometimes what looks to the outside to be unproductive can actually be someone working in the flow. Creative work often does not appear“busy”:
Developers can appear very unproductive at times, sitting staring at the screen with our headphones on and very little in the way of keyboard clackety-tap. This however is when we are doing our thinking, when we are building up, adding to and rearranging the mental model of how our code will work.
Lastly, sometimes our work environment conspires against us. Besides the distractions of chat, desktop and mobile notification, and open office spaces, the tools we have for the job can limit our ability to get things done. One developer I spoke with experienced this which led to this conclusion:
Your developer happiness is unquestionably directly proportional to the ease of the tools you have to accomplish your task.
As engineering leaders, equip developers with tools that help them maintain flow and avoid interruptions. One potential idea is providing a repository of trusted internal knowledge to help jumpstart one’s flow towards solving a difficult problem. If this repository is community based, then subject matter experts can contribute and share their knowledge, and in turn reduce the interruptions they receive by answering repetitive questions from others on their team and organization. If this idea is of interest, I encourage you to read our post on building “A Developer’s Knowledge Architecture”.
What are your thoughts on achieving flow state? What have you found to help you and your team stay focused on programming tasks?
How to explain to a layperson why a developer should not be interrupted while neck-deep in coding?
I learned the hard way to never, ever interrupt a developer in their flow…
We help IT leaders in enterprises solve the cultural challenges involved in digital transformation and move towards a community based culture that delivers innovation and customer value faster. Learn more about our work here.