Teaching programming
In about a month I'm going to apply to a TA job for an introductory course and for OOP.
The test is to give a public class, the subject will be decided a few days before.
Just wanted to know if you've got any suggestion, or care to share your experience as a teacher or an student.
Can't recall my own, only that really learn when joined a group to participate in the ICPC.
Regards
The test is to give a public class, the subject will be decided a few days before.
Just wanted to know if you've got any suggestion, or care to share your experience as a teacher or an student.
Can't recall my own, only that really learn when joined a group to participate in the ICPC.
Regards
I'm a TA (actually, I'm not; I'm a researcher, but since my boss doesn't have a TA, I get to do it once in a while) at a University. Programming is most definitely not the main focus of the courses I assist, but it's considered a "necessary skill" (read: one semester of Intro to Java & OOP, 90% fails, scores are raised artificially and after deliberations about 80% "passed"). When an assignment involves a bit of programming, all hell breaks loose, and it's my job to guide the students.
I few things I've learned:
a) Assume your class knows nothing. Not because that's the case, but because any other assumption on their background knowledge is wrong. Things "everyone knows" are, in fact, not known by everyone.
b) State the obvious, then state it again. Remember back in school when you got annoyed because your teacher spent so much time on obvious things and skimmed over harder parts? It'll start making sense now. Once they understand the basics (and trust me: most of them still won't, regardless of how often you repeat it), they can do the harder parts by themselves. If they don't understand the basics, they're lost forever.
c) Code is scary. Intro to Java was a mandatory course which many failed, and even the sight of a line of code will send most students back into fetal position. Focus on explaining the logic, not the syntax. Use analogies. My favourite way of teaching the basics of programming is by telling a story that keeps on building on itself (see below).
d) Force your students to do exercises throughout the year. It's more work for you (and for them; they'll hate you for it), but it's the only way. Students that try to learn their Java right before the exam fail. There are very few exceptions, and those are usually people with prior experience anyway, who can do the exercises in a few minutes.
e) Teach your students to start programming on paper. Step 1: write down what your program must do. Step 2: high-level pseudocode. Step 3: low-level pseudocode. Step 4: boot computer and implement. Once they get more experience, they can drop step 3 if they want. Force them to do step 1 and 2, e.g. by including it in the exercises.
*Intro to Java story:
I always use the "dimwitted restaurant/bank employee" story. It's about a new employee that can't think for himself, but does exactly what you tell him to. He represents the program. The restaurant/bank manager is teaching him, step by step, how to do his job. He represents the programmer.
Use a few bogus "functional" methods (e.g. "greetCostumer", "getOrder", "bringFood", etc.) as filling, then start explaining different core elements step by step by continuing the story, e.g.
Phase 1: (calling functions) pretend customer, go greet and get order.
Phase 2: (conditions) if there is a customer, go greet and get order; else do the dishes.
Phase 3: (for loop) assume there are infinite customers, go greet and get the order of 50.
Phase 4: (while loop) repeat phase 3 for all the remaining customers.
Once OOP/Classes come into play, you can introduce a second character ("dimwitted chef") and have the two work together.
Ultimately, the program/story I ended up with interplay between the following:
Customers: arrivals generated randomly [this was the setup for a simulation exercise]. Could have the state "new", "ordered" and "finished". In an alternate version, the concept of customers was replaced with "seats"/tables, of which there were a limited number.
Dimwitted Waiter: starts idle. If a new customer enters and the waiter is idle, customer must wave() to activate the waiter (or trigger on arrivals). If new customers are available, it greets and get orders (assumed instant-decisions); if food was ready, it would bring it. When no customer/food was available, it would go idle again.
Dimwitted Chef: starts idle. When a new order comes in, the Waiter activates him and he starts cooking. As long as orders are available, he keeps cooking. When food is finished and the waiter is idle, he yells to reactive the waiter. When no orders are available, he becomes idle again.
The final story had quite a few interesting mechanics to explain:
a) An event generator that spawns arrivals.
b) A queue for cooking orders for the chef.
c) A priority-queue for orders for the waiter (food delivery > greeting).
The year I started had the best results in student scores. I'd like to credit my teaching, but it's probably because I gave them much more hints and tips for the exam. Nevertheless, I still like using the story-method. It makes it understandable without being technical. Explaining a priority-queue to a bunch of airheads is not the easiest thing in the world, but I think a few of them still know what it is.
I few things I've learned:
a) Assume your class knows nothing. Not because that's the case, but because any other assumption on their background knowledge is wrong. Things "everyone knows" are, in fact, not known by everyone.
b) State the obvious, then state it again. Remember back in school when you got annoyed because your teacher spent so much time on obvious things and skimmed over harder parts? It'll start making sense now. Once they understand the basics (and trust me: most of them still won't, regardless of how often you repeat it), they can do the harder parts by themselves. If they don't understand the basics, they're lost forever.
c) Code is scary. Intro to Java was a mandatory course which many failed, and even the sight of a line of code will send most students back into fetal position. Focus on explaining the logic, not the syntax. Use analogies. My favourite way of teaching the basics of programming is by telling a story that keeps on building on itself (see below).
d) Force your students to do exercises throughout the year. It's more work for you (and for them; they'll hate you for it), but it's the only way. Students that try to learn their Java right before the exam fail. There are very few exceptions, and those are usually people with prior experience anyway, who can do the exercises in a few minutes.
e) Teach your students to start programming on paper. Step 1: write down what your program must do. Step 2: high-level pseudocode. Step 3: low-level pseudocode. Step 4: boot computer and implement. Once they get more experience, they can drop step 3 if they want. Force them to do step 1 and 2, e.g. by including it in the exercises.
*Intro to Java story:
I always use the "dimwitted restaurant/bank employee" story. It's about a new employee that can't think for himself, but does exactly what you tell him to. He represents the program. The restaurant/bank manager is teaching him, step by step, how to do his job. He represents the programmer.
Use a few bogus "functional" methods (e.g. "greetCostumer", "getOrder", "bringFood", etc.) as filling, then start explaining different core elements step by step by continuing the story, e.g.
Phase 1: (calling functions) pretend customer, go greet and get order.
Phase 2: (conditions) if there is a customer, go greet and get order; else do the dishes.
Phase 3: (for loop) assume there are infinite customers, go greet and get the order of 50.
Phase 4: (while loop) repeat phase 3 for all the remaining customers.
Once OOP/Classes come into play, you can introduce a second character ("dimwitted chef") and have the two work together.
Ultimately, the program/story I ended up with interplay between the following:
Customers: arrivals generated randomly [this was the setup for a simulation exercise]. Could have the state "new", "ordered" and "finished". In an alternate version, the concept of customers was replaced with "seats"/tables, of which there were a limited number.
Dimwitted Waiter: starts idle. If a new customer enters and the waiter is idle, customer must wave() to activate the waiter (or trigger on arrivals). If new customers are available, it greets and get orders (assumed instant-decisions); if food was ready, it would bring it. When no customer/food was available, it would go idle again.
Dimwitted Chef: starts idle. When a new order comes in, the Waiter activates him and he starts cooking. As long as orders are available, he keeps cooking. When food is finished and the waiter is idle, he yells to reactive the waiter. When no orders are available, he becomes idle again.
The final story had quite a few interesting mechanics to explain:
a) An event generator that spawns arrivals.
b) A queue for cooking orders for the chef.
c) A priority-queue for orders for the waiter (food delivery > greeting).
The year I started had the best results in student scores. I'd like to credit my teaching, but it's probably because I gave them much more hints and tips for the exam. Nevertheless, I still like using the story-method. It makes it understandable without being technical. Explaining a priority-queue to a bunch of airheads is not the easiest thing in the world, but I think a few of them still know what it is.
Just realized you only get to do a single class on the subject...
Most of the hints are still proper. Find a single, good analogy that starts simple but can be expanded to encompass everything in your class. Make it something relatable. Everyone knows a dimwitted waiter.
Speak slowly and steadily. If you run out of time, drop part of the class, rather than finishing everything at a crazy pace. Time your lecture. If you have an hour, aim for 45 minutes. Make sure you know which parts are vital and which aren't, in case you have to skip anything. Practice, practice, practice!
Don't be afraid to ask questions, but don't overdo it. If you get no reaction, don't bother waiting for answers too long. Reaction doesn't just mean answers; it also means facial expressions. I always order my questions by difficulty and start of with "the first X are basic; if you don't know the answer, it's time to pick up the slack". If you see a few students getting uneasy during one of those questions, you know you've lost a few. For the more difficult questions, no raised hands usually means nobody knows the answer; students are more eager to answer these questions than the really obvious ones (never understood why; I did the same as a student...).
If someone gives a wrong answer, make sure to explain why their answer isn't correct and why yours is. The answer itself is generally useless; the logical steps required to get to the answer are much more important. Whether a student's answer is right or wrong, have them explain how they got there.
The hardest part is finding a right tone. Some teachers are very strict, some are very friendly. I think most teachers want to be friendly, but lose control of the class and ultimately end up becoming strict to maintain order. Fear is much easier than respect.
As a TA, I'm not much older than my students (2 years at most; some students are older than I am). I'm also quite small and young-looking. Playing strict just wasn't an option, because if one thing goes wrong, all your credibility is gone. As a Friendly teacher, you can play the "disappointment card" when they get loud. Rather than actually controlling their behaviour, you just guilt-trip into behaving properly.
In closing: know your audience. I teach last-year University students, early/mid twenties. They're not very rebellious; the "bad boys" are weeded out, or just don't come to class [hint: non-mandatory attendance = less frustration]. If you're teaching late-teens, you're going to need a different approach, but I wouldn't know which. Ask the person testing you about the background of your students. How old are they? How noisy are they? How many are there?
And... if things go bad: know what power you have and don't have. Can you send them out? If they refuse to leave, do you have an alternative way of punishing them? Keep worst-case scenarios in mind. If things go wrong, you need to handle it properly, or you risk losing all your credibility. Don't bluff: if you say you're going to throw someone out, throw them out. If they call your bluff, it's over. Instead of threats, use fake-negotiations first. "If you're quiet for a few more minutes, I'll end the class early." They don't know when the class ends, so that's a few more minutes of silence for you, free of charge.
And finally... never get angry. It has no positive effect. You'll feel shitty, and the class won't get any better. The only person who can pull of a good moment of rage is "that friendly, calm teacher you've had for 5 years". When that guy gets angry, shit is up.
Most of the hints are still proper. Find a single, good analogy that starts simple but can be expanded to encompass everything in your class. Make it something relatable. Everyone knows a dimwitted waiter.
Speak slowly and steadily. If you run out of time, drop part of the class, rather than finishing everything at a crazy pace. Time your lecture. If you have an hour, aim for 45 minutes. Make sure you know which parts are vital and which aren't, in case you have to skip anything. Practice, practice, practice!
Don't be afraid to ask questions, but don't overdo it. If you get no reaction, don't bother waiting for answers too long. Reaction doesn't just mean answers; it also means facial expressions. I always order my questions by difficulty and start of with "the first X are basic; if you don't know the answer, it's time to pick up the slack". If you see a few students getting uneasy during one of those questions, you know you've lost a few. For the more difficult questions, no raised hands usually means nobody knows the answer; students are more eager to answer these questions than the really obvious ones (never understood why; I did the same as a student...).
If someone gives a wrong answer, make sure to explain why their answer isn't correct and why yours is. The answer itself is generally useless; the logical steps required to get to the answer are much more important. Whether a student's answer is right or wrong, have them explain how they got there.
The hardest part is finding a right tone. Some teachers are very strict, some are very friendly. I think most teachers want to be friendly, but lose control of the class and ultimately end up becoming strict to maintain order. Fear is much easier than respect.
As a TA, I'm not much older than my students (2 years at most; some students are older than I am). I'm also quite small and young-looking. Playing strict just wasn't an option, because if one thing goes wrong, all your credibility is gone. As a Friendly teacher, you can play the "disappointment card" when they get loud. Rather than actually controlling their behaviour, you just guilt-trip into behaving properly.
In closing: know your audience. I teach last-year University students, early/mid twenties. They're not very rebellious; the "bad boys" are weeded out, or just don't come to class [hint: non-mandatory attendance = less frustration]. If you're teaching late-teens, you're going to need a different approach, but I wouldn't know which. Ask the person testing you about the background of your students. How old are they? How noisy are they? How many are there?
And... if things go bad: know what power you have and don't have. Can you send them out? If they refuse to leave, do you have an alternative way of punishing them? Keep worst-case scenarios in mind. If things go wrong, you need to handle it properly, or you risk losing all your credibility. Don't bluff: if you say you're going to throw someone out, throw them out. If they call your bluff, it's over. Instead of threats, use fake-negotiations first. "If you're quiet for a few more minutes, I'll end the class early." They don't know when the class ends, so that's a few more minutes of silence for you, free of charge.
And finally... never get angry. It has no positive effect. You'll feel shitty, and the class won't get any better. The only person who can pull of a good moment of rage is "that friendly, calm teacher you've had for 5 years". When that guy gets angry, shit is up.
| the sight of a line of code will send most students back into fetal position |
Perhaps they are in the wrong class then?
Nice posts, though.
I don't know how relevant it would be, but to
| share your experience as a teacher |
When I was teaching (12 years ago, for two years, jumpstarting the new curriculum that I wrote for the college I graduated earlier), the last 15 minutes of *every* class were a test, where each student had to write code that makes use of what I just talked about. This wasn't unusual, our college policy actually encouraged that: midterms+finals counted for only half of the course credits.
Inspired by a math professor (excellent group theory researcher, who completely reversed my opinion about math) who did that before, I set myself the goal to give each student a personalized problem every single time. There were about 25 of them, and it was not easy coming up with problems on the spot, some of them came out too easy, some too hard, some embarassingly dull.. but it did help establish connections, I soon knew each student's level and could (some of the time) tailor the problems that would push them but not break them, or at least would help them actually learn what they just heard.
First of all, thanks to Gaminic for the really interesting, well-written and well structred post. These are lots of really good approaches for teaching coding but also teaching in general.
I think teaching can be an amazing thing if everything works out but it could also be frustrating and exhausting.
If you you follow Gaminic's suggestions you should be just fine.
If you need some more excercise or a structure for a lesson you could also take a look at the online class codecademy.
I like their basic exercises.
Good luck and don't worry!
Petee
I think teaching can be an amazing thing if everything works out but it could also be frustrating and exhausting.
If you you follow Gaminic's suggestions you should be just fine.
If you need some more excercise or a structure for a lesson you could also take a look at the online class codecademy.
I like their basic exercises.
Good luck and don't worry!
Petee
Topic archived. No new replies allowed.