Why you aren't a coder

[andrewducker]

There are people who can code, and people who can't[1]. If you're one of the ones that can't, wondering where you're going wrong, or one of the ones that can, wondering why people find it so hard, you'll be glad to know that the answer is in this PDF. It's an academic paper in which some CompSci academics spend a fair amount of energy trying to work out what the difference between the two types is.

After a fair amount of (fairly amusing and informative) waffling, wherein they reveal that

"Programming ability is not known to be correlated with age, with sex, or with educational attainment; nor has it been found to be correlated with any of the aptitudes measured in conventional ‘intelligence’ or ‘problem-solving-ability’ tests."

they get down to the real finding, which is that there are three types of responses and

"...what distinguishes the three groups in the first test is their different attitudes to meaninglessness."

One group refuses to engage with things that they can't see meaning in, one tries to impart meaning to the information, and one deals with the information without imposing meaning on it.

The third group is the one that makes good coders.

Bad coders except computers to understand things. They expect computers to do the right thing. They can see the meaning behind what the coder is asking and expect the computer to work it out.

Good coders know that all that's happening is that data is moved from place to place, transformed in various ways, and (possibly) displayed in some way. The code itself is a series of instructions that in and of themselves have no meaning - they only take on meaning when it's agreed that the changes they produce can be mapped onto the outside world. You can't rely on any internal meaning to produce the "right" output, because as far as the computer is concerned there is no right output - there's just the output you told it to give, and if that's not what you meant, it doesn't care, because it doesn't understand meaning, it just understands instructions.

And to show that it's all about meaning, they tested and discovered that the success/failure of the students didn't break down in the same way when dealing with more meaningful tasks. In that case they generated the standard "normal" curve you'd expect from a range of ability, rather than clustering at two points of pass/fail.

If you expect computers to understand things then you're in for a nasty shock. I, personally, have no doubt that eventually we'll have computers with human-like intelligence, but if you expect that to make life much easier you're fooling yourself - I have just as much trouble explaining what I want to other people as I do to computers.


[1]Joel Spolsky divides it further into those coders who can deal with pointers and those who can't (see here and here, which seems to be another thing that's an ability rather than a skill. Pointers require higher levels of abstract thinking and are one of those things that coders either take to (after a few weeks of headaches) or bounce off of entirely.

Comments

[ekatarina.livejournal.com]

This is fabulous. I have to point a number of people this way.

Ekatraina, who will use these concepts when she becomes a teacher

[missedith01.livejournal.com]

I started to do an OU course in programming many years ago and it was all about making frogs move up and down. I gave it up. I like things to mean something. Well, something more than frogs jumping up and down anyway, (altho, it does rather depend on the frog, now I think about it ...) I think I'm in group one. But at least I know the world is a better place if I don't code. :-)

[andrewducker]

It didn't occur to you that maybe you had to start off with simple exercises and build up to more complex things?

Or did you used to have a _terrible_ case of ranaphobia?

[surliminal.livejournal.com]

It beats coding "hello world"! Or American football stats leagues !

[johnbobshaun.livejournal.com]

I'd say that part of the problem is that there isn't an easy "in" these days because because students are thrown in the deep end with OOP.

Bring back QBasic, I say. ;-)

[andrewducker]

Depends what language you're taught. Most MSc courses seem to teach Java nowadays, but you can start with almost anything.

And if you're using a decent IDE, like VS.Net then you can ignore the OOP stuff for a bit until you've got the hang of the simple bits.

[khbrown.livejournal.com]

Is Java a good first language? I'm sure it's better than C or C++, but compared to Python or Ruby I'd say there's a lot of verbosity and scaffolding to get in the way of the more important concepts.

[andrewducker]

Actually, I'm not sure that C is such a bad language to start with. Pascal's probably the best one though - nice and simple, no overhead to get something simple started and is strongly typed.

How easy is it to write a short python program and just run it - do they need to be run from web servers or anything complex like that?

[khbrown.livejournal.com]

Python is an interpreted (or maybe interpiled) language, so you just pretty much write it and run it, then change it, save it, run it again - you don't have to compile it each time.

[andrewducker]

Just had a look at Python, and it does look pretty good for starting people off.

[andrewducker]

Aaaaand, I've changed my mind.

I wouldn't introduce people to coding in a weakly-typed language.

[allorin.livejournal.com]

Define easy. Going back to what Andy said, if you aren't trying to construct meaning from OOP, and instead can just understand it to be a set of instructions, then I wouldn't class it as 'hard', just complex. But you should be able to teach / learn simple constructs, and work up to the more convoluted stuff.

[khbrown.livejournal.com]

Here's Python creator Guido van Rossum's take on that:

http://www.artima.com/intv/strongweak.html

[andrewducker]

And I can understand that take - but I think that there are other advantages to strong typing, such as auto-completion. Which doesn't add a lot for simple types, but when dealing with complex ones (as I frequently am) is downright invaluable.

[andrewducker]

Oh, and I would tend to start off with strongly typed languages and then introduce weakly typed ones later, personally.