You Can't Teach Height, But Can You Teach Programming?

There's an old basketball saying--attributed to Frank Layden of the Utah Jazz-- that "You can't teach height."  No matter how much skill you have, if you are short, you'll be at a disadvantage on the court.  You can teach someone to be a better player, but you can't make them any taller.  Recently, there's been a meme running around the blogosphere asking whether there is an analogy to height in programming.  Is there something about programming that puts it out of reach for many people? 

Some people can learn to program.  Some can't.  There's a good paper called "The Camel Has Two Humps" by Saeed Dehnadi and Richard Bornat which claims this to be the case.  The authors explain that in CS classes there are two groups of people:  those who can program and those who can't.  "Between 30% and 60% of every computer science department's intake fail the first programming course."  Many methods have been tried over the years to overcome this deficiency but to date no one has made serious progress here.  The authors speculate that this is because some people just can't handle the meaninglessness of programming.  They point out that the teaching of formal logic suffers from the same problems.  If you don't want to read the whole paper, Jeff Atwood has a good synopsis.

Are the authors correct in their analysis?  Is it this lack of meaning that causes people to not be able to program?  I'm not so sure.  My guess is that it is the abstract nature of programming that stops people from being able to program.

Most people who take math long enough eventually hit a wall.  There is some point when you can just no longer grasp what is being taught.  No matter how much you study, you'll never become proficient at that level of math.  For some people this comes early with algebra.  For many others it is geometry or trig.  A large number of people hit the wall with calculus.  Still others at differential calculus.  For me, Discrete Math is something I've never been able to master.  Often times people will do fine in math one semester and struggle to even pass the next.  Why is this?  I think it is because math is increasingly abstract.  The further you get in math, the more abstract it is.  As things get more abstract, they become harder to follow.  This isn't true just in math but even in fields as distant as philosophy.  Following Nietzche is a lot harder than reading Rawls which is harder than Orwell's 1984.  Why?  Because each is written more abstractly than the one before it.

Programming is also increasingly abstract.  Linear programming in BASIC (old-school, not VB) is something most people can accomplish.  Functions are the next rung on the ladder.  After that comes pointers.  Some people just can't grok them.  I've conducted many an interview where the interviewee wrote down foo(bar), erased it, wrote foo(*bar), then finally foo(&bar).  Next is classes.  Not every C programmer can comprehend interfaces and class hierarchies.  Fewer still can create good ones.  Templates (or "generics" as they are now called) throw many people for a loop.  It's amazing how much harder it is to write a function with a T than an int.  At each of these stages, you'll lose some people.

I'm reminded of a time when a friend of mine who is not a programmer tried to create a random home page for his browser.  He wrote some javascript which contained a series of nested if...then...else statements.  Someone else suggested he consider using the switch statement.  I wrote this:

list = new Array(

            "https://www.slashdot.org",

            "https://www.arstechnica.com",

            "https://my.yahoo.com",

            "https://www.flipcode.com",

            "https://www.powerlineblog.com",

            https://www.realclearpolitics.com);

a = Math.floor(Math.random() * list.length);

document.location=list[a];

The difference is more than just a more thorough understanding of the language syntax.  I think it is indicative of a use of higher level abstraction.  If..then is a brute force method.  It is very concrete.  We all understand this.  On the other hand, an array is more abstract and using the array object to get information about itself is not quite as intuitive as counting by hand and hard-coding it.

What is the implication of all this?  If true, you can't teach everyone to program.  As you climb the programming language ladder, people will drop off.  Anyone who can program and has read Worse Than Failure will realize that some people just don't get it.  It isn't that they are stupid, they just aren't wired for this task.  At 5'10", I'm not wired for basketball.  Spending time teaching someone who isn't wired right to program beyond their talent-level will be an exercise in frustration for all involved.

This affects the way we should interview.  If people cannot program, hiring them with the expectation that we will teachthem is fraught with danger.  The short of it is that we need to ask programmers to program during interviews (seems obvious doesn't it?).  Scott Hanselman has a great post on this.

I'll end on a slight tangent.  I wonder if this can explain some of the complaints about VB.net over Visual Basic 6.0.  Moving to .Net added classes and a lot more complexity.  In essence, it added more abstractness to the language.  If my hypothesis is right, this would make a certain number of people who were comfortable with VB 6.0 no longer capable of grokking the updated version.