Author Archive

Rethinking interruptions

Monday, February 4th, 2008

If you read a few personal productivity articles you’ll run into this advice: Interruptions are bad, so eliminate interruptions. That’s OK as far as it goes. But are interruptions necessarily bad? And when you are interrupted, what can you do to recover faster?

Not all interruptions are created equal. Paul Graham talks about this in his essay Holding a Program in One’s Head.

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.

In her interview with John Udell, Mary Czerwinski points out that while interruptions are detrimental to the productivity of the person being interrupted, maybe 75% of the time interruptions are beneficial for the organization as a whole. If one person is stuck and other person can get them unstuck by answering a question, the productivity of the person asking the question may go up more than the productivity of the person being asked the question goes down.

Given that interruptions are good, or at least inevitable, how can you manage them? Czerwinski uses the phrase context reacquisition to describe getting back to your previous state of mind following an interruption. Czerwinski and others at Microsoft Research are looking at software for context acquisition. For example, one of the ideas they are trying out is software that takes snapshots of your desktop. If you could see what your desktop looked like before the phone rang, it could help you get back into the frame of mind you had before you started helping the person on the other end of the line.

Have you discovered a tool or habit that helps with context reacquisition? If so, please leave a comment.

Task switching

Saturday, February 2nd, 2008

If you’re working on three projects, you’re probably spending 40% of your time task switching. Task switching is the dark matter of life: there’s a lot of it, but we’re hardly aware of it.

I’m not talking about multitasking, such as replying to email while you’re on the phone. People are starting to realize that multitasking isn’t as productive as it seems. I’m talking about having multiple assignments at work.

John Maeda posted a note about multiple projects in which he gives a link to a PowerPoint slide graphing percentage of productive time as a function the number of concurrent assignments. According to the graph, the optimal number of projects is two. With two projects, you can do something else when one project is stuck waiting for input or when you need variety. But any more than that and productivity tanks.

Johanna Rothman has an interview on the Pragmatic Programmer podcast where she discusses, among other things, having multiple concurrent projects. She thought it was absurd when she was asked to work 50% on one project, 30% on another, and 20% on another. Research environments are worse. Because of grant funding, people are sometimes allocated 37% to this project, 5% to that project, etc.

We’re not nearly as good at task switching as we think we are. I hear people talking about how it may take 15 or 30 minutes to get back into the flow after an interruption. Maybe that’s true if you were interrupted from something simple. A colleague who works on complex statistical problems says it takes her about two or three days to recover from switching projects. In his article Good and Bad Procrastination, Paul Graham says “You probably only have to interrupt someone a couple times a day before they’re unable to work on hard problems at all.”

Population drift

Friday, February 1st, 2008

The goal of a clinical trial is to determine what treatment will be most effective in a given population. What if the population changes while you’re conducting your trial? Say you’re treating patients with Drug X and Drug Y, and initially more patients were responding to X, but later more responded to Y. Maybe you’re just seeing random fluctuation, but maybe things really are changing and the rug is being pulled out from under your feet.

Advances in disease detection could cause a trial to enroll more patients with early stage disease as the trial proceeds. Changes in the standard of care could also make a difference. Patients often enroll in a clinical trial because standard treatments have been ineffective. If the standard of care changes during a trial, the early patients might be resistant to one therapy while later patients are resistant to another therapy. Often population drift is slow compared to the duration of a trial and doesn’t affect your conclusions, but that is not always the case.

My interest in population drift comes from adaptive randomization. In an adaptive randomized trial, the probability of assigning patients to a treatment goes up as evidence accumulates in favor of that treatment. The goal of such a trial design is to assign more patients to the more effective treatments. But what if patient response changes over time? Could your efforts to assign the better treatments more often backfire? A trial could assign more patients to what was the better treatment rather than what is now the better treatment.

On average, adaptively randomized trials do treat more patients effectively than do equally randomized trials. The report Power and bias in adaptive randomized clinical trials shows this is the case in a wide variety of circumstances, but it assumes constant response rates, i.e. it does not address population drift.

I did some simulations to see whether adaptive randomization could do more harm than good. I looked at more extreme population drift than one is likely to see in practice in order to exaggerate any negative effect. I looked at gradual changes and sudden changes. In all my simulations, the adaptive randomization design treated more patients effectively on average than the comparable equal randomization design. I wrote up my results in The Effect of Population Drift on Adaptively Randomized Trials.

10 rules for creative thinking

Thursday, January 31st, 2008

Check out Sister Corita Kent‘s 10 rules for creative thinking posted on Scott Berkun’s blog.

http://www.scottberkun.com/blog/2008/creative-thinking-rules/

Three-hour-a-week language

Thursday, January 31st, 2008

I listened to an interview last night with Perl guru Randal Schwartz. He said that Perl is meant for people who use the language at least two or three hours per week. If you’re not going to use it that often, you’re probably better off using something else. But if you use it full time, you can see huge productivity increases.

That matches my experience, at least the first part. I was attracted to Perl because I could imagine being very productive with it. At first I used the language infrequently. Every time I sat down to write Perl I had to work hard to reload the language into my brain. Then for a while I used it frequently enough to achieve some fluency. Then as I wrote Perl less often I could almost feel the language slipping away.

Of course you have to use any language, human or computer, to achieve and maintain fluency. But my sense is that Perl requires more frequent use than other programming languages in order to remain minimally competent, and it repays frequent use more than other languages. I imagine this is a consequence of the natural language principles baked into the language.

One of the things I prefer about Python is that you do not have to use it three hours a week to remain competent.

I no longer write Perl, but I still enjoy listening to thought-provoking Perl speakers like Randal Schwartz.

Paper doesn’t abort

Wednesday, January 30th, 2008

My daughter asked me recently what I thought about a Rube Goldberg machine she sketched for a school project. I immediately thought about how difficult it would be to implement parts of her design. I asked her if she really had to build it or just had to sketch it. When she said she didn’t really have to build it, I told her it was great.

I thought of a friend’s comment about designing code versus actually writing code: “I’ve never seen a piece of paper abort.” The hard part about writing software is that people can tell when you’re wrong.

Programming the last mile

Tuesday, January 29th, 2008

In any programming project there comes a point where the programming ends and manual processes begin. That boundary is where problems occur, particularly for reproducibility.

Before you can build a software project, there are always things you need to know in addition to having all the source code. And usually at least one of those things isn’t documented. Statistical analyses are perhaps worse. Software projects typically yield their secrets after a moderate amount of trial and error; statistical analyses may remain inscrutable forever.

The solution to reproducibility problems is to automate more of the manual steps. It is becoming more common for programmers to realize the need for one-click builds. (See Pragmatic Project Automation for a good discussion of why and how to do this.  Here’s a one-page summary of the book.) Progress is slower on the statistical side, but a few people have discovered the need for reproducible analysis.

It’s all a question of how much of a problem should be solved with code. Programming has to stop at some point, but we often stop too soon. We stop when it’s easier to do the remaining steps by hand, but we’re often short-sighted in our idea of “easier”. We mean easier for me to do by hand this time. We don’t think about someone else needing to do the task, or the need for someone (maybe ourselves) to do the task repeatedly. And we don’t think of the possible debugging/reverse-engineering effort in the future.

I’ve tried to come up with a name for the discipline of including more work in the programming portion of problem solving. “Extreme programming” has already been used for something else. Maybe “turnkey programming” would do; it doesn’t have much of a ring to it, but it sorta captures the idea.

Why Mr. Scott is Scottish

Monday, January 28th, 2008

During the Victorian era, Scotland produced the best engineers in the world. It became routine for British ships to have a Scottish engineer on board. Star Trek’s Scottish engineer Montgomery Scott reflects this tradition.

Scotty, in the original series

Source: Victorian Britian

Six quotes on digging deep

Sunday, January 27th, 2008

Here are six quotes I’ve been thinking about related to digging deep into whatever is in front of you, making uninteresting work interesting.

Richard Feynman:

… nearly everything is really interesting if you go into it deeply enough …

G. K. Chesterton:

There is no such thing on earth as an uninteresting subject; the only thing that can exist is an uninterested person.

William Blake:

To see a world in a grain of sand,
And a heaven in a wild flower,
Hold infinity in the palm of your hand,
And eternity in an hour.

King Solomon:

Whatever your hand finds to do, do it with all your might …

James Woolsey:

If you’re enthusiastic about the things you’re working on, people will come ask you to do interesting things.

King Solomon:

Wisdom is in the presence of the one who has understanding, but the eyes of a fool are on the ends of the earth.

Comet dust looks like asteroid dust

Saturday, January 26th, 2008

Until quite recently, astronomers thought that comets formed in the outer reaches of the solar system and then were drawn into highly elliptical orbits that pass near the sun. But samples collected from comet Wild 2 look more like they came from the inner solar system like asteroids. Maybe the outer solar system is more like the inner solar system, or maybe comets didn’t form where we thought they did.

For more details, listen to yesterday’s 60-Second Science podcast or read the Science Magazine article the podcast is based on.

Empirical support for TDD

Saturday, January 26th, 2008

Phil Haack gives his summary of a recent study on the benefits of test-driven development (TDD). The study had two groups of students write unit tests for their programming assignments. Students assigned to the test-first group were instructed to write their unit tests before writing their production code, as required by TDD. Students assigned to the test-last group were told to write their tests after writing their production code. Students in the test-first group wrote higher quality code.

The study concluded that code quality was correlated with the number of unit tests, independent of whether the test were written first or last. However, the test-first students wrote more tests in the same amount of time.

Note that students were assigned to test-first or test-last. Most programming studies are just surveys.  The results are always questionable because professional programmers decide their tools. So, for example, you cannot conclude from a survey that technique X makes progrogrammers more productive than technique Y. The survey may say more about the programmers who chose each technique than about the techniques themselves.

Shell shock may be physical, not psychological

Friday, January 25th, 2008

Shell shock was identified during World War I as a condition that causes soldiers to become dazed after being near explosions. Symptoms may appear weeks after exposure and there are no outward signs of injury. Naturally, this was regarded as a psychological rather than physical disorder.

But according to a story in today’s Science Magazine podcast, there is increasing evidence that shell shock is caused by physical trauma to the brain. One theory is that compression waves from the explosion hit the torso and transfer pressure to the brain via the circulatory system. If this theory is true, improved head gear will not help but improved body armor might.

Example of the law of small numbers

Friday, January 25th, 2008

The law of small numbers says that people underestimate the variability in small samples. Said another way, people overestimate what can be accomplished with a small study. Here’s a simple example. Suppose a drug is effective in 80% of patients. If five patients are treated, how many will respond?

Many people reason that 80% means 4 out of 5, so if 5 people are treated, exactly 4 will respond. Always.

Others understand that things are not guaranteed to work out so neatly, but they still believe that it is highly likely that 4 people would respond. Maybe a 90% chance.

In fact, there’s only a 41% chance that exactly 4 would respond out of a sample of 5.

Laws of large numbers and small numbers

Thursday, January 24th, 2008

In case my previous note on the law of small numbers confused anyone, I’ll compare it to the law of large numbers.

The law of large numbers is a mathematical theorem; the law of small numbers is an observation about human psychology.

The name “law of large numbers” is a standard term applied to a theorem about the convergence of random variables. (OK, actually two theorems. Like nuclear forces, the laws of large numbers comes in a strong and a weak form.)

The name “law of small numbers” is a pun, and I don’t believe the term is commonly used. Too bad. It’s a convenient label for a common phenomena.

The law of small numbers

Thursday, January 24th, 2008

The book Judgment under uncertainty analyzes common fallacies in how people estimate probabilities. The book asserts that no one has good intuition about probability. Statisticians do better than the general public, not because their intuition is much better, but because they know not to trust their intuition; they know they need to rely on calculations.

One of the common fallacies listed in the book is the “law of small numbers.” In general, people grossly underestimate the variability in small samples. This phenomena comes up all the time. It’s good to know someone has given it a name.