Ask HN: How to Teach Coding?

Wow, thanks for your answer.

Point 3 is something I haven't thought of yet. During reviews I pointed on some issues, not every. But that was never something I had a specific reason for, I was just focused on what we want to learn in this lesson.

I will keep that even more in mind now.

Three years is a long time. I've taught bootcamps where I had to do it in 4, 6 or 12 weeks. Three years is luxurious.

Here are my initial thoughts:

- For a timeframe this long it's less "let me teach you" but more "let me guide you in your own learning." If you view this as only imparting knowledge I think you will burn yourself out.

- I would help them formulate a curriculum, keep them on track and make them push themselves. Anyone can learn a lot in three years, but with your guidance they hopefully learn 2x, 3x, 5x or even 10x what they would have learned alone. Ask yourself this every time you check in with them "How can I speed them up? What can I teach them now that will save them time?"

- I would periodically check in and asses what's been learned and what's left to learn. I would also reassess if the curriculum is working or needs tweaking. I would be open to changing things up periodically. Maybe one year is project based work, maybe another focuses on reading classic texts. Three years is a long time to do one thing.

This sounds really fun, good luck and have fun!

I have never liked the “make a sandwich” task. It sets people up for failure, because the teacher can always take things literally enough to make the student wrong. (For example, when given the instructions: "Take out two slices of bread", the teacher can rip open the side of the plastic bag rather than use the opening.) Some students end up with the feeling of “If I can’t even explain how to make a sandwich, how will I ever be able to tell a computer to do anything?”

Here’s an exercise (not sure where I discovered it) that I use at the community college level: https://www.youtube.com/watch?v=meSK1rn2VbA It has the same elements of analyzing a problem, breaking it into steps, and making sure they’re in the right order; but it’s set up for students to succeed.

This exercise is very effective when you put the students in groups of two or three to work on it.

Critically, think about what actually worked for you in your learning. And help your trainee have the same experiences.

I have found that many new teachers to get things across by sharing insights they had only after they understood a subject. But that high level understanding is the result not the cause of mastery.

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