We understand how the creative work of programming can proceed at a comfortable tempo. We're less sure what strategies work when that tempo is interrupted. If we want to know how people successfully work through these pauses we should just ask.
See Tempo Interruptions for interruptions classified.
See 3x3 Reflection for a useful interview structure.
We've borrowed the notion of interruption from recognized events that disrupt flow such as unexpected phone calls. The landmark book, Peopleware, explored these at a time where programming required sustained intense concentration of a solo individual. We call these external interruptions. We've since learned many techniques to externalize this flow such as TDD. We're much more interested when social flow is interrupted from within.
On these pages we look for insight by contrasting the Dayton Experiment with teams making software made complex by the demands of growth. Let's supplement this inquiry with a few structured interviews where people understand our interests and have recent experience working through interruptions.
Some ideas to be pursued.
Abstracting Words and Numbers choose the right one?
Ad-Hoc Theory as Design need not be right, just useful.
Learning from Interruptions like from incidents.
Scripting Tempo Resumes but then doesn't. Ugh.