Checking for the Programming Gear

It irritates me to no end that the original study is so much better known than the utter failure to replicate. I have to suspect that this has something to do with how conveniently it fits many programmers' notion that programmers are a special sort of person, possessed of some power beyond merely a lot of practice at programming and related skills.

Seconding Manufactoria.

I think you should give a more precise definition of the aptitude needed to be labelled has-a-gear.

And the next step for a reductionist is to split this "gear" to smaller (and smaller and smaller... if necessary) parts, and design a course to teach each one of them separately. And only then teach programming.

People have some innate differences, but I feel that speaking about innate talent is often just worshiping our ignorance as teachers.

Of course, it may turn out that the innate differences in this specific topic are too big to overcome, or that overcoming them is possible but not cost-effective... but I think we haven't tried hard enough yet.

For the record, I think programming is so measurable and has such a tight feedback loop that it is one arena in which it's relatively easy to recognize ability that far exceeds your own.

1) Code quality is fairly subjective, and in particular novice (very novice) programmers have difficulty rating code. Most professional programmers seem to be able to recognize it though, and feel awe when they come across beautiful code.

2) Code quantity can be misleading, but if you're on a team and producing a 100-line delta a day, you will notice the odd team member producing 1000-line daily deltas; coupled with even decent ability to tell whether or not that code is maintainable and efficient (in terms of functionality / loc), this is a strong indicator.

3) Actually watching a master write code is fantastic and intimidating. People that code at 60 wpm without even stopping to consider their algorithms, data structures or APIs, but manage at the end of an hour to have a tight, unit-tested, efficient and readable module.

I can think of five people that I know that I would classify as being in discrete levels above me (that is, each of them is distinguishable by me as being either better or worse than the others). I think there are some gaps in there; Jeff Dean is so mindbogglingly skilled that I can't see anyone on my list ever catching up to him, so there are probably a few levels I don't have examples for.

I've taught courses at various levels, and in introductory courses (where there's no guarantee anyone has seen source code of any form before), I've been again and again horrified by students months into the course who "tell" the computer to do something. For instance, in a C program, they might write a comment to the computer instructing it to remember the value of a variable and print it if it changed. "Wishful" programming, as it were.

In fact, I might describe that as the key difference between the people who clearly would never take another programming course, and those that might---wishful thinking. Some never understood their own code and seemed to write it like monkeys armed with a binary classifier (the compiler & runtime, either running their program, or crashing) banging out Shakespeare. These typically never had a clear idea about what "program state" was; instead of seeing their program as data evolving over time, they saw it as a bunch of characters on the screen, and maybe if the right incantations were put on the screen, the right things would happen when they said Go.

Common errors in this category include:

• Infinite loops, because "the loop will obviously be done when it has the value I want".
• Uninitialized variables, because "it's obvious what I'm computing, and that you start at X".
• Calling functions that don't exist, because, "well, it ought to".
• NOT calling functions, because "the function is named PrintWhenDone, it should automatically print when the program is done".

These errors would crop up among a minority of students right up until the class was over. They could be well described by a gut-level belief that computers use natural language; but this only covers 2-6% of students in these courses*, whereas my experience is that less than 50% of students who go into a Computer Science major actually graduate with a Computer Science degree; so I think this is only a small part of what keeps people from programming.

*In three courses, with a roughly 50-person class, there were always 1-3 of these students; I suspect the median is therefore somewhere between 2 and 6%, but perhaps wildly different at another institution and far higher in the general population.

I did teach Python at a computer science school (people there already had 2 years of scientific studies after "bac"), and I was amazed to see how hard it was for some of them to understand that in Python :

>>> 4+2
6
>>> "4"+"2"
'42'

So yes, I guess the key is about understanding what types are. The same kind of issues arise between using a variable and the variable name.

Now, I'm not sure how much this is teachable and when (ie, maybe it's a kind of skill you've to learn when you're young to really grasp). I started programming when I was 11, so there may be something around it, but I don't have much data on that.

Maybe you might like trying Python (there are some more tutorials listed here; specifically, Learn Python the Hard Way, #2 in the Python section, is a nice next step after Codecademy), it has a "cleaner" syntax, in that it doesn't require braces or so many brackets; this could help you to practice without so many distractions.

(And yes, once you've practiced more, you'll be able to keep track of more of the program in your head and so the white space is a navigational aid, rather than a hinderance.)

Note: this is me reply to myself (which I concede is a little lame and maybe I shouldn't've.)

I forgot my favorite question of this type, which, BTW, a couple of doctors I consulted did not seem to be able to answer: how many micrograms in .05 milligrams?

In other words, my hypothesis is that the way to identify the "programming gear" is to test knowledge of some really simple "formal system" such as arithmetic or metric-system prefixes that one would expect adults with a practical command of the simple formal system to be well-rehearsed in.

Note that the second one is answered not by computing the prices per pill, but by noticing that buying in bulk is nearly always cheaper (and possibly that it has to be so if manufacturers are trying to make a profit).

Is there a reason to use the same variable name within and outside a scope? It seems like a fertile source of errors.

I can see that someone would need to understand that reusing names like that is possible as a way of identifying bugs.

posterior = ApplyBayes(prior, evidence)
...
function ApplyBayes(prior, evidence) = { ... }

posterior = ApplyBayes(prior, evidence1)
posterior = ApplyBayes(posterior, evidence2)
posterior = ApplyBayes(posterior, evidence3)

Not HTML! Not HTML! In addition to the obvious shortcoming of not being a programming language, HTML is confusing and often vague. Start with python, ruby, or a lisp.

Someone awsome on here recommended Learn Python the Hard Way. I've had school off since Tuesday and I've been kicking it's ass since. It's really fun. I thought it'd be neat to test out what my abilities are like on Project Euclid.

I've solved three so far. I'm particularly proud of coming up with a program to do the Fibonacci sequence. It's a simple program, and probably not as efficient as it could be, but i didn't look at any spoilers and feel like a diabolical genius after having solved it.

to someone with no background, normally is taught pseudocode.

Tip: you can turn this into standard English syntax in one of two ways: (1) delete the word "to" and the comma after "background"; or alternatively, (2) change "normally is taught pseudocode" to "pseudocode is normally taught".

(Apologies if you're actually a native English speaker and the above was merely a typo -- but it pattern-matches to the calquing of syntax from another language, e.g. one of the Romance languages; and your name suggests that you might be a Portuguese speaker.)