Coding Horror: Separating Programming Sheep from Non-Programming Goats

I guess it is reasonable that people have a hard time with this. They've grown up their whole lives dealing with people and animals and themselves. These act according to wants and gloss over minor errors, a fuzzy world full of fuzzy actors. Heck, even our species has lived and evolved mostly dealing with such. It doesn't make much sense to them that one typo could cause a super powerful computer or expensive device to keel over and be useless and do nothing.

I see this at work. I've known programmers who, when they get a new hire, will basically let them flounder. I guess the basic idea is that if you're "good" you'll "figure it out" (with minimal time investment to boot). And that will work with some people. My own philosophy is that there are a significant number of people who need direction. Don't overwhelm them with "everything". Give them small, structured tasks to learn processes, small parts of the system, build confidence and give some measure of progress.

That all being said, I honestly don't know how I learnt to program at all. I can teach people who know how to program (the basics) more. But I can't teach someone who doesn't know how to program how to program.

I've come around to thinking that Zed Shaw (as just one example) is right about this. With his "Learn X the Hard Way" books he starts out by basically saying "just type this in" (and don't copy and paste). Don't worry what it does. You'll figure that out later.

I see people (in many different areas) who are under the mistaken impression they need to know "everything" before they can do anything (or even in games, make a decision of any kind). They feel the need to weigh up all the options and consider all the consequences. That's not actually how people learn (IMHO).

Children don't know any better so can just learn this way. Adults often let self-doubt, fear of embarrassment or fear of "what might happen" get in the way such that they won't allow themselves to learn.

So perhaps what universities should do is separate students who already know how to program from those that don't. Those that don't don't take ANY theory at all until they do an introductory course that starts with "just type this in". If you lack the ability (and willingness) to turn a thought into a program, no matter how simple, you're doomed to failure. This, I believe, is something that can be taught.

The ability to just try stuff and see what happens in a key element in continual learning (IMHO) and something that needs to be ingrained in programmers (to be) from day one.

I'd really love to see the outcome of this approach versus more traditional approaches.

I think the misconception some teachers have is that if a student is struggling, he or she is either incapable of learning the material or just not trying. The reality is that it could just be a reflection of how effective the teacher's methods are for that particular student.

Try this experiment with five people at a public place, say exactly what you said, and give them exactly one try at the correct answer. I'll give $10 to charity for each one that getes it right. If all five of them get it wrong, you owe me an upvote.

(Fair warning, the terms of this bet are ridiculously unfair to you.)

The test they mention only detects one kind of mental model for programming. What if some kid is unsure about the side-effects of `=`? Do we fail that kid for having an intuitive understanding of something most of us are introduced to as undergrads?