Rapid Fire Context Switching

A Word on Context Switching, as we all know from multi-threading, semaphores, and operating systems doing parallel workloads and switching context overloads the CPU and slows down processing, not to mention overcomplicating the design. In technology, today’s business requires engineers to do context switches daily as “leaders” continue randomly to change directions in technology, platform-hopping, or major requirements revelations. This can range from minor interruptions to more drastic changes like: “We move all our applications from Heroku to Azure and .Net”. Here is my personal story that hopefully will clarify how such switching affects our lives.

A few years ago I was attending a tech-conference event, where I met up with three groups of developers who all spoke different languages. I took part in a friendly conversation among Japanese, Russian, and English speakers. I humbly found myself helping to interpret all three languages. After about 30 minutes of this fun & technical communication with these very diverse language groups, I started to feel sudden exhaustion and needed to step out to decompress. This shows how a simple friendly conversation with context switching in three natural languages turned into very hard work for my seemingly inferior biological Neural-Net brain. I started to go down this self-pity path, I am not skilled enough in these languages, and my brain just cannot handle this load and other downward thoughts.

To solve this puzzle I started to look for a reason, surely I thought if I was growing up immersed in these three languages and spoke all of them native then it should be no problem, right? The answer was closer than I thought, I knew somebody who had grown up in multiple regions and went through several international schools being native in Japanese, Chinese, English & French. This individual was also working as a professional interpreter. Bingo, I found someone I can get a confirmation, and I did ask about this language-context-switching. To my surprise, I was explained that a professional live interpreter (those you may see at events in booth translating) doing work but only 10-15 min MAX then person switch and rest. Simply because such context switching is not sustainable for long time periods with intensity and conversation speed. Our brains cannot handle this.

I concluded that if a professional interpreter with native language skills cannot handle such switches, something similar occurs when we switch programming languages or platforms. When building API in JavaScript, Application code in Swift, and server-side in Java, Apex, or Ruby, or APIs in MuleSoft. A developer is expected to switch not only languages but also development environments and tools (VSCode, XCode, Heroku, Salesforce, AWS, MuleSoft Anypoint, etc.). This is not productive and should be avoided. Obviously, in a large organization, there can be many teams that specialize in each one of these technology stacks that can make this easier or even more complicated with inter-human communications. From personal experience many smaller organizations or startups rely on few engineers to build products and a single engineer needs to build on all mentioned platforms and languages.

My humble request to our dearest leaders, when you think of the next “strategic” platform hop for whatever reason it may be, just maybe consider your humble developers and how they need to manage this context switching to accommodate these strategic shifts to build more value for the organization.