Is Programming Like Music or Engineering, and Must it Be Unintuitive?

You are probably familiar with the observation many have made that the top 5% of programmers are perhaps 20 times more productive than the average programmer. I know this to be true, and have seen it many times. What does this have to do with the discussion? Simply this: the amount of experience does not seem to matter in determine whether you’re in that 5%. It does not seem to be possible to teach one who is not a 5% performer how to get there. I won’t try to prove that here, take my word for it, or at least ask yourself what it means if it is true.

What is more relevant is my observations on watching that 5% group. What did they do better?
- I used to say the thing that really set them apart was a facility with factoring of all kinds. Those were the words I used, but factoring has so many meanings these days that I feel I should clarify.
- The top performers were really good at flipping problems around and viewing them from many angles.
The top players could do it from extreme “meta” positions that were layers of abstraction away from the core problem.
- These people lived and breathed isomorphisms, whether or not they had any idea what the word meant. I’ve described the application of isomorphisms to creativity in an earlier post on “The Medici” effect. It’s worth a reread.

By contrast, the average performers tended to view everything according to a very limited set of models or formalisms they grasped.
- They would try to hammer every problem into one of those few models.
- In the worst cases, the models they were able to understand and employ were limited simply to basic structured programming constructs.
- With difficulty they could get control flow. They were not especially good at break


Is it any surprise that it takes many formalisms to make the disparate problems we face soluble with fewer clearer lines of code? I’m not surprised. I’ve fiddled with just a few domains and languages in my career, and there are many differences. Here are some I’ve played with:
- User interface is a surprisingly parallel problem space dealing with events. Most frameworks make this painful. I’ll bet there is an opportunity for a great language in this niche. I like Adobe’s Flex a lot, but it is far from perfect. Constraint oriented programming (Thinglab!) is closer, so I am very hopeful about Adobe Thermo raising the bar further.

- Creating new languages and pure computer science concepts seems to benefit hugely from Lisp.

You’ve probably guessed my problem with Joel’s approach. It’s probably fine if you are seeking to create a vocational school for factory programmers. But, the formalisms are the real meat. It isn’t the lines of code. The programmers who got the formalisms could grind out more code than any half dozen of the others combined. They did so almost automatically and unconsciously. I suspect Julliard doesn’t work quite as Joel envisions either. Do students there stretch their thinking about musics “formalisms”, or do they spend most of their time perfecting a single arrangement and composition?