When is OK to Interrupt a Developer?

Interruptions are costly for all knowledge workers, but especially so for developers. As Professor Parnin mentions in his well-known post, Programmer Interrupted, interruptions cost developers a minimum of 10-15 minutes per instance. Unfortunately, at least some of these interruptions are essential—teams must coordinate, experts must be consulted, APIs must be explained—but how can developers minimize the impact of interruptions? With Codealike, the most costly interruptions can now be avoided, as Codealike visualizes the state of your teammates on its Pulse Panel and teammates can make smarter decisions about when to interrupt.

About to interrupt your co-worker? Check the Pulse Panel to see his/her working state. Before interrupting weigh your needs against how “in the flow” he/she is. Having a proxy for your co-workers’ level-of-engagement before interrupting them leads to less disruptive interruptions.

While knowing your co-workers’ mental state may lead to better timing for interruptions, the algorithm that detects engagement must be reliable. In this post we share the basics of our algorithm for measuring engagement. This algorithm is born of countless iterations, extensive piloting in our own team and on beta Codealike users, and even within large enterprise development shops. While it is not perfect—it is conservative and may show you as only “Active” when you feel you are “Busy”—it is by far the most effective and user accepted algorithm we have tried to date.

Without further ado, here is Codealike’s algorithm for determining your activity level:

Step 1: We evaluate the last 30 minutes

The entire algorithm is based on a simple data structure. That is, an array of Booleans representing the user’s last 30 minutes of activity. For the purpose of visualization, each grey box represents false (i.e., no activity during that minute) and each orange box represents true (i.e., activity during that minute). As you can see, the example below shows no activity in the last 30 minutes.


Step 2: Is it Grey?

Grey is the color that represents that you don’t have any activity on coding tasks. If you have no activity for the last 30 minutes then, obviously, we decide to show your status as Grey.


Step 3: Is it Grey II?

The Grey analysis is not yet finished. If you do have activity for the last 30 minutes but the last activity is older than 7 minutes ago, then you’ve earned the Grey pulse again. If you’ve recorded activity for the last 7 minutes, then we continue the analysis in order to define if your status is Green or Red.


Step 4: Is it Green?

If you’ve activity for the last 7 minutes, then we evaluate the amount of activity that you’ve had for the analysis timespan which is that of 30 minutes. If your whole activity for that period is less than 15 minutes, then you’ve your Green very well earned.


Step 5: Is it Red?

You’ve got it. If you’ve recorded activity for the last 7 minutes and the total amount of activity for the last 30 minutes is equal or larger than 15 minutes, then you’re in Red status and nobody should even look at you 😀


Of course you should consider a couple of factors like network and servers latency and that may vary the results.

This is not our final answer to how we compute the Pulse indicator. We constantly try different strategies and you may expect changes on how we decide if you’re open to be interrupted or not.

Do you have any suggestions on this method?

How would you automatically decide if a developer should or shouldn’t be interrupted?

One Comment

Leave a Reply