Saturday, June 13, 2015

Programmers and Interruptions

As a programmer, the single biggest problem I face is the interruption.  Whilst I can joke and empathise with other programmers about this, it's something that non-programmers don't understand. There's a well-worn cartoon in programming circles that I will share here, just incase you haven't seen it.

The point of the cartoon isn't lost on anyone, but what is lost on non-programmers is the time span that this may have taken place over.  For an average programmer on an average job, you're probably looking at 10-20 minutes.  For a programmer working on a really complicated system, this can be several hours.  Additionally, the mental workload involved can be draining enough that if this happens, say, three times in a day, the entire day can be written off. 

But what's going on here?

The crux of the problem starts with the differences between knowledge workers and non-knowledge workers.  Most people regardless of status in the workplace will work on a schedule where you focus on some thing, get interrupted, switch focus until interrupted again.  It's all about prioritising what is most important and getting these things off your plate as quick as possible.  You hear managers complain that they never get anything done because their day is full of interruptions, but really that is their schedule - it's just a series of interruptions and the only thing they have to worry about is what interruption is coming next.

This means when a manager/house-buddy/spouse walks up to a programmer and asks them "a quick question", they interpret the amount of time being expended by the interrupted is the same as the amount of time spent by the interrupter.  However, this is not the case...

First, let's introduce the programmers mental stack.  It's analogous to this receipt spike:

With a receipt spike, the first item on the spike is the last one to come off.  This spike is known in computer terms as a "stack", but it's the same thing.  For a programmer, the first item (so at the bottom) on the stack is what we are trying to accomplish (fixing a bug, writing a feature, etc).  Then we push onto the stack the next pieces of the puzzle.  

A real-life example of what I am talking about...  This is one I had today (remember, it's in reverse order, so start at the bottom) it's about 45 minutes :
  • Trace in my head the flow of the header packets that precede the payload packets to make sure this is the best way of doing things.
  • Double-check logic for endian-ness incompatibility.
  • Packets in wrong order still, so add stuff for that.
  • Rejig classes X1, Y1 and add new functionality to classes X2 and Y2 all in my head.
  • Build packet model in my head.
  • Refresh my head on how the packets are structured. 
  • Looks like a packet issue - maybe if I remodel how I'm dealing with the packets... 
  • Let's trace the code in scenario B and compare to what we just learned in scenario A.
  • Let's trace the code in scenario A to see precisely what's going on.
  • It fails in scenario B - must fix scenario B. 
  • It works in scenario A 
  • The device does not behave how I expected it to.
  • There's bug in my iOS Bluetooth code - must fix it.

Obviously, this is all done mentally in my head, and I'm tracking what changes I haven't yet done as well as concentrating on the actual task I'm working on at this precise moment, whilst making sure to balance the stack in my head so when I finish each task, I can go back to the task I was working on before.  When doing this, I'm not typing a single line of code.  I'm staring at a picture on the wall - probably not even taking in what my eyes are seeing - and my ears hear stuff, but I'm not actually listening.  I've likely got headphones on, just to drown out the things like talking that are happening around me, so I don't lose focus.

This is the moment when people say "Oh, as you're not busy right now, can I just ask a quick question" and then wonder why I'm annoyed.  As the person is still talking to me, my head is scrambling to work out how I'm going to recover from this as I still have about 3/4 of the stack in my head.  As I'm being asked if this was a bad time, my anxiety level is skyrocketing as I try to cling on to what I learned in tracing scenario A in that stack above... Was it header packet 0x02 that had the payload size 0x0400?  Must remember 400... no, it's not 400 as the bytes need to be swapped so 0400 is really 0004...   At this point, I must answer the question I'm being asked - so blurt it out - 4... must remember 4... what packet was that on again? 2? Was that in scenario A? Or B?

Now panic sets in...  If I can't remember whether the payload size 400... no... 4... is the right one or the wrong one, I need to go back and look at that again, which means we're now into another 30 minutes of building up the model in my head again.  Having answered the question, I'm staring at my screen and quickly trying to refresh my head.  This is when you hear the dreaded words "Before you get too engrossed again, can you just...."


Now, I can get back to work in a minute or two if I'm doing something trivial.  However, if I'm working on a really complicated issue (such as the above Bluetooth stack), then it's not uncommon for me to take 30 minutes or longer to get things straight from a cold start.  Really big issues can take 90 minutes to get my mental cache loaded up with the model of what I'm doing and how I'm doing it, plus all the states memorised as to what it's doing right now. 

And I'm not alone.... There's a study (see here) that was done over 10,000 programming sessions to see what the edit lag (how long it takes between interruption and starting to type again) that looks like this...

As you can see it takes a while to get back into things.

There is a retort from some managers (or other house guests if working from home) that we need to "learn to handle interruptions better".  This is just throwing fuel onto the fire as a knowledge worker is busy using concentration and focus to perform a task and interruptions cause a break in this focus, making the comment analogous to tripping up a footballer and telling them that they need to handle unplanned obstacles better.

One last thing I'll leave you with:  Never interrupt a programmer chatting to a rubber duck to ask them what they're doing.