For a programmer, an interruption is oh-so different. There you
sit, 12 calls into the call stack. On one monitor is a carefully
picked set of inputs to a complex form that was responsible for
generating the issue and on the other monitor is the comforting
dark theme of your IDE, with the current line in the debugger glowing
an angry yellow. You’ve been building to this moment for 50 minutes
— you finally typed in the right inputs, understood the sequence
in which the events had been fired, and got past the exact right
number of foreach and while loops that took a few minutes each to
process, and set your breakpoint before the exception was triggered,
whipping you into some handler on the complete other end of the
code base. Right now, at this exact moment, you understand why there
are 22 items in the Orders collection, you know what the exact value
of _underbilledCustomerCount is and you’ve hastily scribbled down
the string “8xZ204330Kd” because that was the auto-generated
confirmation code resulting from some combination of random numbers
and GUIDs that you don’t understand and don’t want to understand
because you just need to know what it is. This is the moment where
you’re completely amped up because you’re about to unlock the
mysteries of what on earth could be triggering a null reference
exception in this third party library call that you’re pretty sure
—

“HI!!! How’s it going? So, listen, you know that customer order
crashing thing is, like, bad, right? Any chance I can get an ETA
on having that fixed?”

[possibly from https://daedtech.com/programmers-teach-non-geeks-the-true-cost-of-interruptions/]