Another Perspective on Interrupting Developers at Work

A comic about collaboration.

Anne LoVerso
Built to Adapt
2 min readMar 27, 2018

--

Recently, I saw a comic about interrupting developers making its rounds among the Twitter programming community. The more I saw it, the more I thought about how little it reflected my own experiences in programming.

This comic attempts to capture my own experiences with interruptions — a usually-seamless flow from one area of attention to another, supported by your pair. When pairing, you tend to talk things out or write things down; in both cases, you end up easily getting back on track after an interruption, break, or sidetrack. Having two brains gets you back on track twice as fast.

I was surprised by the reaction from the Twitter community— it resonated with a lot of people! I think most developers acknowledge that they’re not single-process thinking-machines and that interruptions are a part of what we do. Even people who don’t pair related to the process of thinking things out loud or on paper to preserve your thoughts.

I’m glad people are thinking more about interruptions — if they can even be called that. If being interrupted by a teammate unblocks them and keeps the overall project moving forwards, it’s not really an interruption, is it? It’s just a team coming together to do the collective work needed.

Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.

--

--