Neuroscience and your Development Team

Context is an important and fundamental Concept in Computer science and specifically, in this case, programming. It provides a scope for variables to live, it provides functional boundaries for units of execution and an abstraction of architectural elements. In software, as in life, there is a time-cost associated with a move between these contexts. As a programmer, it is imperative to manage these relationships and the associated units of work effectively or the product will suffer or fail. As a leader or manager of programmers, it is equally imperative to manage the context of work each member of the team is engaged in. Failure to do so effectively will lead to missed deadlines or milestones, budget overages, diminished morale and just generally looking bad.

Given a sized task, developers tend to work in autonomy and require very little in terms of management of their day-to-day activities. But what happens when they are routinely re-tasked to address the ever present ‘emergency’ or pulled into unnecessary meetings? What happens when the PM drops by their desk to ask a quick-question or when they are compelled to be responsive to emails all day? The answer is simple, relatively obvious and the indeed the subject of this narrative.

There is no shortage of topical commentary on the subject but if you’re like me, I don’t just want to know about a thing, I want to understand it. Thankfully, the last ten years have been great for the field of Neuroscience and there is a mountain of high-quality research on the topics of memory, learning, focus and, cognition in general. I will keep the science digestible but provide links to the material I reference or cite so you can dig deeper if so choose.

We all understand that programming requires great focus. It requires the developer to hold a ton of nuanced information in his head or Short-Term Memory (STM). The developer must have an immediate and clear understanding of the problem he is trying to solve, and an inventory of the pieces involved as well as the complex relationships between those pieces. He must also possess a familiarity with the finite data and the shapes it can take and of course the nuanced semantics required of a given language to bring it all together for the compiler to understand. All of this, in their head all the time.

Over time, when it all comes together, and the fingers hit the keyboard with increasing speed and dexterity they reach an almost meditative state now known and referred to as Flow.

So how does it all work and how does context switching or task switching affect performance and productivity in your development team? I am glad you asked because this is my favorite part! Now let’s get into the nuts and bolts, or Neurons and Glial cells in this case.

We have a Long-Term Memory and a Short-Term Memory. These are not pseudo-systems but real, tangible areas of the brain whose locations and interactions have been well documented through electrophysiological and neuro-imaging studies and in terms of working-memory or STM, reside primarily in the Prefrontal Cortex. Verbal STM for instance has been shown to rely on the left inferior frontal and

left parietal cortices. Long-Term Memory for things like life experiences and the motor skills that enable you to walk, and talk are stored primarily in the hippocampus and basal ganglia respectively but the physiological phenomena we will be examining is focused primarily on the STM and so shall we.

The STM again, located primarily in the prefrontal cortex needs some mechanism or structure to hold and organize the information coming in so we can operate on it cognitively. So how is that modeled? Well, this time, the medical research community threw us a bone and used a term that anyone in technology can understand. A buffer, or a collection of buffers really. This multi-store is composed of several buffers with each responsible for a specific type of input, like visual or audio. On top of these disparate buffers are a set of processes that act on information stored within them and are known collectively as the ‘Central Executive’ In computer science parlance, it’s a bit like an API in front of an ephemeral data store.

Okay, so now we have some information about a complex problem stored in a series of buffers and governed by a central executive, but exactly how much information can we store there? It turns out very little, in fact the generally accepted number is four. That’s right, four ‘things’ with a thing being – well, a thing. Could be a number or a pattern or as we will soon find out, a more complex structure with links to objects in Long-Term Memory. At this point, the programmer has enough knowledge, experience, and information from the present and recent past to then transform intention into action. Elsewhere in the frontal lobe, the Primary Motor Cortex has those fingers tapping away at the keyboard and materializing the codified solution to our complex problem until a colleague taps him on the shoulder.

Confused and stunned, he turns to face his visitor while slowly removing the headphones that were once a universally understood signal that meant, “I’m coding, do not disturb”.

The visitor says something like, “Hey, I don’t mean to interrupt you but real-quick, can you …”. A prudent team leader would have a squirt bottle handy to thwart unwelcome solicitors before they interrupted a developer deep at work.

The developer, with a smile on his face, proceeds to answer the question or look at the issue and sometime later, returns to his work.

If we think back to the multi-Store and its buffers, we will recall the impossibly small storage capacity and might then begin to wonder what happened physiologically when that interruption began. Well, when the Central Executive realized that a new problem was being presented it needed to begin storing incoming content. Trouble is that the buffers were already full of carefully organized and linked data relevant to solving the complex problem at hand. Since the number and size of buffers is constant, there was no alternative but to purge the existing information to make room for the new stuff. It’s like back before auto-save and you were writing a paper and you were just about to write the conclusion then lost power before you ever saved and all you are left with is regret and that sick feeling in your stomach.

You might think, “hey, no big deal, just get back to it.” and sure, that sounds about right but before you can write that conclusion you must first rewrite the paper or in the case of the programmer, he has to rebuild that context, reassociate the links to LTM, re-evaluate the problem and reformulate that mental map where he sees all the moving parts and knows instinctively where to go next and what needs to be done. This does not happen quickly, and it does not happen easily. Further research points to a

relationship between interruption interval and depth of memory loss to the extent that is the duration is sufficient even LTM can be negatively affected.

In summary, there is no such thing as a ‘quick’ question when it comes to a disruption for a developer. If you want a horse to pull a carriage don’t dump a bag of carrots in front of him; put some blinders on him attach the poop catcher and point him in the right direction.