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 |
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.
comments.
Very interesting reading and a great learning experience! I must also say, the presentation of
posts are simple yet elegant starting with simple introduction and a catchy photograph (with
white background) followed by elaboration of the topic with further references.
Few points popped up in my mind when you wrote about multi-tasking. It's usual that we are
multi-tasking human beings but few factors decides whether we should do multi-tasking or
not :
* Qualifying as a task : For an employee's (say the senior programmer's) point of view,
it's important how does (s)he define a task. Some tasks are assigned by the manager
and some are personal. e.g. Reading a blog might be self-assigned task for this
programmer but for her/his manager it does not qualify as a task. Though a manager
does not assign multiple tasks, each of us are usually multi-tasking individuals.
* Task Frequency : Some of the tasks are recurring in nature and some are to be done
only once. Since we are comfortable with know-how of recurring tasks, think-time
preceding and succeeding recurring task is less and it's easy to switch between tasks.
But for the unique tasks think-time is more and therefore it becomes difficult to
switch. e.g. entering a timesheet (recurring task) has little think time but doing a
design for a new module (unique task) might require much more think. So it's easy to
get few recurring tasks done in between unique tasks but nor vice-versa.
* Task Size (Duration) : Third point important point is task size. If proposing
architectural solution is a task, it would probably span over several days/weeks. But a
simple bug fix may take only few minutes. So it might be quite logical to take few
simple tasks in between a large task (maybe few reviews, reading books etc) as the
total switch time is negligible compared to the entire task size. But taking other tasks
does not make sense for a short duration task as the switch time is very high.
* Nature of the task : A monolithic task might be monotonous and boring. Few simpler
different tasks may bring fresh thoughts and makes the entire experience more
enjoyable. e.g., reading specifications for continuous few days might be boring, so it's
better to do some design along with reading specifications.
Keep blogging...I am sure there are other followers who likes reading your blog like me...
Interesting points. Here are my thoughts on some of the points you mentioned.
> Though a manager does not assign multiple tasks, each of us is usually multi-tasking
Research shows that you when multitask you lose; mixing personal tasks and professional is even more dangerous. Personally I prefer to keep dedicated hours of the day for personal tasks like blog reading, responding to personal email etc. and dedicated hours for work.
Of course, work has a tendency to get into the dedicated time for self-development and personal activity but dedicated time-slots, maintained well, are supposed to be more effective.
> Entering a timesheet (recurring task) has little think time but doing a design for a new module (unique task) might require much more thinking.
But trying to submit a timesheet while designing a new module is dangerous; the perils of multitasking don’t become less even if both tasks are recurring in nature; for example, answering cell phones and driving are both recurring and simple but fairly risky when done together.
> So it's easy to get few recurring tasks done in between unique tasks but nor vice-versa.
We think it’s easy. Research shows it’s not. It’s tempting but doesn’t work all that well. Kathy’s article has more details. The basic point her article (http://headrush.typepad.com/creating_passionate_users/2006/03/multitasking_ma.html) makes is that these things bring down productivity.
> Third point important point is task size. If proposing architectural solution is a task, it would probably span over several days/weeks.
I wouldn’t consider proposing an architectural solution a task. It’s more like a collection of tasks. David Allen in his ‘Getting Things Done Fast: The Ultimate Stress-free Productivity System’ (http://www.amazon.com/exec/obidos/ASIN/B000JZ7PMW/thousandtyone-20) refers to tasks like these as ‘projects’.
The trick is to break it up into smaller tasks before you set out to conquer them (https://www.thousandtyone.com/blog/AreYouStuckWithAProblemDivideAndConquer.aspx). When you’re done with a few of those small tasks and have brought a few of them to a logical end do a task switch move over to something unconnected it you must. The key is to work in serial, not parallel.
> A monolithic task might be monotonous and boring. Few simpler different tasks may bring fresh thoughts and makes the entire experience more enjoyable.
Again, divide and conquer. I think we’re saying the same thing here but in different ways. Break the specification into smaller sections and commit to reading a section for a dedicated amount of time; but then when a buddy pops up on the Yahoo Messenger and says ‘Hi’ tell him to wait. This post wasn’t about completing the whole spec read at once. It was about making sure you have your Yahoo Messenger turned off when you dedicate time to reading the specification. I think that’s where most of us lose out. :)
We were meant to spent decent amount of time on a task before we hoped on to the next task. When we multitask we’re just spend very small amount of time on one thing before we hop on to something else. This post was about increasing that time spent on one thing at a time and avoiding distractions.
Always a pleasure to get some more thoughts added on to the initial post. That’s for taking out the time to comment and not being remaining a ‘silent follower’ of this blog. :)
Dheeman,
> Has Rajiv Popat, I saw, have changed?? The person who used to work during late hours of the night virtually every day; Apart from official work he used to work in some source-forge projects, write blog entries.... and lots on.
Of course I’ve changed. Don’t you see the change in the frequency of posts that are coming out? We should all continue to change and we should continue to thank god for the changes. It’s called self improvement. :)
I’m working harder on work and this blog. Work on a couple of open source initiatives will be increased very soon too.
Having said that, these constant changes have nothing to do with the multitasking that was described in this post. In fact, I’ve been trying to get more done in less time and doing one-thing-at-a-time helps.
Comments are closed.