Switching Gears is Grinding Gears

Pay attention young programmers, this is the most important piece of programming advice you will ever hear.

\n\nWell perhaps not, but it might be the most important piece of programming advice you hear today.\n\n

“Switching gears is grinding gears.”

\n\n

\n\nI’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.\n\nWhat do I mean by switching gears?\n\n

\n\n

Many different contexts

\n\nSwitching 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.\n\nThis 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.\n\nI think it is easier to speak about this subject if we talk about some specific applications of the idea and why they are harmful.\n\n

\n\n

Switching problems

\n\nIn 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.\n\nHave 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?\n\nEven 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.\n\nThis form of switching gears is at the very least frustrating, and at the most a complete demotivator and productivity sapper.\n\nUnfortunately 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.\n\nIf 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.\n\nIn 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!\n\n\n\n

Switching technology

\n\nThis 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.\n\nSwitching technology is painful!\n\nThis 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.\n\nIt 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.\n\nWhat 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.\n\nI’m not saying to not learn new things.  It is very important to always be learning.\n\nWhat 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.\n\nTechnology 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.\n\nSo what do I do instead?\n\nI 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.\n\nOne 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.  \n\nBut!  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.\n\nI 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.\n\n

Switching teams

\n\nThis one typically isn’t an issue, but it can be depending on the environment that you are working in.\n\nTeams 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.\n\nTeams are generally more efficient than individuals, because they benefit from synergy, when 1 + 1 = more than 2.\n\nBut 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.\n\nA 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.\n\nFor 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.\n\nThey 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.\n\n

\n\n

The groove

\n\nEver 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?\n\n\n\nYou twist that screwdriver around a bit until finally it slips into the groove.  Then when you turn the screwdriver the screw turns with it.\n\nAs 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. \n\nIt 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.\n\nRegardless 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.”\n\nDepending 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.