[BossingAround]

To teach programming is to take on the following roles:

1) Information provider - search for suitable materials. For example, if the student finds the materials not engaging, it would be your role to find different material that suits the needs of the student better

2) Problem provider - this is extremely important. It is difficult, for example, to care about loops when all the textbooks show only that--loops in isolation. Your role is to construct or find problems that the student can solve with their new knowledge. Generally, the challenges/issues should be one level above the student's knowledge, so that it pushes them forward.

3) Guidance role - it is your job to analyze the students' motivation behind learning how to code, and provide suitable path. E.g. if one wants to become a web designer, it might not be the most suitable to start with assembler. You should also course correct, e.g. when you see a web designer to be struggling with data structures, it is absolutely appropriate to make a detour into some CS territory with data structure classes.

But, of course, most of the learning does the student him or herself. You can't teach anyone anything ever. You can just be there for the student, to help them and guide them.

My 2c as a self-taught developer.

[pfooti]

This is very good advice, especially number 2. Teaching programming, especially to a trainee, is a great opportunity for project-based learning approaches. Give your person problems and tasks that are difficult enough that they have to learn something to do it, but not so difficult that they'll just bounce off of it. Much of being a good teacher is learning to quickly calibrate tasks like this.

Provide help when they need it (critically, also teach them to recognize when they need help, most novices are pretty bad at this), but don't over support (if the student isn't reaching, they probably aren't learning).

Pair programming can also be a great tool in general for learning (with you playing the role of metacognition [1] for the trainee, which again is notoriously difficult for all novices - even experts in other fields have a hard time being metacognitive in new ones). The key there is again: don't prevent all of your trainee's mistakes as they happen, but try to guide them toward noticing them and repairing them before they get too stuck. The other part of teaching that's a learned skill is determining how much struggle / wheel-spinning is productive for your particular student.

All of this is with the caveat that YMMV - people learn best in different ways, but productive struggle and real tasks are really good starting points for most (and way better than lecturing).