Productivity

The Hawthorne effect is the idea that people perform better when they’re being studied. The name comes from studies conducted at Western Electric’s Hawthorne Works facility. Increased lighting improved productivity in the plant. Later, lowering the lighting also increased productivity. The Hawthorne effect says that the productivity increase wasn’t due to changes in lighting per se but either the variety of changing something about the plant or the attention that workers got by being measured, a sort of placebo effect.

The Alternative Blog has a post this morning entitled Hawthorne effect debunked. The original Hawthorne effect was apparently due to a flaw in the study design; correcting for that flaw eliminates the effect.

The term “debunked” in the post title may imply too much. The effect in the original studies may have been debunked, but that does not necessarily mean there is no Hawthorne effect. Perhaps there are good examples of the Hawthorne effect elsewhere. On the other hand, I expect closer examination of the data could debunk other reported instances of the Hawthorne effect as well.

The Hawthorne effect makes sense. It has been ingrained in pop culture. I heard a reference to it on a podcast just this morning before reading the blog post mentioned above. Everyone knows it’s true. And maybe it is. But at a minimum, there is at least one example suggesting the effect is not as wide-spread as previously thought.

It would be interesting to track the popularity of the Hawthorne effect in scholarly literature and in pop culture. If the effect becomes less credible in scholarly circles, will it also become less credible in pop culture? And if so, how quickly will pop culture respond?

Sitting at a computer changes the way you think. You need to know when to walk away from the computer and when to come back.

I think mind mapping software is a bad idea. Mind maps are supposed to capture free associations. But the very act of sitting down at a computer puts you in an analytical frame of mind. In other words, mind mapping is a right-brain activity, but sitting at a computer encourages left-brain thinking. Mind mapping software might be a good way to digitize a map after you’ve created it on paper, but I don’t think it’s a good way to create a map.

When I need to sort out projects and priorities, I do it on paper. After that I may type up the results. I like to capture ideas on paper or on my voice recorder but then store them online.

When I do math, I scribble on paper, then type up my results in LaTeX. Scribbling helps me generate ideas; LaTeX helps me find errors. I’ve found that fairly short cycles of scribbling and typing work best for me, a few cycles a day.

In the past, we did a lot of things on paper because we had no choice. Today we do a lot of things on computers today just because we can. It’s going to take a while to sift through the new options and decide which ones are worthwhile and which are not.

Recommended books

Daniel Pink’s book A Whole New Mind has a good discussion of left-brain versus right-brain thinking. As he points out, the specialization between the left and right hemispheres of the brain is more complicated than once thought. However, the terms “left-brain” and “right-brain” are still useful metaphors even if they’re not precise neuroscience.

Also, to read more on how computers influence our thinking, see Andy Hunt’s book Pragmatic Thinking and Learning.

Related posts

A stimulating work environment
Living within chosen limits
Tim Bray’s high-tech monastic cell
What’s wrong with paper?
Getting to the bottom of things

My frustration with personal productivity systems like GTD is that they’re all about projects and tasks. They leave out a third category: programs. GTD thinks of a project as something that can be broken into a manageable number of tasks and scratched off a list. But programs go on indefinitely and cannot be divided into a small number of one-time tasks.

I’m using the word “program” as in an “exercise program” or a “research program.” (I could think of my exercise program as a project, but it’s one I hope not to complete for a few more decades.) Sometimes there is a neat hierarchy where programs spawn off projects that can be divided into tasks. But sometimes you just have programs and tasks.

One of my frustrations with managing software development in an academic environment was the large number of programs disguised as projects. (Sorry, I know it’s confusing to talk about “programs” in the context of software development and not mean computer instructions.) You can’t manage programs as if they were projects. For example, you can’t talk about “after” project is done if it’s not really a project but a never-ending program. You have to either acknowledge that a program is really a program, or you have to have some way to make it into a finite project.

Greg Wilson pointed out an article on productivity by Jason Cohen that makes a lot of sense. Here’s a story that Jason tells to set up his point.

You get in your car at home and head out towards your mother’s house 60 miles away. … You hit traffic during the first half of the trip, so after 30 miles you’ve averaged only 30 miles per hour. Now the traffic opens up and you can go as fast as you want. The question is: How fast do you have to go during the second half of the trip such that you’ve averaged 60 mph over the entire trip?

The key is that you cannot go fast enough to make up for lost time. Your average will be less than 60 mph no matter how fast you go for the second half of the trip. His conclusion: “It’s amazing how periods of low velocity wash away gains of high velocity.” The title of his post is about how to double your productivity, but about one third of the article is devoted to explaining why even larger gains are not possible, i.e. his observation that unproductive periods limit potential productivity gains. As he explains, “the thing to do is eliminate the low-velocity stuff.”

The best way to be more productive may be to concentrate on “what” more than “how.” Concentrate on what to do, and more importantly, what not to do. There may be more to gain by adding to the “not to do” list than by being better at what’s on the “to do” list.

The latest EconTalk podcast is an interview with Brink Lindsey, author of The Age of Abundance. Lindsey said that in the 1980’s and 90’s we learned how to live with the freedoms gained in the 1960’s and 70’s. Many negative social indicators soared in the 60’s and 70’s: crime, divorce, drug use, abortion, etc. But during the 80’s and 90’s many of these indicators reversed direction, and Lindsey believes it is because many people have learned to replace legal and societal limits with chosen limits.

I don’t know whether I agree with Lindsey’s sweeping sociological analysis, but I do see some truth to it. I like his phrase “living within chosen limits.” I see a movement toward living within chosen limits on technology. The most obvious example may be Twitter. About 8,000,000 people at this point see some value in limiting their correspondence to 140 character messages. Some other ways I hear of people placing voluntary limits on their technology:

• Unplugging from the Internet to work
• Using terminal-style text editors to minimize distraction
• Using browser-based applications with limited functionality to avoid installing software
• Setting a five-sentence limit on email messages
• Paper organizers, e.g. the Hipster PDA

I imagine the people who adopt these limitations will moderate their approach over time. Instead of unplugging from the Internet, they’ll make better use of it and become more disciplined. They may decide that some modern word processor features are worthwhile but still chose something more streamlined than Microsoft Word.

It may take a generation or more to learn how to take advantage of the new possibilities. We’re in a period of excess now, analogous to the culture of the 1960’s. It will be interesting to see what the analogy of the 80’s and 90’s will be.

Related posts from Kevin Kelly:

Neo-Amish Drop Outs
Amish Hackers

Related posts here:

Strategy for dealing with information overload
Selective use of technology
Getting to the bottom of things

The second habit in Stephen Covey’s best-selling book The 7 Habits of Highly Effective People is “Begin with the end in mind.” Pope Leo X would have disagreed.

Twyla Tharp tells the story of Pope Leo X and his frustration with Leonardo da Vinci in her book The Creative Habit. da Vinci was experimenting with varnishes and so forth when the Pope thought he should be painting. Leo’s assessment of da Vinci:

This man will never do anything, for he begins thinking about the end before the beginning of his work.

Related posts:

Are Covey’s quadrants correlated?
Don’t try to be God, try to be Shakespeare

Clay Shirky gave a thought-provoking presentation “It’s Not Information Overload. It’s Filter Failure.” He argues that information overload is not new. Ever since Gutenberg most people have had access to more information than they could handle. But until recently there were effective mechanisms for filtering this information: social norms, slow communication, etc. The solution is to create new filters. Here are a couple quotes from near the end of his presentation.

We’ve had information overload in some form or another since the 1500’s. What’s changing now is the filters used for most of that 500 year period are breaking. And designing new filters doesn’t mean simply updating the old filters. They’re broken for structural reasons, not surface reasons.

When you feel yourself getting too much information, I think the discipline is not to say to yourself “What’s happened to the information?” but rather “What was I relying on before that stopped functioning?”

(By the way, does anyone else think Clay Shirky looks like Tom Hanks in that video?)

From Mark Twain:

The secret of getting ahead is getting started. The secret of getting started is breaking your complex and overwhelming tasks into small manageable tasks, and then starting on the first one.

In his book Secrets of Consulting, Gerald Weinberg tells the story of a woman who had several pairs of twins. Someone asked her if she and her husband got twins every time. She replied no, most of the time they got nothing at all. Just as intimacy doesn’t usually result in one child, much less two, most efforts in business don’t produce any significant results. Weinberg summarizes this observation in Weinberg’s Law of Twins:

Most of the time, for most of the world, no matter how hard people work at it, nothing of any significance happens.

Later he turns this around and states the principle more positively in Weinberg’s Law of Twins, Inverted:

Some of the time, in some places, significant change happens — especially when people aren’t working hard at it.

Related post: Four reasons we don’t apply the 80/20 rule.

Why can’t we make more use of the 80/20 rule? I’ll review what the 80/20 rule is, explain how it can be powerful, then give four reasons why we don’t take advantage of it.

What is the 80/20 rule?

The 80/20 rule is amazing when you first learn about it. It says that efforts and results are often very unevenly distributed. You’ll get 80% of your results from the first 20% of your efforts. For example, maybe your top 20% of customers will provide 80% of your profit. Or when you’re debugging software, often 80% of the bugs will be in 20% of the code. Once you become aware of it, you’ll see 80/20 examples everywhere.

There’s nothing magical about the numbers 80 and 20. The general principle applies if 93% of your results come from 22% of your efforts. The numbers don’t have to add to 100. The principle is just that outcomes are unevenly distributed, more unevenly distributed than you may think.

Applying the 80/20 rule

Applications of the 80/20 rule are everywhere. For example, if you want to learn a foreign language, you don’t buy a dictionary and start learning words from page 1 and work your way to the end. Some words are used far more often than others. You’ll be able to use a language much sooner if you learn the vocabulary roughly in descending order of frequency.

Software optimizations can be extreme examples of an 80/20 rule. Sometimes 98% percent of a program’s time is being spent executing just five lines of code.  Finding those five lines and tuning them is far more effective than randomly tweaking things here and there in hopes that the changes improve performance.

Why don’t we apply the 80/20 rule?

If the 80/20 rule is so powerful, why don’t we us it more often? Why don’t we concentrate our efforts where we’re likely to see the best results? Here are four reasons.

1. We don’t look for 80/20 payoffs. We don’t see 80/20 rules because we don’t think to look for them.
2. We’re not clear about criteria for success. You can’t concentrate your efforts on the 20% with the biggest returns until you’re clear on how you measure returns.
3. We’re unclear how inputs relate to outputs. It may be hard to know what the most productive activities are.
4. We enjoy less productive activities more than more productive ones. We concentrate on what’s fun rather than what’s effective.

If you address these issues in order, you might get stuck on the third one. It can be hard to know what is most productive. Our intuition in this area is usually wrong. For example, maybe the most effective thing to do is very simple, but we overlook it because we think the answer must be more complicated. Or maybe we confuse what we need to do with what we want to do. Collecting data is the best way to find out what really works. The results are usually surprising.

Sometimes the world changes and we’re stuck doing what used to be most effective. Some of the most persistent ideas about the “right” way to develop software come from studies of done forty years ago. It’s not enough to collect data one time.

Related blog posts:
Houston power outage and the 80-20 rule
Networks and power laws

Andy Hunt posted an article this morning entitled Science Failure and Cubicle Brain Death. He explains that one reason it took so long to discover that adult animals could grow new brain cells was that such growth doesn’t happen in laboratory conditions. To grow new brain cells, animals need stimulation that a sterile lab environment does not provide. People need stimulating environments too. Little things matter.

… things like the pen and paper you use, the decorations at your desk, the lighting and ceiling height of your cubicle all have a measurable effect on your cognitive processes.

Joel Spolsky talked about this in the latest StackOverflow podcast. His company often faces criticism for spending so much money on office space for developers. But as he put it, the difference between depressing and stimulating office space may amount to whether you devote 4% or 6% of your total budget to rent. The extra investment in office space allows you to recruit more competitively for top talent and makes the people you hire more productive.

Related posts:

Selective use of technology
Brain plasticity
Getting to the bottom of things

I heard of a study recently that concluded inexperienced and experienced programmers write about the same number of lines of code per day. The difference is that experienced programmers keep more of those lines of code, making steady progress toward a goal. Less experienced programmers write large chunks of code only to rip them out and rewrite the same chunk many times until the code appears to work. Or instead of ripping out the code, they debug for days on end, changing one or two lines at a time, almost at random, until the code appears to work.

As Greg Wilson pointed out in his interview, focusing on quality in software development often results in increased productivity as well. More effort goes into forward progress and less goes into re-work.

Not only do experienced programmers produce more lines of code worth keeping each day, they also accomplish more per line of code, sometimes dramatically more. But that’s not news. It’s well known that the best programmers aren’t just a little more productive than average, they’re one or two orders of magintude more productive. (See, for example, Joel Spolsky’s book Smart and Gets Things Done.) More interesting is that the best programmers don’t seem to have a much larger capacity for producing and understanding lines of code.

There have also been studies that show programmers produce about the same number of lines of code per day independent of the language they use. You might think that someone working in assembly language could produce more lines of per day than someone writing in a higher level language such as VB or Java, but that’s not the case. It seems that while counting lines of code is a terrible way to measure productivity, it is a good way to measure what you can expect someone to be able to hold in their head.

Do you have a single program that you “live in” when you’re at a computer? Emacs users are known for “living” inside Emacs. This means more than just using the program for a large part of the day. It means using the program as the integration point for other programs, a sort of backplane for tying other things together.

Steve Yegge’s most recent blog post described his switch 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 concludes 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.

Graphic artists may spend the majority of their work day using Photoshop, but they don’t send email from Photoshop, and they don’t keep their calendar in Photoshop. So I wouldn’t say they “live” in Photoshop. Microsoft developers spend a great deal of their time inside Visual Studio, though they don’t live inside Visual Studio to the same extent that Emacs users live inside Emacs. The Visual Studio experience is somewhere between Photoshop and Emacs on the “live in” scale. Unlike Emacs, Visual Studio has no ambition to become an operating system, probably because the company that makes Visual Studio already has an operating system.

I once knew someone who lived in Mathematica, doing his word processing etc. inside this mathematical package. Mathematica is a nice place to visit, but I wouldn’t want to live there.

A growing number of people now live inside their web browser, particularly if that browser is Firefox. There are Firefox plug-ins available to mow your lawn and take your children to the orthodontist. Maybe Firefox is becoming the Emacs of a new generation.

The choice of a program to live in is really a choice of how you want to tie applications together. To live in Emacs, you have to write Emacs Lisp, and that’s a deal-breaker for many. Interestingly, Microsoft has a project to create a highly configurable editor some have nick-named Emacs.NET. You can bet that the extension language will not be Emacs Lisp.

Some people live in their command shell and use shell scripts to tie everything together. While many Unix folks live that way, that hasn’t been practical on Windows until recently when PowerShell came out.

By the way, you can run PowerShell and Emacs at the same time. See Jeffrey Snover’s blog post PowerShell Running Inside of Emacs.

Sometimes making a task just a little simpler can make a huge difference. Making something 5% easier might make you 20% more productive. Or 100% more productive.

To see how valuable a little simplification can be, turn it around and think about making things more complicated. A small increase in complexity might go unnoticed. But as complexity increases, your subjective perception of complexity increases even more. As you start to become stressed out, small increases in objective complexity produce big increases in perceived complexity. Eventually any further increase in complexity is fatal to creativity because it pushes you over your complexity limit.

Going back to simplification, a small decrease in complexity can be a big relief if you’re stressed out. Maybe that small simplification can pull you out of F-state back to C-state. If you’re up against your maximum complexity, a small simplification could make the difference between a problem being solvable rather than unsolvable.

Small simplifications are often dismissed as unimportant when they’re evaluated in the small. Maybe a new term makes it possible to refer to an idea in three syllables rather than six. No big deal if it’s a term you don’t use much. But if it’s a term you use all the time, it makes a difference. That’s why every group has its own jargon.

Suppose one programming language takes five lines of code to do what another language can do in four lines. So what? How long does it take to type one line of code? But multiply that by 10. Maybe you see 40 lines of code on your laptop at once but you can’t see 50. Or multiply by 10 again. Maybe you can hold 400 lines of code in your head but you can’t hold 500. Language features dismissed as “syntactic sugar” can make a real difference.