Advertisements
Posted by: jsonmez | March 10, 2012

Switching Gears is Grinding Gears

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.”

gear-intro

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!

Clss_065

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?

This Shutterstock image #2798630 was downloaded on 3-13-07 for HSW: QUICK FIXES FOR YOUR HOME, 730175.

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.

Advertisements

Responses

  1. Thanks for this.

    • Your welcome

  2. I find it very true that context switches are really taxing. While it’s more important to remove the causes of too much switching it helps the symptoms a bit if you take a break proper or do a bit of meditation.

    I find it most helpful to *not* to think about anything and especially not the things you are working on. Either focusing on meditation or just letting my mind drift, yet not following the thoughts that come up. This way I defragment my thoughts. I need to let my unconscious mind to catch up w/all the data I crammed inside of my head and it’s not helping if I push more data in before what’s inside has been somewhat processed.

    • Excellent point, Susanna, I agree. The idea of defragmenting your brain is very interesting as well. Often on Fridays I feel like I have all these bits and pieces of things that are cluttering my head and I need to sweep them up.

  3. I once worked in an environment where what you call “switching problems” was a constant source of annoyance for me. I actually made a spreadsheet where I recorded what I did each day, but built in a half hour of time for each task switch as “waste”. After a couple of months, I started making estimates based on the amount of waste, and when asked about it, I showed my manager at the time that in an 8 hour day, 2-3 hours went to waste.

    This actually led to a concerted attempt to minimize the waste. So, I would say that if you’re plagued by these sorts of things externally, documenting is your best friend.

  4. The worst for me is switching types of tasks. For example if I’m coding and then have to do some project management task like checking on bugs. Throw that in with meetings or documentation and I’m doing u-turns all day long.

  5. Well said,

    I changed jobs about 7 months ago from a straight .Net shop (I had just started to introduce the team to PHP so we could get WordPress off the ground for some quick tasks) to a shop where we have some old VB.net code, a new site running C#/EF/LINQ, another site running sold old homegrown PHP, as well as some new PHP/CodeIgniter/PyroCMS work.

    This constant jump was a KILLER to me, especially since I hadn’t really honed in on my PHP or MVC skills yet. Plus being a remote working, largely on my own, sometimes tracking down the proper resources or answers was difficult.

    For me, the two things that have saved me are Personal Kanban and more recently Pomodoro. Using Kanban, I can outline the tasks I have to do, prioritize them, and easily jump boards to see which project has which tasks. That helps unload a lot out of my brain. Secondly, the Pomodoro allows me to focus on just one primary task for about 30 minutes at a time. I’m still trying to do a good job at the focusing part, but I let the e-mails float to the side and I can check them when I’m done working.

    The biggest help this has been is that if I have to jump midday from the PHP project to the .Net project (not a daily occurrence, but enough to be significant), I can time it within one of my Pomodoro slots, and I can mentally make the shift, without the chaos of being half way through something in PHP land and have my mind try to jump into .Net land.

    This has helped me get into the grooves a lot faster, and also made it easier for me to update my boss on the status of tasks/projects, because it’s all out of my head and onto the “digital paper.”

  6. paired programming – can’t bear the thought of someone tethered to me while i work, think, create, imagine, problem solve …


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: