Can A Programmer Be Ten Times More Productive?

Can a good programmer be ten times more productive than an average one? It’s a common claim, but one that’s hard for many people to believe.

I read about a psychology study where subjects had to do a series of simple math steps—like times 6, plus 12, divide by 3, minus 4. Each subject got a big stack of cards with a number on one side, and their job was to do the math and write the result on the other side. Most subjects got all of the answers right, but only a small percentage spotted the trick: all that math simply doubles the number. (Try one!) Even after doing a whole stack of cards, most people didn’t notice the wasted effort. Some programmers are ten times more productive, and it’s because they spot the clever solution.

There’s a classic story about mathematician John von Neumann solving a puzzle. In the puzzle, there are two trains going 50 miles per hour. They are 100 miles apart, heading straight towards each other. Meanwhile, a bee flies back and forth between the trains at 75 mph. The question is: how far does the bee travel before the trains collide and crush it? As the trains approach each other, the bee flies a shorter and shorter distance on each trip between them. The complicated solution is to calculate the length of each leg of the bee’s journey, and add them all up. (It is the sum of an infinite series.) The easy way is to notice that the trains will collide in one hour: at 75 mph, the bee will travel 75 miles in that hour.

The story goes that when John von Neumann was asked this question, he instantly answered: “75 miles”. The person who posed the question said, “Very good. You know, most mathematicians don’t spot the trick, because they get bogged down with the infinite series.” Von Neumann replied, “But I did solve the infinite series. There’s a trick?”

Some productive programmers probably solve problems the normal way, but do it ten times faster. They are like Von Neumann doing the infinite series in his head. But I suspect that most highly productive programmers have a knack for spotting a clever-and-simple approach, rather than slogging through the obvious-but-difficult-to-implement one. For programming, this is much better than being ten times faster. The clever-and-simple solution results in less code, which requires less debugging, less maintenance, and it probably uses less memory and runs faster.

These examples not only show how one programmer can be ten times more productive than another, but they also show why it is worthwhile spending the time to mull over a problem—maybe take walks around the block or brainstorm with co-workers—before diving in to implement the most obvious solution.

PS: That study on simple math was also about music. Some subjects heard music, and some were in a quiet room. The music had only one significant effect on performance: none of the subjects listening to music spotted the trick.

Comments

[Val Bercovici]

Wow, this discussion brings me right back to my days interviewing at Microsoft. They were famous for scrutinizing candidates' thought processes with questions like these.

Ironically my great high school friend and your Princeton CS lab buddy Adam Barr has spent quite a bit of time opining on this and related topics on his own blog.

Your reference to psychology, math and music reminded me of a story.

Sophomore year in college, I took an Introduction to Psychology class. For one of the mandatory laboratory sessions, I signed up as a test subject for a study on Distraction.

We were asked to solve a variety of simple math problems. Meanwhile, the facilitator distracted us with loud noises, counting out numbers, and so on – making it very hard to concentrate.

It also happened that an attractive classmate joined the session, and sat directly across from me. I enjoyed the irony that the objects of the study were at least as distracting as the test itself.

Apparently, the failure to observe brilliantly can be attributed to a variety of different causes :-)

[Mike]

So true.

It seems like every time I look back on a previous set of code, I always find a much simpler approach to solve the problem in much fewer lines. Experience and knowledge definitely play a role in the skilled programmer's abilities. The rest is a mix of creativity, genius and luck.

[Smartha]

Hi Dave,
One of the important facets of life has been highlighted in your blog... If i was to state the same for professional life, I would have probably put it as "Working Smart... rather than Hard." What counts is Productivity as you have rightly put it across. And the same applies to life also. Achievers are not the ones who slog, but the ones who dig opportunities in every problems and make a win out of it. Am reminded of Robert Frost's lines from the poem The Road not Taken...
TWO roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth;
Then took the other, as just as fair,
And having perhaps the better claim,
Because it was grassy and wanted wear;
Though as for that the passing there
Had worn them really about the same, "

So the essence is to think out of the box, being innovative and making the most of every moment by effective management. Needless to say that it applies to programmers and the world alike.

[sohbet odaları]

Thanks a lot

I remember one all-nighter in college where I had a mental block when writing some semaphore code. As the sun rose, I got cleaned up and went about my day. That night when I sat down to work on the problem again, I saw the "simple" solution in about one minute. Sometimes it's best to skip a problem and return to it later with a new perspective.

[Shibin Zhang]

I went to a discussion about Netapp storage accelerators two weeks ago. Fair to say, they are examples of clever-and-simple products. The ideas are not complicated, but they provide solutions to real customer problems.

[Shibin Zhang]

Another example is NAS. What’s NAS? It’s just a file server and disks in a box. I can do it too. The problem is why I didn’t think of this idea before Network Appliance.

[Wilfried Visser]

Interesting. Having seen many scientific/engineering s/w development projects succeed and fail during my career so far I usually tell a similar story:
"What do you think is the productivity ratio of the best over the worst mason in a construction company? Well, that must be somewhere between 1.1 and 5 most would guess. In s/w development 10 is already conservative. On average for programmers I think it is at least a 1000 if you include the very best and worst at work in large organisations.
I have seen programmers with no productivity at all, or worse: just adding rubbish others have to revert (negative productivity). I also am aware that the utmost best among them find solutions that are equivalent to the work of 100s or even 1000s of others.