Switching Between Projects

This is a repost from my old blog thecompilerdoesntcare.com and was originally posted in 2017.

These last few months I have been off my regular project because of a lower-than-usual amount of tasks. Not enough to keep all four of us on my team busy full time. This means that I have spent around 200 hours on projects other than the one I’m usually working on.

In this post I’ll talk a little bit about my experience jumping between projects and why I think it’s a good idea to do, every once in a while.

The Technology

The project I usually work on is a spanking new .NET Core ASP.NET MVC project, that I have been on since it started, around a year and a half ago. Since that project started, I have not really worked on anything else while this project ran.

A few months ago it was delivered, and we switched to maintenance-mode. This switch in daily workflow created a vacuum, and suddenly we did not have enough new features to keep the whole team busy.
This is most likely just a transition period, and will soon change as all the feature request in the pipeline are matured and ready to be implemented.
In the meantime though, I have been rotating to fill in holes on other projects.
It’s never fun to be removed from a well-functioning and gelled team, but this was actually an experience that worked to my benefit.

First, I was assigned to one of the oldest projects in the company – a Web Forms project in Visual Basic. Also, built on a previous version of our own platform, which I had no experience with at all.
Not being an veteran developer, I have never had anything to do with the older .NET stuff like VB and Web Forms.
I was in a situation where I had to learn a lot of new stuff at once. I wasn’t thrilled, because I’m currently studying for a C# certification, so the timing wasn’t great. But it turned out to be a lot of fun to learn a new language and framework (even though it turned out not to be that different). This put the things I usually work with in perspective, and have actually made me a better C# developer. Some things seemed to click while working on a new (old) strange platform.

Rapid Understanding

After this first fairly large (100 hours) task was done, I was back on newer C# projects. The tasks there were smaller, but I was still jumping from project to project. Now the technology wasn’t the problem – the unknown codebases were.

I would get a task in a project and would have to figure out a solution, mostly on my own. When I had come up with one, I would discuss it with one of the developers on project – and then I would start.
The benefits from jumping in and out of codebases were two-fold. The benefit for me was huge, because I had make sense of the existing code quickly, and I got pretty adept at this. That is a great skill to have in my bag for the future.

The second one, was on the projects that I did tasks on, because I had to look closely at the code, and figure out what it did, I functioned as a fresh pair of eyes, and spotted many low hanging fruits (like refactorings, that greatly improved readability), which heightened quality of the code in the project.
Often, when you are on the same project for a while, you grow blind to some things, so this wasn’t the other developers that were doing a bad job or anything. I think they just didn’t see some of the stuff. (Just like I don’t see the mess on my desk anymore).
I looked very closely at some stuff that they probably don’t look at all, because they know how everything works. I needed to dig around in it to understand it.

Conclusion

The need for me to jump around on projects was not an optimal situation, I was told by my Team Lead. And that is how I felt too, before it started.
It turned out that it was beneficial, both for myself, but also for the projects I worked on.
My biggest fear was distancing myself from my regular team, but I was actually able to keep my physical spot next to them, but still I was able to work closely with some of the developers that I don’t usually work with – which has widened my social circle at work, and that’s great too!
I have actually gotten so much out of this time, that I would recommend every developer to do this regularly!
How often and for how long is hard to say, but I think maybe a month a year or two weeks twice a year would be appropriate – the length and frequency might not matter much, as long as it just done, though.

Mikkel Secher

Mikkel Secher