Productivity

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:

John Cleese on creativity
Losing patience with wastes of time
Rethinking interruptions

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:

Email isn’t the problem
Rethinking interruptions

The title of this post is the last line of a 60-Second Science podcast. The podcast announces a recent study that says we tend to over-estimate our abilities before we start something new, but under-estimate our abilities once we get started. Sounds true to me.

From The Dip:

A woodpecker can peck twenty times on a thousand trees and get nowhere, but stay busy. Or he can peck twenty-thousand times on one tree and get dinner.

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:

Doing good work with bad tools
Chauffeurs and Ferraris revisited
Emacs a few weeks later

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.

Related posts:

C-State and F-State
Multitasking makes us shallow
A sort of opposite to Parkinson’s law

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

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.

If you’ve never heard a Ford-Chevy argument, you may find it hard to believe that such things exist. People actually get into arguments, sometimes violent arguments, over which trucks are better, Ford or Chevy.

More generally, a Ford-Chevy argument is an emotionally charged debate over the merits of two similar things with each side fiercely loyal to its position. These arguments look silly to outsiders but are serious to insiders. We all have our Ford-Chevy topics.

Have you ever gotten into a Mac versus PC argument? Emacs versus vi? Your favorite programming language versus some inferior language? How about your profession versus some rival profession? Your favorite sports team versus a competitor?

Thomas Gideon recently recorded a podcast on software tools. Gideon gives a good explanation for why we have technical Ford-Chevy arguments.

The time needed to gain mastery over a single deep tool usually precludes being able to learn anything else in that category. Pointing out feature differences, ones that may paint your chosen tool in an unflattering light, can make you defensive without realizing it. … how much effort you put in is being called into question, and to a degree, if only subconsciously, your intelligence or judgment may also be questioned by implication.

When you’ve made a large investment in time or money, you don’t want to hear someone question that investment. You may feel that your intelligence or judgment is being called into question. You may fear that you’ve picked the wrong tool but don’t have the time or energy to learn an alternative.

I’d like to think I’m above Ford-Chevy arguments, but I’m not. I would never get into a literal Ford-Chevy argument because I don’t care about trucks. But I could easily fall into a Ford-Chevy–type argument about something I care more about.

It’s no surprise that emotional factors influence our choice of music or clothes. But it is surprising how much emotional factors influence even highly technical decisions. For example, people often choose statistical methods for emotional reasons, though they would never admit it. Once we make a decision, we come up with rational justifications after the fact. This applies to choosing a computer or a statistical method just as much as it applies to choosing a truck or pair of shoes.

Read a few of the over 6,500 comments on the video to get a taste of a real Ford-Chevy argument.

Related post: Doing good work with bad tools

Emacs is a text editor with ambitions to be an operating system. I do not use Emacs, though I once did, and I still find it intriguing. I’d like to find something similar that acts more like a Windows program.

GNU Emacs began in 1984 and has been in constant development ever since. The current version is 23.1. How many applications from 1984 are still in widespread use today? The only other one that comes to mind is TeX.

I used Emacs in graduate school and for a few years after that. I was fairly fluent with Emacs, though I never customized it much. I intended to learn Emacs Lisp and all that, but it never happened.

When I started developing Windows software I used Emacs at first, but the benefits of Visual Studio soon persuaded me give up my old editor. It was much easier to go with the flow.

I’ve revisited Emacs a couple times over the years. I still have some of the keystrokes burned into my memory. I use it on Linux now and then, but I mostly work on Windows, and my experience using Emacs on Windows has been frustrating to say the least. Tasks that are trivial in any Windows application, such as printing and spell checking, are surprisingly difficult to set up in Emacs. I’m sure it is possible to resolve these problems, though I never did.

The problems with printing and spell checking are part of the larger issue that Emacs is so idiosyncratic. It behaves nothing like a typical Windows program. Some people may say that’s a good thing. But it makes life more complicated if you switch between Emacs and more conventional Windows software.

Emacs is no more a typical Mac application than it is a typical Windows application. And yet my impression is that this is less of a problem for Mac users. I’d like to understand whether this is true and if so why.

One of the things I liked about Emacs was the way you could “live” there. An expert Emacs user might work inside Emacs all day, using it as an editor, debugger, shell, file system explorer, email program, etc. Steve Yegge is such an expert. When he blogged about his move from Windows to Mac,  he said the main reason for the switch was that he prefers the appearance of the fonts on a Mac. Changing operating systems was not a big deal for Yegge because he didn’t really live in Windows before, nor does he live in OS X now. He lives in Emacs. He concluded his essay by saying

So I’ll keep using my Macs. They’re all just plumbing for Emacs, anyway. And now my plumbing has nicer fonts.

Living inside Emacs comes at a price. Part of that price is writing lots of Emacs Lisp to glue things together. Another part of that price is the commitment to practicing using Emacs. As Yegge says elsewhere

… you need to make a serious, lifelong commitment to Emacs in order to master it. … So it’s not an editor for the faint of heart …

Yikes! I’m not ready to make a serious, lifelong commitment to a piece of software. To my wife? Yes. To my text editor? No.

One of the best features of Emacs is that it has custom “modes” for various kinds of files. Instead of using a separate program for editing every kind of file, Emacs users use one program with different modes. As soon as a new file type comes out, say for a new programming language, someone will post an Emacs mode for that new language.

I’d like to find an editor on Windows that is analogous to Emacs. By that I mostly have in mind a powerful, highly configurable editor with support for many file types. I’d want it to behave like a Windows application, not a foreign transplant, and integrate well with .NET.

There was a project to create such an editor, nicknamed Emacs.NET. It was announced in late 2007. It sounds like the project is still alive, but it doesn’t seem all that promising.

I’ve looked at a few Windows editors that claim to be highly configurable but are not well documented. So if such an editor is configurable, it’s configurable for the person who wrote it or possibly for anyone else willing to study the source code.

Any suggestions for a general purpose Windows editor? For starters, I’d be pleased to find something that’s good at editing LaTeX and HTML.

Update (2 April 2010): I’ve decided to give Emacs another try.

Related posts:

This post started out as an update to my earlier post One program to rule them all.

What do you learn just in case you’ll need it in the future, and what do you learn just in time when you do need it?

In general, you learn things in school just in case you’ll need them later. Then once you get a job, you learn more things just as you need them.

When you learn just-in-time, you’re highly motivated. There’s no need to imagine whether you might apply what you’re learning since the application came first. But you can’t learn everything just-in-time. You have to learn some things before you can imagine using them. You need to have certain patterns in your head before you can recognize them in the wild.

Years ago someone told me that he never learned algebra and has never had a need for it. But I’ve learned algebra and use it constantly. It’s a lucky thing I was the one who learned algebra since I ended up needing it. But of course it’s not lucky. I would not have had any use for it either if I’d not learned it.

The difference between just-in-case and just-in-time is like the difference between training and trying. You can’t run a marathon by trying hard. The first person who tried that died. You have to train for it. You can’t just say that you’ll run 26 miles when you need to and do nothing until then.

Software developers prefer just-in-time learning. There’s so much out there that you aren’t going to need. You can’t learn every detail of every operating system, every programming language, every library etc. before you do any real work. You can only remember so much arbitrary information without a specific need for it. Even if you could learn it all in the abstract, you’d be decades into your career without having produced anything. On top of that, technological information has a short shelf life, so it’s not worthwhile to learn too much that you’re not sure you have a need for.

On the other hand, you need to know what’s available, even if you’re only going to learn the details just-in-time. You can’t say “I need to learn about version control system now” if you don’t even know what version control is. You need to have a survey knowledge of technology just in case. You can learn APIs just-in-time. But there’s a big gray area in between where it’s hard to know what is worthwhile to learn and when.

Update: Here is a Chinese translation of this post.

Related posts:

Software that gets used
Why programmers write unneeded code
Don’t standardize education, personalize it
Worthless technical books

In his podcast Roberts on Smith, Ricardo, and Trade, Russ Roberts states that self-sufficiency is the road to poverty. Roberts elaborates on the economic theories of Adam Smith and David Ricardo to explain how specialization and trade create wealth and how how radical self-sufficiency leads to poverty.

Suppose you decide to grow your own food. Are you going to buy your gardening tools from Ace Hardware? If you really want to be self-reliant, you should make your own tools. Are you going to take your chances with what water happens to fall on your property, or are you going to rely on municipal water? Are you going to forgo fertilizer or rely on someone else to sell it to you? Carried to extremes, self-reliance ends in a Robinson Crusoe-like existence.

People in poor countries are often poor because they are self-reliant in the sense that they must do many things for themselves. They do not have the opportunities for specialization and trade that are available to those who live in more prosperous countries.

Some degree of self-reliance makes economic sense. Transaction costs, for example, make it impractical to outsource small tasks. It also makes sense to do some things that are not economically feasible. For example, an orthodontist may choose to make some of her own clothing or keep a garden for the pleasure of doing so, not because these activities are worth her time. In general, however, specialization and large trading communities are the road to prosperity. Without a large economic community, no one can become an orthodontist (or an accountant, barrista, electrician, …)

Why do we so often value self-sufficiency more than specialization and trade? Here are a three reasons that come to mind.

1. In America, self-sufficiency is deeply rooted in our culture. We admire the pioneer spirit, and this leads to seeing as virtues actions that were once a necessity.
2. Self-sufficient people are generally well liked, especially if they’re not too prosperous.  Conversely, those who create wealth by leveraging the labor of others are often treated with suspicion and jealously.
3. Our school system encourages “well roundedness” rather than excellence. The way to succeed is to be moderately good at everything, even if you’re not outstanding at anything. (More on this idea here.)

Update: After writing this post, I read Russ Robert’s book The Choice: A Fable of Free Trade and Protectionism. I discovered one of the later chapters is entitled “Self-Sufficiency Is the Road to Poverty.” Excellent book.

Related posts:

Evaluate people at their best or at their worst?
Make something and sell it
Do something dull
Transaction costs

From The Power of Full Engagement:

… every one of the great industrial disasters of the past twenty years — Chernobyl, the Exxon Valdez, Bhopal, Three Mile Island — occurred in the middle of the night. For the most part, those in charge had worked very long hours and built up considerable sleep debt.

Can better tools make you less productive? Here’s a quote from Frequently Forgotten Fundamental Facts about Software Engineering by Robert Glass:

Most software tool and technique improvements account for about a 5- to 30-percent increase in productivity and quality. … Learning a new tool or technique actually lowers programmer productivity and product quality initially. You achieve the eventual benefit only after overcoming this learning curve.

If you’re always learning new tools, you may be less productive than if you stuck with your old tools a little longer, even if the new tools really are better. And especially if you’re a part-time developer, you may never reach the point where a new tool pays for itself before you throw it away and pick up a new one. Kathleen Dollard wrote an editorial to this effect in 2004 entitled Save The Hobbyist Programmer.

Miners know they have a significant problem when the canary they keep with them stops singing. Hobbyist/part-time programmers are our industry’s version of the canary, and they have stopped singing. People who program four to eight hours a week are being cut out of the picture because they can’t increase their skills as fast as technology changes. That’s a danger signal for the rest of us.

So what do you do? Learn quickly or change slowly. The first option is to commit to learning a new tool quickly, invest heavily in up-front training, and use the tool as much as you can before the next one comes along.  This is the favored option for ambitious programmers who want to maximize their marketability by always using the latest tools.

The second option is to develop a leap frog strategy, letting some new things pass you by.  The less time you spend per week programming, the less often you should change tools. Change occasionally, yes, but wait for big improvements.

Related posts:

Doing good work with bad tools
Fear of tech commitment
Three-hour per week language