Wanted: Advice from CS teachers
-
Example of the problem:
Me: "OK everyone. Next we'll make this into a function so we can simply call it each time-"
Student 1: "It won't work." (student who wouldn't interrupt like this normally)
Student 2: "Mine's broken too!"
Student 3: "It says error. I have the EXACT same thing as you but it's not working."
This makes me feel overloaded and grouchy. Too many questions at once. What I want them to do is wait until the explanation is done and ask when I'm walking around.
@futurebird I have on occasion worked with software professionals who behave much the same way.
-
So Your Code Won't Run
1. There *is* an error in your code. It's probably just a typo. You can find it by looking for it in a calm, systematic way.
2. The error will make sense. It's not random. The computer does not "just hate you"
3. Read the error message. The error message *tries* to help you, but it's just a computer so YOUR HUMAN INTELLIGENCE may be needed to find the real source of error.
4. Every programmer makes errors. Great programmers can find and fix them.
1/
@futurebird this is a great outline for a “debug” lesson. I try to scaffold up to writing their own code over the semester:
Assignment 1 Read code: give them working code and they add comments.
Assignment 2 Debug code: give them broken code WITH comments of what it’s SUPPOSED to do and see if they can fix it. Both typos and logic errors. But I give this assignment after teaching about break points and other debugging tools.
Only after that are they allowed to start writing code. After that they tend to bug me less in class with their errors (pun intended
). -
Wanted: Advice from CS teachers
When teaching a group of students new to coding I've noticed that my students who are normally very good about not calling out during class will shout "it's not working!" the moment their code hits an error and fails to run. They want me to fix it right away. This makes for too many interruptions since I'm easy to nerd snipe in this way.
I think I need to let them know that fixing errors that keep the code from running is literally what I'm trying to teach.
@futurebird I've never taught a class, but my first thought is to try starting with a live-coding session where I make mistakes myself
-
@futurebird I have on occasion worked with software professionals who behave much the same way.
Well perhaps they have nostalgia for those responsibility-free middle school days.
-
Example of the problem:
Me: "OK everyone. Next we'll make this into a function so we can simply call it each time-"
Student 1: "It won't work." (student who wouldn't interrupt like this normally)
Student 2: "Mine's broken too!"
Student 3: "It says error. I have the EXACT same thing as you but it's not working."
This makes me feel overloaded and grouchy. Too many questions at once. What I want them to do is wait until the explanation is done and ask when I'm walking around.
@futurebird I try to separate clearly the moments when they code and the moments when I explain stuff. When I explain, they have to listen (not look at their computers). They naturally tend to not interrupt with “it doesn't work” comments, and usually ask interesting questions. For this to work, I always promise that I will share with them the code I typed I front of them (for that, I use my institution's platform).
-
Sometimes I have them write the code on paper with the computers closed. And this is fine, but I'd rather have them using the IDE or textedit and there is a limit to how much fun you can have with code on paper.
And it does tend to be the weaker students who are almost happy to find something to stop the onslaught of information "see it doesn't work! we can't go on!" and that obviously makes me very grouchy.
I need them to see this is like saying "Teacher my pencil broke! Stop the lesson!"
@futurebird can I ask : is this a “recent” phenomenon? I don’t really recall this behaviour except as an outlier when I did CS (which was a while ago…)
-
@futurebird can I ask : is this a “recent” phenomenon? I don’t really recall this behaviour except as an outlier when I did CS (which was a while ago…)
It's always been a thing though I do think it's been getting a little better.
-
Example of the problem:
Me: "OK everyone. Next we'll make this into a function so we can simply call it each time-"
Student 1: "It won't work." (student who wouldn't interrupt like this normally)
Student 2: "Mine's broken too!"
Student 3: "It says error. I have the EXACT same thing as you but it's not working."
This makes me feel overloaded and grouchy. Too many questions at once. What I want them to do is wait until the explanation is done and ask when I'm walking around.
@futurebird I’ve mostly taught adults, so this might not work for you, but I would try explaining that at the end of the lecture, you don’t need them to have working code, you need them to have a working understanding. They’re missing the important part of class, the learning, to focus on an unimportant part of class, producing a working program. If it’s not working, focus up and wait until we have a pause. To me, this sounds more like an etiquette question than a programming one.
-
@futurebird I try to separate clearly the moments when they code and the moments when I explain stuff. When I explain, they have to listen (not look at their computers). They naturally tend to not interrupt with “it doesn't work” comments, and usually ask interesting questions. For this to work, I always promise that I will share with them the code I typed I front of them (for that, I use my institution's platform).
@futurebird Another problem is explaining to them that errors are good and that the compiler is their friend, as you already explained. It's not easy with C, for instance, where the compiler spits very obscure error messages.
Good luck!
-
@futurebird I’ve mostly taught adults, so this might not work for you, but I would try explaining that at the end of the lecture, you don’t need them to have working code, you need them to have a working understanding. They’re missing the important part of class, the learning, to focus on an unimportant part of class, producing a working program. If it’s not working, focus up and wait until we have a pause. To me, this sounds more like an etiquette question than a programming one.
@futurebird maybe even just a “it doesn’t need to compile right now, we’re focused on <concept>” and leaving the compiler angry
-
Wanted: Advice from CS teachers
When teaching a group of students new to coding I've noticed that my students who are normally very good about not calling out during class will shout "it's not working!" the moment their code hits an error and fails to run. They want me to fix it right away. This makes for too many interruptions since I'm easy to nerd snipe in this way.
I think I need to let them know that fixing errors that keep the code from running is literally what I'm trying to teach.
@futurebird That does sound frustrating, especially if you have a good flow with the lesson and then have to stop suddenly. I'm not a school teacher, but I mentor a robotics team, and we always code in pairs with one student "driving" and the other just observing for errors. It means we stop less for small silly things like typos, but also enforces the idea that there *will* be errors, it's just how coding works. I'll say, "it takes four eyeballs," and then they don't feel too bad about messing up. Usually then the students can check in with their partner first if something is wrong, and not just immediately call an adult over. I don't know how this would translate to a classroom setting though, might get loud.
-
Wanted: Advice from CS teachers
When teaching a group of students new to coding I've noticed that my students who are normally very good about not calling out during class will shout "it's not working!" the moment their code hits an error and fails to run. They want me to fix it right away. This makes for too many interruptions since I'm easy to nerd snipe in this way.
I think I need to let them know that fixing errors that keep the code from running is literally what I'm trying to teach.
@futurebird Do they work in groups? And ask them to consult with other groups . Record that plays "It isn't broken, the code is doing exactly what you asked it to do" on loop.
-
Example of the problem:
Me: "OK everyone. Next we'll make this into a function so we can simply call it each time-"
Student 1: "It won't work." (student who wouldn't interrupt like this normally)
Student 2: "Mine's broken too!"
Student 3: "It says error. I have the EXACT same thing as you but it's not working."
This makes me feel overloaded and grouchy. Too many questions at once. What I want them to do is wait until the explanation is done and ask when I'm walking around.
I’ve taught programming like this, but I’m an increasingly huge fan of the debugging-first approach that a few people have been trying more recently. In this model, you don’t teach people to write code first, you teach them to fix code first.
I’ve seen a bunch of variations of this. If you have some kind of IDE (Smalltalk is beautiful for this, but other languages usually have the minimum requirements) then you can start with some working code and have them single-step through it and inspect variables to see if the behaviour reflects their intuition. Then you can give them nearly correct code and have them use that tool to fix the issues.
Only once they’re comfortable with that do you have them start writing code.
Otherwise it’s like teaching them to write an essay without first teaching them how to erase and redraft. If you teach people to get stuck before teaching them how to unstick themselves, it’s not surprising that they stop and give up at that point.
-
@futurebird I usually have clear me/them speaking parts in the course. While I speak, they listen, which I enforce up to the last whisper.
Also, the "me" parts only take 15-20 minutes each, then it's time for questions, https://github.com/ineiti/livequiz, or other interactions.
For the exercise sections, the "me" parts are of course much shorter.
-
I’ve taught programming like this, but I’m an increasingly huge fan of the debugging-first approach that a few people have been trying more recently. In this model, you don’t teach people to write code first, you teach them to fix code first.
I’ve seen a bunch of variations of this. If you have some kind of IDE (Smalltalk is beautiful for this, but other languages usually have the minimum requirements) then you can start with some working code and have them single-step through it and inspect variables to see if the behaviour reflects their intuition. Then you can give them nearly correct code and have them use that tool to fix the issues.
Only once they’re comfortable with that do you have them start writing code.
Otherwise it’s like teaching them to write an essay without first teaching them how to erase and redraft. If you teach people to get stuck before teaching them how to unstick themselves, it’s not surprising that they stop and give up at that point.
Tangentially related:
"AI can write code so why teach how to code?"
"Great point! It can write an essay too, so why teach how to read."
Like. We've had calculators for decades and still teach arithmetic. And functionally the average person needs to know probably more about mathematics and needs to read more than they did a century ago. The same will apply for code.
-
Tangentially related:
"AI can write code so why teach how to code?"
"Great point! It can write an essay too, so why teach how to read."
Like. We've had calculators for decades and still teach arithmetic. And functionally the average person needs to know probably more about mathematics and needs to read more than they did a century ago. The same will apply for code.
@futurebird @david_chisnall I mean… if AI could do what it promises, why are these companies hiring?
-
I’ve taught programming like this, but I’m an increasingly huge fan of the debugging-first approach that a few people have been trying more recently. In this model, you don’t teach people to write code first, you teach them to fix code first.
I’ve seen a bunch of variations of this. If you have some kind of IDE (Smalltalk is beautiful for this, but other languages usually have the minimum requirements) then you can start with some working code and have them single-step through it and inspect variables to see if the behaviour reflects their intuition. Then you can give them nearly correct code and have them use that tool to fix the issues.
Only once they’re comfortable with that do you have them start writing code.
Otherwise it’s like teaching them to write an essay without first teaching them how to erase and redraft. If you teach people to get stuck before teaching them how to unstick themselves, it’s not surprising that they stop and give up at that point.
@david_chisnall @futurebird it's not exactly the same, but it feels like the same ballpark ... When I started learning to program, the instructor used a pseudo language (based on Pascal, but modified) so there was no compiler available.
We analysed problem code visually before writing our own, but the process was the same - visually follow program flow, and analyze it for errors. -
I’ve taught programming like this, but I’m an increasingly huge fan of the debugging-first approach that a few people have been trying more recently. In this model, you don’t teach people to write code first, you teach them to fix code first.
I’ve seen a bunch of variations of this. If you have some kind of IDE (Smalltalk is beautiful for this, but other languages usually have the minimum requirements) then you can start with some working code and have them single-step through it and inspect variables to see if the behaviour reflects their intuition. Then you can give them nearly correct code and have them use that tool to fix the issues.
Only once they’re comfortable with that do you have them start writing code.
Otherwise it’s like teaching them to write an essay without first teaching them how to erase and redraft. If you teach people to get stuck before teaching them how to unstick themselves, it’s not surprising that they stop and give up at that point.
@david_chisnall @futurebird when I was a teenager I developed my first Doom source port and it was how I truly learned to program in C. Having an existing codebase of good code to work within is a godsend because you are constantly being subconsciously taught what "good code" looks like. Plus yes, everything you've said here too: most of the work involved in programming is about changing code and not just writing it. Learning to debug, read code and reason about it are all essential
-
@futurebird @david_chisnall I mean… if AI could do what it promises, why are these companies hiring?
@mhoye @futurebird @david_chisnall It is always the same: Six months from now, the models will obsolete the humans they're hiring now.
I don't know* why I keep freaking out and getting terrified and depressed now, 36 months into "programmers will be gone in 6 months".
*) I suppose I do know; it's because I have an anxiety disorder.
-
Wanted: Advice from CS teachers
When teaching a group of students new to coding I've noticed that my students who are normally very good about not calling out during class will shout "it's not working!" the moment their code hits an error and fails to run. They want me to fix it right away. This makes for too many interruptions since I'm easy to nerd snipe in this way.
I think I need to let them know that fixing errors that keep the code from running is literally what I'm trying to teach.
@futurebird do your students think that writing code is like writing a word document and you are the “auto-correct” typo utility?
️
