Hi Rhino,

Thanks a lot.
Wishing You Merry Christmas and Happy Holidays.

Regards,
VMogana

On Sat, 24 Dec 2005 12:12:36 -0700, "Luc The Perverse"
<sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly
quoted someone who said :

In the 90s I wrote a column for the Computer Paper on my theories
based on my experiences as head instructor at a computer camp where
the kids blew me away with how fast they learned.

The key tricks are these:

1. this is a kid's environment. Lots of noise, chaos, goofy stuff.

2. When I speak I demand absolute silence. In return I speak no more
than a couple of carefully planned sentences,  dramatic if possible. I
don't repeat myself publicly.  I want them hanging on my every word.
The last kid to stop talking I made run out of the room a block or so
away  to ring a bell then run back.  It was not that much of a
punishment, since the kid got the fun of making his classmates laugh
when they heard the bell. But I did get rapt attention.

3. Leaking.  I teach something to a small group of kids I don't teach
to the others. This becomes their secret weapon to use in their
programs.  The kids see the results, and either wheedle the
information out of the "privileged" kids, or chase me around to tell
them too.  You have never seen kids so motivated to learn trig!

4. example code.. This code does a simple version of what the kids
want to.  It is commented to death.  They can just type it in to try
it out.  In the process of getting the typos out the have it pretty
well understood and are well on their way to theme and variations.

5. Graduated bang for buck. On day one, all the student had to do was
his a function key and you would be rewarded with a randomly sized,
placed, and coloured helicopter. You got maximal reward for least
effort.  As time progressed the student had to work ever harder for
ever more subtle rewards in fine control.

6. Order of presentation. I taught methods first, iteration and random
numbers second, and arithmetic third.  It was absolutely natural in
drawing for kids to organize methods into hierarchies of reusable
components they could share.

7. Learn by experiment.  I presented the editor this way. These keys
do something.  See how many of them you can figure out what they do.
The emphasis is that computers are SUPPOSED to be mysterious and
undocumented. It is supposed to be puzzle to figure out. You are not
supposed to get it on your first try.

8. Let the kids teach each other. They have their own ways of
explaining things. They can do it in parallel much faster than I can.
All I have to do is give enough of a hint so that a few students
figure it out. It then ripples throughout the class by student to
student interaction.

9. On opening day I gave a little introductory speech where I said
something like. I have interviewed you all and it is clear you want
more than anything to learn to write your own computer games.  I
promise I will not teach you ANYTHING that is not necessary to write
computer games.  Unfortunately, sometimes it won't be clear why you
need to learn something, so you will just have to trust me.

10. Graph paper.  One of the very first exercise I did was hand out
graph paper and ask each kid to draw a Pac Man or similar simple
figure, with polygons, and label all the vertices with the absolute
co-ordinates.  As each kid (ages 7 to 15) completed the task they
brought it to me or one of my assistants for checking.  If they had it
right they went off to another room where the computers were.  There
they were shown how to type the polygon vertices into the computer
into a simple skeleton drawing program and see their creation
realised, usually in hideously garish colours.  The unconscious lesson
the kids learned was the planning was hard, but the computers were
easy.  The kids only had a few short sessions a day of computer
access. The rest of the time they were doing traditional summer camp
things.  But the kids would carry about sheafs of graph paper to plot
out their masterpieces in ever spare moment.

11. I remember my entire childhood quite vividly. I recall adults
being so patronising. I tried hard not to do that.

Caveat. This style of teaching is utterly exhausting. You could not do
it full time or without an incredibly good support staff as I had.
Some kids are freaked by the pandemonium, or the competitive pressure
that develops even when I don't consciously foster it.

At UBC, teaching people slightly older than I was, I used different,
but unconventional techniques. There the problem is keeping students
awake.

So I banned note taking. I had contests, often with two teams, with
points for answering questions, solving problems at the board (done
say 5 from a team at a time).  

The winning team would get chocolate bars (only a nickel back then),
or selections from the local bakery.

The idea here was even if the student did not care about the class he
did not want to let down his team.

On opening day I would say, "No student of mine has ever failed.  So
you can relax. However, you would probably find you will spend more
time on this course than any other."

The class was supposed to be an hour, but often student would hang
around for 6 hours before the last one went home.

I spent lots of time on theme and variation of the fundamentals, which
panicked the students because we were "behind". But my students
thoroughly got them so they could write code in their sleep (or under
exam pressure).  Then it was pretty easy to add the fancy stuff later
on that solid foundation.

I think that the only "insight" is realizing that it all depends on
the teacher. Skilled teachers can teach anything using any technique
but they need to have similar talents to good actors or court room
lawyers. They must love playing to the audience and be sensitive to
it. The are thrilled when they have the audience in rapt attention and
are able to detect and react when they are losing their attention.

Technical teaching skills and the use of teaching aids can be learned
but, as in any other profession, they are no substitute for talent.
and there a