Some arbitrary thoughts 1. 'Learning to program' is not atomic - it might include the syntax and semantics of a given language, learning abt data structures and algorithms, trying to understand a given paradigm (eg OOP), developing problem-solving skills. So maybe different parts of learning to program would each show relationships with other domains. 2. I'm not sure subitizing is a good example, because it is so 'fundamental'. Many animals can subitize. Only humans with severe learning difficulties are unable to subitize. Subitizing in tens is more like 'chunking'. 3. 'Scaffolding' in the sense of Vygotsky's ZPD and Bruner's scaffolding works well. But I know some sports psychologists favour a 'just do it' approach. Like you can try to improve your golf swing by following rules about where your head is and how you hold the club and where your feet should be, but if you try to follow all this the cognitive load is so high there is nothing left to pay attention to hitting the ball. (I don't play golf but I know this works when trying to cast a fly). Maybe this is why professional programmers are saying 'counting' (in another branch of this) - they are focussing on 'just doing it'.
________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guzdial, Mark Sent: 27 June 2007 21:06 To: Lindsay Marshall; Peter Gutmann; [EMAIL PROTECTED]; discuss@ppig.org; [EMAIL PROTECTED] Subject: RE: PPIG discuss: Programmer education argument-starter of the week -----Original Message----- From: Lindsay Marshall [mailto:[EMAIL PROTECTED] Sent: Tue 6/26/2007 4:27 PM To: Guzdial, Mark; Peter Gutmann; [EMAIL PROTECTED]; discuss@ppig.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: PPIG discuss: Programmer education argument-starter of the week > We know relatively little about what leads to success in programming. An interesting question then is how much we know about learning anything! Why do we think learning to program is different from learning anything else? ===== AGREED! Great question! Learning to program can't be different from any other kind of learning. Programming is too new to believe that we have evolved any particular new forms of learning that are particular to programming. You can pick your favorite neural or cognitive model of learning -- it's got to be the same for programming as math, art, science, or engineering. The reason for studying how people learn (and not learn) to program is because we can help them to do it better by understanding the domain and the task of learning that domain. For example, Gerhard Fischer (with John Seely Brown) wrote an article many years ago now about how skiing instruction was dramatically improved by considering how to use scaffolding to make it easier to focus on one skill at a time. The domain-specific education field that has made the most progress is mathematics education (though reading education may be as advanced). Mathematics education researchers have studied how children come to learn the concept of number, and in so doing, have learned about previously invisible enabling skills which, if missing, inhibit a child from learning mathematics. My favorite of these is subitizing. Subitizing is the ability to look at a set of items and know how many are there without counting. Everybody can do it for one to three items. More than that, we have to count--unless the items are in a well-known shape (like five or six on a die or a domino). Math ed researchers have found that the lack of subitizing skill (especially for sets of five and ten) inhibits later math learning. They have found ways of testing for subitizing skill and helping students develop that skill in preschool so that their math development isn't inhibited. What are the computing/programming analogous skills to subitizing? Let's consider the students who aren't learning to program in all our experiences. If we're agreed that there is no "geek gene," then it's not nature -- it must be nurture. The students who are learning to program have had some experience which has led to learning some skill/concept that the other students don't have. What might that be? - Maybe our students who learn to program more easily have more experience writing down or executing instructions? Maybe they have a stronger understanding of some underlying concept of what it means to define a process for another agent? - Maybe our students who learn to program more easily have had more experience thinking about repetitive tasks, how to describe them, or how to create shortcuts for them? In which case, they may have a stronger recognition of the need for an iteration control structure and what would be needed to keep the iteration from going on forever? So, the point isn't that learning to program is inherently different. It's different in the same ways as learning any domain is different from learning other domains. By understanding more deeply the challenges of learning to program, we can better help those students who do struggle and seem unable to learn to program.