Ask HN: Teaching programming to high-school students
I have volunteered to teach (substitute) a split high-school class of Grade 11 and Grade 12 students, where the Grade 12 students are much more advanced. I have never taught high-school students before.
The classes are ~80 minutes each and there are four classes; Java is the language of choice. The advice from my friend, for whom I will substitute, has been:
- Use a lecture, work, lecture, work style. - Use pair programming.
In a recent HN post, someone mentioned explaining algorithms using a paperless process: describe how to make a PB&J sandwich, which I thought was brilliant.
What other advice, teaching tools, or devices would you recommend that I use to help capture their imaginations and inspire the next generation of software developers?
Thank you!
4 comments
[ 81.4 ms ] story [ 616 ms ] threadTeach them the core basics, and give them a template they can use to get new programs up and running. You want to teach core programming concepts, but not lose them in the overwhelming nature of getting going from scratch.
Once they have the basics grasped (base types, variables, setting values, comparisons, arithmetic, etc), give them a small project based on something they're interested in. Maybe it's sports, so have them write something that would help a manager keep track of his players, their stats, etc
Maybe its cars, so have them write a program that helps someone keep track of car parts, or car information, etc.
The key will be engaging them and getting them to understand how to apply what they learn to real world situations and needs.
Just my 2 cents
Let them decide. It's better to let them do what they want best, than do what you want. It would be more fun.
My opinion on this matter is that the actually starting with some hands on material is much better than explaining a programming process. Mostly because beginner programming is fairly easy to understand without learning a proper process - and I'm not saying that proper process isn't important, it very much so is - I'm saying that it would probably be a lot more enjoyable to actually have them solve simple solutions first.
I find that my favorite part as someone with still much to learn about programming is the ability to find my own neat solutions and try to make them work.
2 things:
1. First off, before anything else, you want to make sure you've got classroom discipline in order or you'll never be able to teach anything. You basically want to start off tough, not smiling, and with high expectations. Then reward their hard work by easing up a bit as you go. Right from day one:
* Try to memorize some names ahead of time. You should have a computerized attendance system where you can see pictures of the students.
* You arrange seating on day one. You are the boss. Let them know it. You are not their friend.
* Have some simple class rules ready on day one. Go over those rules on day one.
That said, it sounds like older students, and it's an elective class, so you shouldn't have much discipline trouble (though don't bet on it). In all likelihood you can start easing up on discipline after a few days and everything will be fine --- but they must know that you'll bust them if they do anything that damages the learning environment you're trying to create.
2. Aside from discipline, here's my advice on actual teaching: At first, you want to alternate between "smart small and get fun things working" and "grand overview to give them a feel for what the heck they're doing". For example, on day one you might be doing stuff like telling them exactly what to type to make something interesting happen. Once you've shown them that they can produce neat stuff, they're going to want the overview stuff. After enough overview stuff, they're going to be like, "ok, enough already, let me do it". Then after some labs when they've moved on and are getting frustrated again, you go back into "overview" mode again. And so on.
Soon, your handholding isn't as explicit anymore, and your grand overviews start to get deeper, and you find yourself settling into the standard "lecture, work, lecture, work" style.
* * *
Regarding the split between the grade levels, I'd suggest trying to arrange things so that sometimes the more experienced students are working on their projects while you work with the less-experienced students to help them catch up. Relying on pairing less-experienced with more-experienced to have the more- teach the less- will probably lead to resentment ("I didn't sign up for this to teach! I signed up to code!").