Interruptibility

Contrary to everything I’m reading, the goal of being a good programmer is *furthered*, not hindered, by planning on embracing interruptions. This is not to say that you never close the door or declare war on interruptions either, but those are tactical decisions. Strategy demands, however that you don’t ignore the piece of information that invalidates the work you are so ‘busy’ doing. Staying ‘plugged in’ is the only way to pick up signals of this sort. The greatest opportunity is still out there, and then – there is what you are working on at the present.

Here are some questions you can ask of each interruption (to yourself or of them), to maximize the value of the ones you take on:

1) Is this about what I’m working on ?
2) Is this about boosting my productivity for what I am working on
3) Is it important enough that it needs to be captured ?
4) If so, can the person communicate it to you in a 2-3 sentence email, that you can read and get back to them once you have time to grok it ? *

Number 4) is particularly important. First- because the ‘come to your door’ tactic is usually done when a person is being lazy in specifying what they want and often has a social motive in mind anyway (ooh how terrible! . So you’ll have a better chance grokking the edited version of what they want to convey anyway. Secondly, you are thinking in a different way at the moment, and the context switch to understand them (if they are not intending to put the 2 most valuable sentences first) will have a cost, and may actually cloud the issue you’re trying to understand.

Plan to allow interruptions – 8 hour closed door periods and 10pm – 3am hero sessions are excellent ways to end up off in the weeds, if they become the rule and not the exception.

We’re social animals, and not nearly as logical as we want to believe we, so we really doubly benefit from vetting our ideas with those of others..