Context, in the sense we’ll talk about it here, is the set of information that is currently loaded into your short-term memory related to the task at hand. In computer terms, it’s your working set of pages that have been fetched into memory.
Computers have a distinct advantage over our mental architecture; they are built to swap context easily and naturally.
We aren’t built that way. If something interrupts us, breaks our flow, or causes us to lose our focus, it’s really expensive to drag everything back in. We call that “dragging everything back in” context switching. We’re going to take a look at why you want to avoid that at all costs, and how to avoid distractions and manage interruptions better.
How much disposable attention do you have?[145] That is, how many things are currently demanding your attention, and how many total things can you possibly pay attention to at any given point in time? The ratio is pretty unfavorable.
You can’t pay attention to as much as you think you can.
You can’t pay attention to too many different things at once, because to change your focus from one item to another means you have to switch context. And unfortunately, our brains just aren’t wired to support context switching very well.
Multitasking takes a heavy toll on productivity. One study[146] found that in general, multitasking can cost you 20 to 40 percent of your productivity. Right there, that cuts your eight-hour workday down to five. Other studies bump that number up closer to 50 percent, with a huge increase in errors, as well.
Just to clarify, multitasking here refers to performing multiple concurrent tasks at different levels of abstraction. Fixing a couple of bugs while in the same area of code doesn’t count as multitasking, nor does returning several similar phone calls or cooking a multicourse meal. You get into trouble when you interrupt your code-fixing session by responding to an unrelated IM, email, or phone call or take a quick peek at a news site.
Unlike computers, our brains don’t have a “save stack” or “reload stack” operation. Instead, you have to drag all the bits of memory back in, sort of one-by-one. That means that if you are deep into a task (such as debugging) and then get interrupted, it can take you an average of twenty minutes to get back into it. Twenty minutes. Consider how many interruptions you may get in a given day; if each interruption requires twenty minutes for you to recover, a good portion of your day is just plain wasted. This could explain why programmers in general hate to be interrupted—especially by nonprogrammers.
It takes twenty minutes to reload context.
In today’s digital culture, this is part of a larger, dangerous phenomenon known as cognitive overload. It’s a cocktail of stress, too much multitasking, too many distractions, and the frequent flurry of new data to deal with. Scientists agree that trying to focus on several things at once means you’ll do poorly at each of them.[147]
And if that wasn’t bad enough, a controversial study done in the United Kingdom noted that if you constantly interrupt your task to check email or respond to an IM text message, your effective IQ drops ten points.
By comparison, smoking a marijuana joint drops your IQ a mere four points (see Figure 26, Relative IQ point loss).
Whatever you do, please don’t do both.
This makes me wonder if companies should focus less on mandatory drug testing and perhaps instead concentrate on mandatory email-habit testing.[148] But of course it’s not just about email and drugs; drivers conversing on cell phones cannot respond quickly to highway hazards, either. Television news channels overflow with different news stories on the main screen, small video insets, and a couple of scrolling headlines, all separated by commercials for dancing toilet paper. From a cognitive science point of view, that’s just plain torture.
Given that we’re so bad at handling multiple things at once and that we are very easily distracted by a myriad of technical marvels, let’s take a look at how to avoid some common distractions and stay on task.
In an episode of All Things Considered on NPR, Paul Ford extolled the benefits of a spartan user interface.[149] Consider an early word processor such as WordStar or WordPerfect on an early text-based operating system (CP/M, MS-DOS, et al). There were no windows. No mouse. No email, no games. A working setup that is so bland, it turns out to be inspiring. Or more precisely, it’s a setup that helps you maintain your focus on the task at hand.
One of my favorite tools for portable writing is my Sharp Zaurus. Toward the end of its life, I ended up taking everything off of it except the vi editor. I took off the wireless card and synchronized it using only the CF memory card. This left me with a device with very few distractions; there is literally nothing else to do on it except write. No games, no email, no Web—just the chapters and bits of text on which you’re working. It’s spartan but effective.
On a more full-featured system, you can run a specialized application to hide everything except the one application you’re currently using. For instance, on the Mac you can use Think![150] to black out every application other than the one that has focus, or DeskTopple,[151] which can hide your desktop icons, replace your wallpaper, and autohide application windows on a timer.
Under Mac OS X, you can use the utility QuickSilver to set up globally accessible keystroke-based commands. It reminds me of the terminate-and-stay-resident program SideKick on those early systems.
For instance, I have it rigged so that with just a few keystrokes I can send a one-line email message to someone in my address book. Now on the surface of it, this doesn’t sound like much. However, being able to send an email message without bringing up all of Mail is a huge advantage.
Say you’re in the middle of some other task. You get the sudden thought that you have to send an email to someone. Perhaps you’re in the middle of debugging an application and you realize you will be late for a lunch appointment. You press a few keys, send off the mail, and get back to debugging.
Now compare that to the usual experience.
You’re in the middle of debugging, and you realize you have to send an e-mail. You context switch to the Mail application, bring it up, start to send the email, and notice several new emails have come into your inbox, and now the distraction is right in front of you. You will quickly become ensnared by the new email messages and lose your train of debugging thought. Context blown.
In a similar vein, I have Quicksilver rigged so that I can add a line to my to-do list with just a few keystrokes. Otherwise, you run the same risk as with email. You have to turn your context to the to-do list, and as soon as you’re there to type in your new entry, you see all the other things you’re supposed to be doing, and once again you are distracted.
You can do the same sort of thing in Linux by keeping a small terminal window open with a shell script that will add to your to-do list.
When you have a thought, it’s much better to send it to where it belongs—whether that’s the to-do list or email—and then get right back to what you’re doing.
While we’re talking about streamlining your interface and work habits, we’ll have to take an obligatory tangent to discuss GTD.
David Allen’s Getting Things Done: The Art of Stress-Free Productivity [All02], known by the acronym GTD, is a hugely popular book/method/cult aimed at helping you organize, prioritize, and effectively complete your work.
He supplies a methodology and a lot of tips and tricks (who knew a labeler could be so much fun) to help you be more efficient at plowing through tasks.
In terms of the ideas we’ve looked at here, Allen makes three critical points. The first two have to do with processing email or other inbox-related piles, the last is a more general note:
Scan the input queue only once: Whatever input queue you are dealing with, be it in an email inbox, voicemail, or paper inbox, don’t use the arrival box as a storage device. Go through and sort the new arrivals into whatever piles are necessary, but don’t keep rescanning the same old stuff in the input queue. If it’s something that can be dispatched in less than two minutes, then do it and get it over with, or pawn it off on someone else entirely if you can (aka delegation). Constantly reviewing the same 1,000 inbox messages to work on the last 20 important ones just wastes your time and mental energy.
Process each pile of work in order: Once you have your piles, work them. Stay on task, and avoid context switching. As we saw earlier, switching to another task will blow your mental stack, and you’ll lose more time as you get back into the task. We programmer types are highly susceptible to being distracted by shiny things. Stick to your pile.
Don’t keep lists in your head: Allen spots another important aspect of maintaining an exocortex. Dynamic refresh of mental lists is very expensive. Instead, keep to-do lists and such somewhere in your exocortex—on a sticky note, in a wiki, in a calendaring or dedicated to-do list tool, or in something similar.
The GTD method has a lot of fans, and if effective prioritizing and task organization are the sort of thing you have trouble with, GTD might help.