Programming and Cognitive Development

[xcthulhu]

Recently I have been increasingly interested in science education, in particular programming.

A classic paper in the emerging field of the cognitive study of early learning to program is Saeed Dehnadi et al.'s The Camel has Two Humps.

http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf

The study found that among programming students, three groups emerge: consistent thinkers, inconsistent thinkers, and people who refuse to answer any questions. The consistent group wasc haracterized by answering questions on aptitude and review tests consistently, while the inconsistent group was characterized by answering inconsistently. Similar studies were conducted among students studying formal logic with similar results.

Tests were conducted before and during introductory courses in programming and formal logic.

The authors make some sweeping and fairly controversial conclusions:

It has taken us some time to dare to believe in our own results. It now seems to us, although we are aware that at this point we do not have sufficient data, and so it must remain a speculation, that what distinguishes the three groups in the first test is their different attitudes to meaninglessness.

Formal logical proofs, and therefore programs – formal logical proofs that particular computations are possible, expressed in a formal system called a programming language – are utterly meaningless. To write a computer program you have to come to terms with this, to accept that whatever you might want the program to mean, the machine will blindly follow its meaningless rules and come to some meaningless conclusion. In the test the consistent group showed a pre-acceptance of this fact: they are capable of seeing mathematical calculation problems in terms of rules, and can follow those rules wheresoever they may lead. The inconsistent group, on the other hand, looks for meaning where it is not. The blank group knows that it is looking at meaninglessness, and refuses to deal with it.

...

The consistent group seem to be much easier to teach. We speculate that they divide into two groups: the very successful ones find programming easy and may perhaps be those who ought to follow a conventional computer-science education, with lots of formal content; the moderately successful perhaps are the software engineers, those who can program but can’t imagine that they will ever enjoy it, and are content to submit to management discipline and to be drowned in UML (ugh!)

Sounds depressing. Everyone loves the Lockean idea of the tabula rasa. That's the underlying principle behind "No Child Left Behind", and why I've had so many people tell me "Anyone can learn X!"¹ But it's wishful thinking - I know from personal experience whatever reason different people exhibit different aptitudes for mathematics and programming. Some people have no talent at all.

I think more research should be conducted here. Is meaningless rule-following consistency the proper test of early programming and mathematical aptitude? Or is there a better early indicator of success? Should students be screened before trying to teach them proofs or programming so teachers don't waste their time?

--------
[1] This is inevitably followed by some advertisement to buy something that will teach me X.

[yadayada]

... nor has it been found to be correlated with any of the aptitudes measured in conventional ‘intelligence’ or ‘problem-solving-ability’ tests. ... We point out that
programming teaching is useless for those who are bound to fail and pointless for those who are certain to succeed.

Having been fluent at one time or another in a couple of dozen computer languages, I have always imagined them to be somewhat analogous to natural languages. Both are most efficiently learned by immersion accompanied by dictionary lookup. The more languages one knows, the easier it becomes to learn a new one. The reason is that while the syntax varies, most of the same old concepts translate from language to language. Programming, in some ways, is simply a way of expressing logical ideas strictly and grammatically.

Meaninglessness may be a much more widespread problem than what was found in learning to program. Just as my specialty of the day is highly meaningful to me in some inexpressible ways, other specialties, even closely related, may be totally foreign and incomprehensible.

[BadgerJelly]

"Anyone can learn X!"

This is true. The problem is not every can learn X at any given time in their lives. Some will need to be influenced from birth to show aptitude and some can easily adjust to techniques alien to them.

I am not saying this is all to do with how plastic your brain is but more a combination of this with preset genetics. I watched something a few months back about a mathematician who didn't seem to have a great genetic set up to give him the edge in mathematics but nevertheless he became a successful mathematician, just not a great one.

I do believe that anyone can learn anything but the problem is finding the method that relates to the individuals cognitive language and interpretation of reality and using these to maximise the most important aspect of learning. Which in my opinion is "passion, want and/or interest.

eg. if you have an interest in painting then this could be used to paint an engine. This would give the artist a greater appreciation of the subject matter and on some level instill an amount of intrigue into further investigation and understanding of the subjects mechanisms. Another way is to look at the subject matter as a form of art in itself.

[flannel jesus]

I'd love to take the tests myself. I feel that my thought-processes are very much in line with the kind of thinking necessary to make a successful programmer, so I'd predict that I'd do well on them -- I'd be of the consistent type.

I do definitely think that the kinds of people who don't understand programming are fundamentally (not superficially, but fundamentally) thinking in a different way from the people that do. They're not just thinking slower, for example -- they're approaching it from a completely different (and arguably incorrect or inappropriate) angle mentally.

[Dave_Oblad]

Hi all,

I agree with FJ.. As a long time programmer, I have always found it simple. Mostly because I understood the hardware involved. The trick in being a good programmer is the ability to break a problem down into manageable chunks. And those chunks into even smaller chunks. This creates a foundation to build upon.

Then you start connecting the small chunks into an architecture that accomplishes a goal. You can keep re-using the small chunks over and over again to create a variety of architectures. If done right, those can be connected together too.. to finish a large scale goal. With this pyramid approach, the final few stones at the top of the pyramid can be accomplished with very few lines of code. Precede this with an initialization of variables and your done. (except for debugging or final tweaks)

Let's say programming is like building a house.

The difficulty I see most often with someone new.. is they attempt to build the whole house at the onset. If you build a house, you start with making a pile of boards, bricks, nails, glass, pipes, fixtures, cement and whatever. Then you build it from ground up. So how do they build a house the first time? I suppose that comes from experience. Start with a bird house.. then a dog house.. etc. Until one gets an idea of what will be required for a full scale house. And especially the order required to build it.

I can't eat a turkey in one bite.. but break it into small enough pieces and it's easy to eat. I guess that's the secret to success.

I believe I'd also test as the consistent type.

Best to all,
Dave :^)

[owleye]

I think the researchers are onto something. Count me among those in the consistent category.

However, I think there's another factor involved, which depends on the ability to keep all the balls aloft in the juggling act of maintaining consistency. I'm not really able to do that very well, but compensate by, wiping the slate and taking another crack at it, though in doing so, I'm never quite being able to "finish" it. (Even so, large projects, say the internet, can come to be so large, that they have a "life of their own" and probably a life-time as well.) In any case, as a side benefit, I remain a bit aloof of the details even though I'm more or less aware of them, and focus on trying to make the meaningless meaningful.

James

[flannel jesus]

Here's one anecdote I've found that perhaps relates to the difference in mental processes of someone who understands how to program and someone who doesn't (it's not that long, and if you're into programming, it's actually quite an entertaining read):

Let me tell a story that is typical of those I heard from the TAs who worked for me at the computing center. A student comes up to the TA and says that his program isn’t working. The numbers it prints out are all wrong. The first number is twice what it should be, the second is four times what it should be,and the others are even more screwed up. The student says, “Maybe I should divide this first number by 2 and the second by 4. That would help, right?” No, it wouldn’t, the TA explains. The problem is not in the printing routine. The problem is with the calculating routine. Modifying the printing routine will produce a program with TWO problems rather than one. But the student doesn’t understand this (I claim because he isn’t reasoning about what state his program should be in as it executes various parts of the program). The student goes away to work on it. He comes back half an hour later and says he’s closer, but the numbers are still wrong. The TA looks at it and seems puzzled by the fact that the first two numbers are right but the others don’t match. “Oh,” the student explains, “I added those 2 lines of code you suggested to divide the first number by 2 and the second by 4.” The TA points out that he didn’t suggest the lines of code, but the student just shrugs his shoulders and says, “Whatever.” The TA endeavors to get the student to think about what change is necessary, but the student obviously doesn’t get it. The TA has a long line of similarly confused students, so he suggests that the student go sit down and think through his calculating procedure and exactly what it’s supposed to be doing. Half an hour later the student is back again. “While I was looking over the calculating procedure, a friend of mine who is a CS major came by and said my loop was all screwed up. I fixed it the way he suggested, but the numbers are still wrong. The first number is half what it’s supposed to be and the second is one-fourth what it’s supposed to be, but the others are okay.” The TA considers for a moment whether he should bring up the student on an honor code charge for receiving inappropriate help, but decides that it isn’t worth it (especially since that line of similarly confused students is now twice what it was an hour ago). He asks the student whether he still has those lines of code in the printing routine that divide by 2 and 4 before printing. “Oh yeah,” the student exclaims, “those lines you said I should put in. That must be the problem.” The TA once more politely points out that he didn’t suggest the two lines of code, but the student again shrugs and says, “Whatever. Thanks, dude!”

The student in my hypothetical story displays the classic mistake of treating symptoms rather than solving problems. The student knows the program doesn’t work, so he tries to find a way to make it appear to work a little better. As in my example, without a proper model of computation, such fixes are likely to make the program worse rather than better. How can the student fix his program if he can’t reason in his head about what it is supposed to do versus what it is actually doing? He can’t. But for many people (I dare say for most people), they simply do not think of their program the way a programmer does. As a result, it is impossible for a programmer to explain to such a person how to find the problem in their code. I’m convinced after years of patiently trying to explain this to novices that most are just not used to thinking this way while a small group of other students seem to think this way automatically, without me having to explain it to them.