free html hit counter
Posted on: Monday, 03 November 2008 by Rajiv Popat

One of my seniors told me something on the lines of - "Senior engineers are supposed to wear multiple hats and juggle multiple tasks at the same time"; the issue at hand was that I was not 'utilizing' the senior most members in my team to their fullest extent by not giving them multiple tasks to work on all at once. According to him, even though I had promoted these individuals I wasn't tapping into their full potential by pushing them to undertake multiple tasks at once.

This particular senior of mine believed that all senior members in all teams should multitask and if they couldn't, they weren't senior enough to be promoted to the position of senior programmers. He wanted, expected and demanded that anyone who was to be promoted as a senior programmer had to be a serious, mind-blowing, kick ass juggler when it came to handling multiple tasks as once before he was lifted to the position of a senior programmer or promoted.

During the early parts of my career I had been a ruthless multitasking guy myself. The obvious expectation from someone like me was that I would push multiple members in my team towards multitask as well, but then something creepy happened. All the multitasking that I was doing was starting to have it's toll on me.

There would be days at a stretch when I would stare at the monitor losing a track of what it is that I was doing and what I was supposed to be doing next. I had taken multitasking to the next level and was suffering through what can be, most aptly, defined as the ALT-Tab-Syndrome. That is when I started realizing how expensive a human context or task switch was.

In his article on human task switch Joel Spolsky explains how harmful human multitasking is by comparing it with multitasking on computers. He argues that both are expensive and the only thing they do is provide is a perception of speed, not actual increase in speed or productivity. He explains:

OK, back to the more interesting topic of managing humans, not CPUs. The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That's because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code. If you send that programmer to Crete for a three week vacation, they will forget it all. The human brain seems to move it out of short-term RAM and swaps it out onto a backup tape where it takes forever to retrieve.

In his post, Joel basically pushes the idea that human multitasking in all it's form is not as productive as working on one-thing-at-a-time. In fact Joel feels it's harmful.  

G. Wade Johnson argues that what Joel is talking about can be described as preemptive programming. Wade on the other hand, introduces another form of multitasking where he talks about utilizing multitasking to utilize idle time:

An interrupt forces a task-switch. You incur all of the overhead of changing state, just like in the time-slice case. In fact interrupts are worse for humans than for computers. If you know you will be changing tasks after lunch, you can generally aim for a good place to stop. With an interrupt, you have no choice of when it occurs.

On the other hand, I try to keep one major task and two or three minor tasks on my plate at all times. This way, when something causes me to block on the major task, (waiting on technical or business input, lack of some resource, a design problem that I just can't seem to beat right now) I can spend some time on the minor tasks. Every minor task I complete, is one more thing that actually gets finished. That way I don't spend the blocked time busy waiting (browsing the web, reading slashdot, etc <grin>).

As valid as Wade's point seems, I've been a first hand example of what happens when you try to utilize and squeeze out every second of your idle item. Human RAM's are relatively limited in size, writing a few functions, firing a build that is going to take a minute to fire, reading a blog-post in that one minute and coming back to the code when the build is complete with all the variable names, function names and class names you were working with fresh in your head doesn't sound real life as well.

Kathy Sierra believes that the perils of multitasking aren't just limited to lowering the quality of the tasks that you are multitasking. According to her multitasking may have perils which are much more profound. She explains:

Where I once believed that the myth of multitasking was about time (that doing four things simultaneously takes much longer than to do those same four things in sequence), scientists now know it's also about quality. And it gets worse... it's not just that the quality of those four things in parallel will suffer, it's that your ability to think and learn may suffer. Some researchers believe that all this constant, warp-speed, always-on multitasking is causing young people, especially, to become less able to follow any topic deeply.

Kathy has indeed done her research on the topic really well. Go ahead, browse through her post and you'll get everyone from The Time Magazine to Jordan Grafman, chief of the cognitive neuroscience section at the National Institute of Neurological Disorders and Stroke, telling you that multitasking and being involved in too many things at once is harmful.

While I see countless young and ambitious engineers wanting to take on more and more projects, bigger and better challenges, grow in life and go places all at once, Kathy's post does a good job at reminding them their physical and mental limitations:

Whenever I talk about the big myth of multitasking, people always come up to tell me how they themselves just "have the kind of brain that can do this." Riiiiiight. They don't. I don't. You don't. And maybe you'd realize it if you turn off your cell phone, disable IM, mute the little "ding" alarm that says you've got email, and just sit there for a few moments.

The big problem for most young people, it seems, is that they don't know how to "just sit there." They get the shakes after just a few minutes without media stimulation.

What ever be the form of multitasking that you're doing; chances are that it is doing you or your work more harm than it is doing you or your work good; and that includes the kind of multitasking Wade explained in his post. As developers we tend to believe it's beneficial and we like to think we can handle it really well; but the truth of life is we can't. Kathy explains:

One of the most interesting things discussed in the Time article is that neuroscientists have established the specific area of the brain responsible for context switching. And unfortunately for some of us, it appears that this part of the brain performs less well as our brain ages. In a nutshell, the older we get, the less quickly and effectively we can multitask. But... most parents of teenagers already know that we have no frickin' idea how our kids manage to do what they do simultaneously. The key issue, though, is that while we now know they're better at it than we (the parents) are, they aren't half as good at it as they think they are.

And chances are, you aren't as good at it as you think you are.

The next time you fire a build and you feel this yearning temptation to read a blog post or reply to an email, ask yourself if you can handle the task-switch and come back to the build elegantly and completely when it's complete? If not, maybe you're just better off sitting there, admiring the build getting fired and slowing down a bit as you think about the next few lines of code you are going to write. After all you'll hardly get anywhere with just random multitasked speed.

If you're leading a team, if there is one lesson you can take back from this post, Joel describes it rather articulately:

As it turns out, if you give somebody two things to work on, you should be grateful if they "starve" one task and only work on one, because they're going to get more stuff done and finish the average task sooner. In fact, the real lesson from all this is that you should never let people work on more than one thing at once. Make sure they know what it is. Good managers see their responsibility as removing obstacles so that people can focus on one thing and really get it done. When emergencies come up, think about whether you can handle it yourself before you delegate it to a programmer who is deeply submersed in a project.

Are you still expecting your team members to multitask before you promote them? Are you only promoting your team members based on their multitasking abilities? Here's my advice to you: Don't use multitasking abilities as a measure for promotion.

Are you knitting your brows and telling yourself what a moron I am because you think that as you climb up the corporate ladder you have to multitask? Well, Multitasking is a real need in my job profile as well. I tend to give a very strong perception of multitasking when I work on multiple projects at once; but that's exactly what it is - a perception. Behind the curtains; I try my best not to multitask as long as possible.

A colleague recently told me that he was planning on picking up Ruby on Rails in the next three months while he also worked on something learning something else during those three months. My immediate response and suggestion to him had been that he should buy a Ruby On Rails book, stop learning the other thing that he was planning on learning and just focus on Ruby On Rails and finish it off in the next one and half month instead of three. Then he should consider moving to something else.

This is but, one simple example of avoiding the perils on multitasking. All situations in your life may not be as simple as this and I clearly don't have all the answers, but the biggest favor that you can do yourself is by starting to realize that human task switching is expensive and that multitasking in a real problem in our lives. Once you realize that, work consciously towards finding ways and means to avoid multitasking every time you can see an opportunity to avoid it.

Bottom line; whenever you have an option to avoid multitasking, avoid it.

The trick is to blind out everything else when you start with a task at hand and not look at anything other than the task as had till the task comes to a logical end where it's safe to switch to something else without having to keep too much about your first task in your head. Till you reach that point, don't open your outlook; close your browsers and if that stupid phone is ringing continuously switch it off too. Once you reach a logical end where you know it's ok to switch to another task, then by all means do; but random aimless multitasking in attempt to do too much in too little time gets you nowhere. Absolutely nowhere.

The Perils of multitasking are huge; both in software development and life in general. Multitasking is truly impacting and preventing us from being successful and happy; but you don't have to take my word for it; see Scott Berkun talk about attention and sex to help you decide for yourself.