Productivity

Micro distractions

Posted on by John

Why are long articles easier to read on paper than on a screen? The explanations I’ve heard most often involve resolution or other properties of screens. But the culprit may not be the screen per se. It may be links, notifications, and other distractions.

Obviously if you follow a link you’ll won’t finish reading your original article as quickly (or possibly ever). But even when you don’t follow any links, you have to decide not to follow each link. These decisions are not as obvious a distraction as say constructi0n noise or flickering lights, but they are still distractions and they take a toll. That is the explanation Nicholas Carr gives in his new book The Shallows. (Sorry for the distraction.)

Paper books don’t offer readers many options, and that may be their strength. If you’re aware of things you could do to interact with an e-reader, you have to decide whether to take these actions. E-readers are expected to get better screen technology as well as ads in the near future. The ads may harm reading efficiency more than increased screen resolution will help.

Two kinds of multitasking

Posted on by John

People don’t task switch like computers do.

The earliest versions of Windows and Mac OS used cooperative multitasking. A Windows program would do some small unit of work in response to a message and then relinquish the CPU to the operating system until the program got another message. That worked well, as long as all programs were written with consideration for other programs and had no bugs. An inconsiderate (or inexperienced) programmer might do too much work in a message handling routine and monopolize the CPU. A bug resulting in an infinite loop would keep the program from ever letting other programs run.

Now desktop operating systems use preemptive multitasking. Unix used this form of multitasking from the beginning. Windows starting using preemptive multitasking with Windows NT and Windows 95. Macintosh gained preemptive multitasking with OS X. The operating system preempts programs to tell them it’s time to give another program a turn with the CPU. Programmers don’t have to think about handing over control of the CPU and so programs are easier to write. And if a program runs into an infinite loop, it only hurts itself.

Computers work better with preemptive multitasking, but people work better with cooperative multitasking.

If you want to micro-manage people, if you don’t trust them and want to protect yourself against their errors, treat them like machines. Interrupt them whenever you want. Preemptive task switching works great for machines.

But people take more than a millisecond to regain context. (See Mary Czerwinski’s comments on context re-acquisition.) People do much better if they have some control over when they stop one thing and start another.

Related post: Inside the multitasking and marijuana study

Inside the multitasking and marijuana study

Posted on by John

A study came out in 2005 saying that multitasking lowers your IQ more than smoking marijuana does. David Freedman interviewed Dr. Glenn Wilson, author of the study. Wilson’s first response was “Oh, that damned thing.”

Someone from Hewlett-Packard contacted Glenn Wilson and asked him to conduct the multitasking study.

Encouraged by his sponsor at HP to keep the budget extremely low, and assured there was no pretense of trying to obtain scientifically valid, peer-reviewable, journal-publishable results, Wilson dragged eight students into a quiet room one at a time and gave them a standard IQ test, and then gave each of them another one — except that the second time, he left either a phone ringing continuously in the room or a flashing notification of incoming e-mail on a computer monitor in front of them.

Wilson said “It didn’t prove much of anything, of course.” But the study made a huge splash.

I don’t imagine anyone would be surprised that a constantly ringing telephone would reduce your ability to concentrate on an IQ test.  And comparing the result to marijuana use is pure sensationalism. While hearing a phone ring and smoking marijuana both impair concentration, they’re obviously not comparable.

Artificial studies like this one fail to answer the more important question of what effect  voluntary multitasking has on creativity and productivity. As Tyler Cowen says

To sound intentionally petulant, the only multitasking that works for me is mine, mine, mine!  Until I see a study showing that self-chosen multitasking programs lower performance, I don’t see that the needle has budged.

Paul Graham made a similar observation.

The danger of a distraction depends not on how long it is, but on how much it scrambles your brain. A programmer can leave the office and go and get a sandwich without losing the code in his head. But the wrong kind of interruption can wipe your brain in 30 seconds.

I’m convinced that multitasking, even voluntary multitasking, does decrease creativity and productivity. But I reached that opinion from personal experience, not based on any study of people taking IQ tests while listening to a phone ring. And of course some activities pair more effectively than others. Sweeping floors while listening to an iPod works better than checking email while taking an IQ test.

Related posts

Acknowledging problems versus solving problems

Posted on by John

People want their problems acknowledged more than they want them solved, at least at first. That’s one of the points from Thomas Limoncelli’s book Time Management for System Administrators.

Suppose two system administrators get an email about similar problems. The first starts working on the problem right away and replies to the email a couple hours later saying the problem is fixed. The second replies immediately to say he understands the problem and will resolve it first thing tomorrow. The second system administrator will be more popular.

Of course people want their problems solved, and sooner is better than later. But first they want to know someone is listening. Sometimes that’s all they want.

Related posts

Not for everyone

Posted on by John

The expression “_____ isn’t for everyone” can sound snobbish. For example, if someone says that their favorite wine isn’t for everyone, are they really saying that not everyone has the refined taste that they do? Or if they say their favorite author isn’t for everyone, are they really saying that not everyone is smart enough to appreciate the books they enjoy?

But sometimes the expression is used humbly, as in Brian Carper’s article Emacs isn’t for everyone. There are some arrogant Emacs users out there, but Brian isn’t one of them, at least not as far as I can tell by reading his article. He simply discusses some of the pros and cons of the software and explains why some people would be better served by another tool.

I hope you’ll keep reading even if you have no interest in Emacs. This isn’t a post about Emacs per se. It’s about some of the things the article made me think of.

The majority of software development articles either advocate the author’s tool of choice or complain about a tool the author is forced to use. (See Ford-Chevy arguments in tech for a possible explanation.) Articles that frankly discuss pros and cons are rare. Here’s a sentence from the article I particularly liked.

Mastering an arcane text editor isn’t necessarily going to be on the top of the list of everyone’s goals in life, especially when there are other editors that are easier to use and give you a significant subset of what Emacs would give you.

That’s a far cry from “Maybe you’re not smart enough to use Emacs.”

I also appreciated that the article wasn’t overly pragmatic. It wasn’t just a dry cost-benefit analysis. Brian explains

I didn’t learn Emacs with the goal of being productive. I learned it for the same reason some people build cars in their garages, while most people just buy a one and drive it to and from work every day. … For me, productivity was a beneficial side-effect.

Every once in a while you’ll see someone say they use a tool for fun. For instance, I’ve heard several people say they were burned out on programming until they discovered Perl or Ruby. But it’s far more common for someone to say “This made me more productive.” than to honestly admit “I enjoy tinkering with this.” The two probably go hand in hand: you’ll probably be more productive using a tool you enjoy tinkering with even if in some objective sense it’s inferior to another tool.

Related posts

Losing patience with wastes of time

Posted on by John

Peter Bergman wrote an HBR blog post last week How (any Why) to Stop Multitasking. Bergman tried to stop multitasking for a week as an experiment. His post lists six benefits from his experiment including this observation:

I lost all patience for things I felt were not a good use of my time.

Multitasking can mask the pain of doing something that doesn’t need to be done.

Thanks to Neal Richter for pointing out this article.

Update: See this post on the study that Bergman quotes on how multitasking lowers your IQ more than smoking marijuana does. The study made a big splash even though it had a ridiculous design.

Related posts

Burnout

Posted on by John

Here’s the best explanation of burnout I’ve seen:

… burning out isn’t just about work load, it’s about work load being greater than the motivation to do work.

The context is a former consultant saying that heavy course loads at MIT did not burn him out, but an easy job doing dishonest consulting work did.

From The story BCG offered me $16,000 not to tell.

Related post: The most subtle of the seven deadly sins

Confusing familiar with simple

Posted on by John

Is Spanish simpler than Chinese? Most English speakers would think so, though that may not be true. Spanish is more familiar than Chinese if you’re an English speaker, but that does not mean the language is objectively simpler. In fact, linguists have a theory that all human languages are about equally complex, though they allocate their complexity in different areas. For example, Chinese has a complex tonal system, but I’ve been told its grammar is relatively simple.

We often confuse familiar with simple. Rich Hickey makes this observation in the context of programming languages, though the principle applies much more generally.

I think programmers have become inured to incidental complexity, in particular by confusing familiar or concise with simple. And when they encounter complexity, they consider it a challenge to overcome, rather than an obstacle to remove. Overcoming complexity isn’t work, it’s waste.

In some sense the familiar is simple. Familiar things have less perceived complexity, and sometimes perceived complexity is all that counts. But perceived complexity is personal. We can forget that familiarity clouds our judgment about complexity. We may recommend something familiar but complex to someone else who finds it unfamiliar and complex. Teachers have to keep in mind what students find complex. Programmers have to keep in mind what users find complex. Doctors have to keep in mind what patients find complex.

However, familiarity and perceived complexity can be deceiving even though no one else is involved. You may find something familiar and not realize how much effort you’re devoting to fighting its complexity. It’s easy to assume that things must be as complex as they are. I didn’t realize how complex clarinet was until I learned to play saxophone. I didn’t realize how complex C++ was until I had some experience with other programming languages. I didn’t realize how complex some desktop software was until I tried online alternatives.

The complexity of the familiar may not be apparent until you look closer. Nothing could be more familiar than the experience that the sun and planets go around the earth. That is a simple explanation until you look at orbits more carefully. Then you start introducing epicycles on top of epicycles to preserve the earth-centric model.  You may find that what you thought was simple was only familiar, and that what you dismissed as more complex was only less familiar.