Start Your Coding Engine

How much does it cost to tap on the shoulder of a software developer at work? We know software development takes a lot of mental energy and focus, but surely it can't be that hard to just "get back into it" after Joe walks by your desk and asks you about your lunch plans.

I like to think of the brain as the body's version of random access memory (RAM). At any given time, you have a finite amount of RAM available for your system. Just as opening and using programs consumes the available RAM on your computer, storing thoughts in your mind uses up your brain's available "RAM". When you're using your computer, and you are done with a program, you close it, and the computer gets some RAM back. Similarly, when you are done considering something in your mind, you release the thought and your brain gets some of its "RAM" back (this is obviously an oversimplification).

Now, consider how difficult it is to hold on to your thoughts; all those times where you "just had it". How much energy do you have to spend to keep a thought in your head? How many thoughts can you keep in your head at once? Imagine trying to construct and keep track of a system of many thoughts that are all interconnected. If you lose focus on any one part of the cohesive concept, the entire idea can be lost. In this way, it would appear that the brain "flushes" its RAM fairly easily when something else demands its attention. This is the reason distractions are so costly for software developers.

I'll use the analogy of starting an engine to illustrate this point. Let's say you come into the office, fire up your laptop, and open a text editor. You're not "driving" yet. You've put the key in the ignition and you're trying to get the engine to turn over. Once it does, you naturally accelerate as you "get back into it". After 30 minutes or so, you're back up to speed with where you left your code and you're ready to continue fleshing it out. At this point you are "driving".

Writing enterprise code is mostly describing what should happen in a process if certain logical conditions are met. It's a lot like writing out the directions for a road trip. There is a notion of, "If I get to this intersection, I turn right. Four blocks down, I make a left if it's raining." When a software developer is "driving", they are able to see the directions in their mind and can continue to describe how to get to their destination. As they build up these directions, they consume more and more mental RAM and it can become difficult to keep track of where they have been and where they are going.

So, what happens when Joe asks about lunch plans? Quite simply, the engine stalls and all forward progress is halted. If the interrupting conversation lasts long enough, the solution stored in mental "RAM" could vanish as that RAM is used to hold the conversation. Afterward, this leaves the developer to have to question where they were and stop and ask themselves for directions again. Then, the process starts from the beginning. The engine must be restarted and momentum must be regained. In this modern world full of Zoom meetings, Teams chats, and "quick calls," it can be very difficult to find the time necessary for sustained, uninterrupted focus, and this process of stalling and restarting the engine can occur multiple times throughout the day. Ideally, after restarting their engine, a developer is able to accelerate back to "cruising speed" and continue moving forward, but if your engine continues to stall just as you get to the point where you can start to accelerate, it is very difficult to move forward.

If minimal productivity occurs when the engine is off and maximal productivity occurs at cruising speed, it's interesting to consider how much time is spent throughout the day simply trying to accelerate to cruising speed. If you have a day with 4 meetings, it is far more efficient to schedule them in a block together, so that the rest of the day can be used as uninterrupted focus time. If you don't do this, you can end up with 4 meetings spread across your day, and 4 separate 1 hour blocks of "focus" time for development in between. It is very hard (if not impossible) to build software in bursts like this.

I used to be guilty of being too available, hopping from chat to chat, call to call, context switching many times throughout the day. When you have so many different things competing for your attention, it's hard to give any one thing the appropriate care and attention it deserves. If you're always answering questions or helping someone else, it is very easy to find your day suddenly gone, with little time allocated for the work you need to do. Collaboration is always a good idea, but focus time is equally important. Next time you consider pulling a software developer out of their focus time, consider how important the question is.