Pay attention young programmers, this is the most important piece of programming advice you will ever hear.
Well perhaps not, but it might be the most important piece of programming advice you hear today.
“Switching gears is grinding gears.”
I’ve been doing this programming thing for quite a while now, and I have come to realize that the biggest thing that saps my productivity is switching gears.
What do I mean by switching gears?
Many different contexts
Switching gears can apply to a variety of different contexts, but it is basically whenever you are working on some task or technology and have to stop what you are doing and either do something else or change the type of thing you are doing.
This is really a bit different than multi-tasking. Multi-tasking is really trying to do more than one thing at once. It usually involves a large amount of rapid context switches, but for this post I am more concerned about the general idea of breaking rhythm.
I think it is easier to speak about this subject if we talk about some specific applications of the idea and why they are harmful.
Switching problems
In the Agile world of software development today, we often are required to switch from problem domain to problem domain as many of our iterations contain mixes of different features on different parts of the system and bugs to be fixed.
Have you ever been in the situation where you were just beginning to understand how some area of the code base worked, or how to work with a particular customer on a particular problem space and then had to switch to something else and start all over again?
Even when you switch back to the original context you were working with, if enough time goes by, it becomes new again. You have to relearn much of what you had learned the last time and just when you begin to hit your groove, the cycle begins again.
This form of switching gears is at the very least frustrating, and at the most a complete demotivator and productivity sapper.
Unfortunately for most developers, this problem is out of your immediate control. But, take note product owners and project managers, there is a reason why iterations should have a goal.
If you are in the precarious position of being a developer pinned against the ropes, try to make some noise and let your management and product owners know that your team will be much more efficient when you aren’t switching gears all the time.
In my experience, the results of replacing this constant context switching with the synergy of a common goal and related features in a segment of time has an astounding effect on productivity that is hard for any serious businessperson to ignore. So speak up!
Switching technology
This is the primary reason why I have a distaste for JavaScript. It is why even in this abundance of web development, I would still rather program a client application.
Switching technology is painful!
This is one of those things that is unavoidable in todays development environment. If you are a web developer, you are going to be working with HTML, JavaScript, probably some sort of server side language, and most likely some form of SQL.
It really isn’t worth trying to fight this because you are going to be going against the technology grain to do so. Although, I do suppose this may be one of the reasons for the recent popularity of Node.js.
What we can try to do is to minimize the context switch as much as possible. We do this by sticking with a particular way of doing things and not chasing after each new technology of JavaScript framework that comes out each week.
I’m not saying to not learn new things. It is very important to always be learning.
What I am saying, is to try to find some kind of rhythm with the technology stack you are working with and try not to switch that up.
Technology specific training can really help here as well. I for one, need to learn JQuery better. The problem is that when I am working on a web based feature, I am not forced to learn JQuery because I am not in that context long enough.
So what do I do instead?
I waste time Googling for answers. I know that I have a short coming here and I need to just bite the bullet and spend some dedicated time to really thoroughly learn JQuery, because by Googling for little pieces of it at a time, I am not really making much headway and the context switch ends up stealing what I do learn from my memory.
One more aspect of this is the idea of focused teams. Many software development groups do not like to specialize their developers onto one focus area. I agree whole-heartily with the idea of non-specialization.
But! There is huge benefit to be gained by keeping the same group of developers working on a specific set of technology or part of the code base for a set period of time. I’ll talk about this a bit more, towards the end of this post, but the basic idea is that it takes time for people to find their groove.
I think it is optimal to break any large team up into smaller technology area focused teams that regularly rotate every 3 months or so. The idea here is that you give those teams enough time to get good at what they are doing and actually commit what they have learned to memory, but you rotate them often enough that they don’t end up becoming specialists which are unable to see the whole picture.
Switching teams
This one typically isn’t an issue, but it can be depending on the environment that you are working in.
Teams need enough time to go through that forming, storming, and norming set of phases. If you are constantly interrupting this process by switching around team members, you are never going to get the team to act as an entity of its own.
Teams are generally more efficient than individuals, because they benefit from synergy, when 1 + 1 = more than 2.
But just like a big truck taking some time to get up speed, a team takes time to get going. Also like a big truck, a team can gain momentum that individual developers seldom can achieve.
A smaller aspect of this is pair programming. I suppose that many have been successful switching up programming pairs once a day or so, but I suppose that more teams have been successful switching up pairs at longer intervals.
For me, this interval varies. Sometimes, I feel like I need to stay paired with a teammate for longer than 2 weeks, which is our regular interval, sometimes 2 weeks is fine. It depends on what you are working on and how much momentum you have.
They key here is to make sure that you are giving teams enough time to take up their own flag and stake their territory. Teams can take some time to find their common goal. Self-direction can really help with this.
The groove
Ever tried to turn a flat head screw with a screwdriver, but it doesn’t quite turn, because you can’t seem to get the head of the screwdriver into the groove of the screw?
You twist that screwdriver around a bit until finally it slips into the groove. Then when you turn the screwdriver the screw turns with it.
As humans, we tend to be like screwdrivers, we have to find our groove. We all have this adjustment period where we are fumbling through things.
It is very important to make sure that we aren’t switching gears so often that we are not actually turning any screws once we are in the groove.
Regardless of what kind of context switching you are doing—whether it is problem domain, technology or teams—it is important to make sure that you are not spending 90% of your time finding the groove and only 10% of your time “in the groove.”
Depending on what you are doing and what the context switch is, the proper amount of time before switching contexts is going to vary, but I think it is very important be aware of this phenomenon and plan around it. If you don’t you are going to end up spinning your wheels, which is unfulfilling to say the least.