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.


Reply via email to