Slashdot Mirror
Multitasking Harmful To Productivity
Greyfox writes: "According to a CNN article, a person who is multitasking several things takes a hit on his productivity. Oddly enough, it reads almost exactly like a description of the problem with multitasking on computers; context switches cost, especially if you have to swap a lot of crap out in order to fit the new process into memory. So basically, an employee who can stay focussed on one thing for long periods of time is going to have higher productivity than one who has to handle constant interrupts. Now if I could get my manager to buy into that ..."
There's a running joe that James' century old work represents basically everything cognitive scientists know today. In other words, not much new progress in the last 100 years. :) Anyways, to quote from James' book, chapter 11 (emphasis mine):
[p. 409] If, then, by the original question, how many ideas or things can we attend to at once, be meant how many entirely disconnected systems or processes of conception can go on simultaneously, the answer is, not easily more than one, unless the processes are very habitual; but then two, or even three, without very much oscillation of the attention. Where, however, the processes are less automatic, as in the story of Julius Caesar dictating four letters whilst he writes a fifth,[9] there must be a rapid oscillation of the mind from one to the next, and no consequent gain of time. Within any one of the systems the parts may be numberless, but we attend to them collectively when we conceive the whole which they form.
When the things to be attended to are small sensations, and when the effort is to be exact in noting them, it is found that attention to one interferes a good deal with the perception of the other. A good deal of fine work has been done in this field, of which I must give some account.
It has long been noticed, when expectant attention is concentrated upon one of two sensations, that the other one is apt to be displaced from consciousness for a moment and to appear subsequent; although in reality the two may have been contemporaneous events...
Chad Loder
Rapid 7, Inc.
The next generation of network security products
A discussion of "multitasking for programmers" and why it hurts is at Distraction: the one big obstacle. This is written for programmers, but it is true for everbyody who works with knowledge.
You found a sword: +4 damage, +5 moderator points
I can't. I have CAPD(Central Audiotory Processing Disorder). I could spit it out, if I knew what he was asking, but that's what I can't do, make sense of what I hear. If I'm doing ANYTHING else, I don't understand what somebody is saying to me, be it hitting something with a hammer, reading a book, coding, looking at a wall, if my attention is even remotely used for something else, I can't hear people.
That includes thinking of what to say when they're done talking, or if they get me thinking of something else. It's really annoying, actually. That's why I can't do the phone-monkey thing.It does have its advantages, though. I'm not easily interrupted when doing work, I don't hear people talking to me when I don't want to, it's not ignoring, it's involentary, but convenient at times. I have not trouble visiting my own little world.
God save our Queen, and Heaven bless The Maple Leaf Forever!
Where I work we don't have any specific rules about this kind of thing so things happen both ways, but on the one project where one other guy and I are working side by side on a piece of code, our productivity jumps thru the roof, and not only do we get MUCH more done, the code we produce comes back from QA with almost none(or in several cases Zero) defects. I think alot of it has to do with us catching each others dumb mistakes, and i don't just mean missing ';' or other things that compilers will check (In fact we had to teach our selves to igonor such problems when the other was typing becuase by the end of the day we woudl want to kill each other) We will catch simple logic errors and flawed assumptions as the come up because each of us already has an idea of what the code will look like, and if the other does something completly strange we can discuss it and figure out if its the right thing to do, all before its ever finished. There is nothing worse than digging thru 5k lines of code looking for weird logic erros.
Right on. However, the researchers here seem to have a rather simplistic, one-dimensional view of multitasking.
(OK, sound research starts by validating a few simple concepts, then building more complex structures later. But seriously, eight years of research, for merely this? I guess they've got to keep some ideas in their back pockets, ready for a next round of grants.)
There are two ways multitasking can happen: chosen swapout of tasks (you mention waiting for something to finish, but it might be waiting for anything - email reply, phone callback, etc.), and imposed interruptions (phone, instant-message, chatty boss/coworker, and so on). Swapouts are like enqueue-wait swaps on a mainframe - you know it's going to be awhile before you can resume that task, so you turn to something else. Interruptions are like, well... I/O interrupts - they demand immediate attention, whether or not its convenient at the moment. Swapouts tend to _improve_ efficiency generally, and so does minimal servicing of trivial I/O interrupts. Continuing the mainframe analogy, a first-level I/O interrupt handler merely fills a buffer and posts an ACK, then exits; these don't seriously degrade scheduling. What hurts productivity are interrupts that are forced as untimely swapouts of important, hard tasks.
A long time ago, I did some applications programming in COBOL for a S&L. (Yeah, I know COBOL sucks, but it paid the mortgage and I also taught myself IBM S/360 ASM during the same period.) Anyway, I was easily the most productive programmer in the shop, because I always had at least three and sometimes half a dozen projects ongoing at once. This was back when you were lucky to get two compilations of any one program per day. So, I'd code in one program, submit it for compile, and go on to coding in another program. It was quite effective, swapping tasks that way. Of course, it also helped that the programs were usually related.
As with many things, the real issue here is empowerment. Workers who can choose when to swap out tasks and turn to other ones will always be more productive (and happier) than those who are constantly interrupt-driven and never get to take anything to a "stopping point." This seems obvious: it's why you don't have the Help Desk do any network engineering or complex programming.