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.
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.
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.
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...
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.