

Ask HN: Best way(s) to teach someone else to program, person to person. - rugoso

I was wondering if you have any sort of experience teaching someone to program, and specially a 1 to 1 kind of teaching, and what's your advice on the matter.
======
ScottWhigham
I have tons of classroom training experience and tons of video training
experience. On those rare days when 1-2 people would show up for training, I
found myself in that situation and it's tough for the trainer. 1v1 - what I
would suggest is that follow a timeline. What can happen is that the trainee
can get stuck on one item (big or small, doesn't matter) and then you find
yourself spending 2 hours explaining what a classroom would spend 10 minutes
on. People tend to get frustrated and think that asking 100 questions is the
best way to learn. Sometimes it is, sometimes it isn't. Sometimes "64
Questions" just leads you into an area that the user isn't ready to go - _no
matter if they think they are or not_.

So pick a timeline, agree in advance that, "If you get stuck on something,
we'll try to work it out but we must make it through this section by 3:00PM
today no matter what."

2nd piece of advice - don't let them ask so many questions that they take you
off topic or into areas that your timeline has you covering later. "We're
going to cover that in a bit..."

Training is an area in which the trainee can make or break the experience. A
trainee that lets you be their guide will learn from a good trainer but a
trainee that tries to wrestle control from even a great trainer will not learn
much.

------
aasarava
I've done this a few times (C++, PHP, HTML, CSS, etc.) and it seems to work
best when you treat it as if you're teaching someone to drive a car: Both of
you are sitting side by side in front of the same computer, with the trainee
driving.

First, I like to show the person some feature in the program or Web site, like
say a popup window. Then I show them the code for that window. Then I show
them how to modify different components by adjusting variables and so on, so
that they get the feel for where all the moving parts are and see how their
changes directly affect the popup window.

Then, I have them write a basic function that does the same thing, but this
time from scratch. Once we go over what worked and didn't and debug the code
and get things working, we move on to a second function or construct.

Ultimately, the goal is to start small and continue expanding from there, kind
of like having the trainee drive around a parking lot, then city streets, then
the freeway.

Most importantly, I find that the key is to keep building on the same code,
and helping the trainee see their program grow into something useful -- as
opposed to simply showing them one construct in the abstract and then another
and then another, without tying them together in any way.

------
raquo
I was tought PHP that way (I only used to program in Delphi before a bit).
Initially, I read the basic parts of the PHP manual (about syntax, etc), then
we and my friend (a PHP master) sat for about 5 hours and wrote code that did
a lot of different stuff - cycles, regexps, reading files, basic XML parsing,
etc. Of course I forgot it all in the next several hours, but I later often
returned to it to see how to do various stuff (we commented the code
generously). Useful, especially given the lack of examples for some topics in
the PHP manual. Although this is probably not the kind of teaching you
meant...

~~~
rugoso
thanks raquo, and yes, this is kind of the teaching i meant ;)

this is certainly useful information for me, something i could try

