How I Reduced the Burden of Context Switching as a Software Developer
As a software engineer with many responsibilities, I’ve learned how to manage my time better
--
**PREVIOUS JOB**
I’m a software engineer working on code, infrastructure, and customer support while also being a leader in some projects. Monitoring emails, debugging code, deploying applications, architecting systems, preparing presentations, documentation, discussing ideas with other peers— the list goes on. It’s hectic at times.
In a 2009 paper, Sophie Leroy explored the challenges of attention residue when switching between work tasks.
“We need to fully disengage from one activity before we can jump to another. Otherwise, performance will suffer.”
Sometimes I leave unfinished work, which creates this sense of accomplishing nothing in the day. And although I get things done and commit to our deadlines, the quality can get suboptimal at times, which is frustrating.
The other day, I stopped for a moment and thought of my or the team’s behaviour, processes, and other practices required to do our job or that helped us overcome situations throughout the years. Here is what comes to mind.
Implement “Person of the Day”
Our team implemented the “Person of the Day” process for a short period, and it helped us reduce context switching and improve our focus.
Two main activities, customer support and infrastructure, were getting out of control. We were not handling them well, along with all the other stuff. We were missing requests entirely or taking too long to respond. Plus, we didn’t have level 2 support.
Person of the Day means that each day, a team member would only work on customer support and infrastructure—nothing else. There was also a backup resource in case the person was absent.
These were the activities of the Person of the Day:
- Watch email traffic and resolve any support cases. If in doubt about how to handle it, contact another team member for help.
- Monitor infrastructure, which includes web servers, applications, automated jobs, and overall system performance.
- Do not get involved in any software development activity so it doesn’t divert from the process.
- Help to remove any blockages from other participants.
- In case of unavailability, let everyone know about it. The backup resource must then be assigned.
Let Go of Perfection
I’m a great believer in doing, improving, and repeating. The irony is that this way of approaching things is perfect for an environment where you have to wear multiple hats and act quickly.
I’m very comfortable at my job, and as time passes, I learn and make better and quicker decisions.
Ultimately, we get our things done and working most of the time, and that’s enough. In a later step, as a separate project, we improve our code or documentation.
Focus on the Solution, Not on Who’s To Blame
In the face of a problem, there is no time for questions such as “Who did this?” or “Why did you decide to call web service A versus B?” They add no value to finding a solution. We concentrate all of our efforts on resolving the problem, then we tackle the root cause afterwards, which — don’t get me wrong — is of the utmost importance.
And to make it clear, finding the root cause doesn’t mean blaming someone.
Other Practices
If it takes five minutes or less, do it now
This is something I do not to accumulate too many activities on my plate. It also alleviates the perception of getting nothing done.
Sometimes, the five minutes turn into one hour, but I’ve become better at identifying those cases.
Before switching to another task, take notes on what you’re doing
It improves the attention residue effects of context switching. When I’m interrupted and then try to go back to the previous activity, I always forget what I was doing. Taking a snapshot of my current state helps me a lot.
Before moving to check why some users cannot connect to one of our web services, I write down what I have completed so far in a new implementation I’m working on, for example. For instance, “I’m working on web service XYZ. I finished the controller and the business logic, and now I’m facing an issue with the input validation.”
When I return to the previous task, the cognitive load is lighter because I spend less time remembering what I am doing.
Conclusion
In the beginning, I mentioned that I wasn’t sure I wanted to be considered good at handling multiple tasks. That’s because I don’t like it, and it’s my dream to focus more on software architecture and leadership/management only (which is already a lot of work, by the way).
But it’s fine. I’m at peace with it. I think I will continue working in this setting because it’s become my comfort zone. It’s on me, in some sense. To be brutally honest, I like the visibility and being exposed (not when something bad happens, though). I also like having many options and projects because it increases my chances of excelling, at least in a few areas.
In general, from a team perspective, we have been making a ton of progress in automating and documenting our processes and applications. We’ve been slowly upgrading our technology stack as well, which is always a good thing. At the end of the day, I like my job.
**PREVIOUS JOB**
