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(

            “http://www.slashdot.org”,

            “http://www.arstechnica.com”,

            “http://my.yahoo.com”,

            “http://www.flipcode.com”,

            “http://www.powerlineblog.com”,

            http://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.

Comments (8)

  1. Andrew says:

    Studies have shown that the way humans become proficient in something is through effortful practice, i.e. attempting tasks that are just beyond your current level of competency. How good you get at something is therefore directly related to your level of motivation for improving your skills rather than innate ability. This applies equally in physical activities, like soccer, as well as in mental activities like chess.

    Interviewing to assess a candidate’s current level of programming sophistication is therefore a guide to the amount of motivation a person has had in the past to improve their coding/algorithm/data structure skills. While this might be a good predictor of future motivation I disagree that it is any kind of  an indicator where a particular person has topped out intellectually.

    This Scientific American article, "The Expert Mind", is a great summary of all this if you are interested in learning more http://www.sciam.com/article.cfm?chanID=sa006&colID=1&articleID=00010347-101C-14C1-8F9E83414B7F4945

  2. SteveRowe says:

    I didn’t intend to say we coud (or should) expect to determine someone’s peak ability in an interview.  We can’t.  However, I think we can detect whether someone has a talent for something or not.

    Humans get better at something through effortful practice but each human has certain innate talents which allow him/her to be better at some things than others.  No matter how much I practice basketball, I won’t ever be Michael Jordan.  That’s not just because of my height.  I also don’t have the athletic ability to do it.  Likewise, no matter how much they practice, most people probably can’t become grand masters in chess.  The authors of the paper above found a test which they believe can predict whether someone will be able to handle programming or not.  Marcus Buckingham has an interesting book called "First, Break All the Rules" where he discusses this issue of talent and how it relates to finding great employees.

  3. Dion Dock says:

    Your ideas seem on the right track but I’m not sure I agree with the examples.  For example, a pointer isn’t an abstraction, it’s how the computer literally references memory.

    The hapless student has been taught to program to some extent, and suddenly their abstractions are both taken away (introduction to pointers) and made more advanced (relational databases).

  4. Andrew says:

    You wrote:

    "but each human has certain innate talents which allow him/her to be better at some things than others"

    That certainly is the conventional wisdom but the Scientific American article states that there simply isn’t a lot of hard evidence in support of it. There is however much evidence that experts are made not born. It takes about 10 years of heavy lifting to get good at something which is why past practice is often mistaken for talent, especially in interview/assessment type situations.

    One of the things I’ve read about MS recruiting is that you look for people with a passion for computers and technology and who have a bias for action. Both of these traits are likely to lead you to people who are motivated towards effortful practice of their programming skills. Similarly by getting candidates to write code during an interview you are assessing their past motivation, which is quite likely to be a guide to their future motivation. All of this says to me that you will offer jobs to people who will turn out to be highly productive programmers, but I don’t think that you are assessing some sort of innate programming talent.

    Personally I find this to be a fascinating subject, I’ll check out the "The Camel Has Two Humps" paper tonight.

  5. SteveRowe says:

    Dion, it’s not "abstraction" I’m talking about but rather abstractness.  I.e. the lack of concreteness.  The concept of a pointer is abstract (even if it is not an abstraction).

  6. Maurits says:

    "The concept of a pointer is abstract"

    "Abstract" is a relative term, of course.

    It’s also heavily dependent on your point of view.

    I view my bank account as an abstract entity that looks vaguely like

    class CBankAccount {

    private: signed money balance;

    public:

    bool Deposit(unsigned money income);

    bool Withdraw(unsigned money expense);

    money CheckBalance() { return balance; }

    };

    I imagine people that work in banks have a much more concrete picture of how banks work, but view computers something like this:

    class CComputer {

    private: spreadsheet Files[];

    public:

    spreadsheet NewSpreadsheet(name newName);

    spreadsheet OpenSpreadsheet(name theOneIWant);

    }

  7. A lot of testers begin life as software test engineers. That is, they execute tests but don’t do any

  8. The world of testing is becoming a lot more technical than it once was. While there is still a need for