Introduction

After more than a year of working as a full-stack software developer at a telecommunications company, I have experienced my fair share of having to handle multiple workloads. Whether it be code review, testing, or implementation tasks, there were times when juggling two or more tasks simultaneously was a common occurrence. Or rather, it's the norm.

I assume that you, the reader, are also a developer and are reading this article in the hope of learning new techniques to deal with this common challenge. In our daily work endeavors, we, as developers, are always encouraged to be more reactive, proactive, and take initiative. In other words, we are pushed to do more against the never-ending tasks and responsibilities that are tied to our backlogs and features to maintain and support.

In this article, i'll sharing a technique that i have been trying out and using recently to deal with the problems of context switching and dealing of urgent tasks that suddenly pop out of thin air. This technique involves organizing your repository file structure so it can be easily parked and also allow you to switch to different scopes without losing organization.

The problem

I work on a software system deployed with a microservices architecture strategy. This means that testing a feature requires running several microservice applications on your local computer. And being a full stack developer, testing is part of our job and responsibility. Now, in implementing new features, I'll be checking out a combination of different VCS branches from each service focused on the feature I'll be working with. Here, we can already sense the issue with my setup.

Suppose I have been codding for a few hours, and a more urgent task is raised that needs review ASAP. The review is of much more urgent and important than my current task. If I jump in directly and take the review, I know that I am going to lose my progress and will have to suffer the pain of having to switch context to understand the changes to be reviewed. Not only that, i would also have to checkout different branches on different services for testing out the feature. But I end up taking the review task anyway since the gods of the sprint board demand that the review be done and task be pushed to staging by the end of the afternoon for user acceptance testing by tomorrow morning. And after finishing the review, i had to setup my development environment once again.

The solution

After racking my brain and trying out different approaches to efficiently switch between development environments with different scopes without losing my temper because I checked out the wrong Git branch. I finally had an idea and i decided to try it out. The strategy involves maintaining different directories with clones of the repositories required for a certain task, whether it be for testing or developing a new feature. This way, whenever I take on another task or review while my current doing is not yet finished, I can easily park it and just switch directories.

The advantages that comes with this approach are:

• In terms of testing workloads, you can create folders for screenshots and text files for your testing findings and store them under their respective folders to keep things organized.
• It provides more agility and ease of organization since most file explorers already support drag and drop, and you can easily create more folders to cater to your setup.
• You can have confidence that when you switch back and forth between different development folders, it's just the way you left it.
• It saves you time and stress in switching out and setting up branches of different services.

To make things more meaningful, you can name the development environments based on what are their purpose and context. For example: fix-user-sigup-not-appearing-on-signup-page. I know that's a bad name, but you clearly get the point.

Conclusion

Dealing with the problems of context switching between workloads of different scopes is tough and taxing. A solution for this is to break down and organize separate directories of development environments, with each scope independent and different from one another. The advantage this approach gives is that you completely separate workloads with different contexts from one another, providing more agility when switching from one task to another. This also allows for a more focused and isolated environment of repositories and services that you can use whether you are working on implementing a new feature or reviewing new ones.