Wanted: Advice from CS teachers
-
@itgrrl also self taught, from what I can see this is rarely in courses - can ask some recent grads this week. @futurebird
At the university we had this maybe once.
But then, to quote a professor: "You are learning 'computer science' here. 'Programming' is something that you should either already know or learn in your free time."
-
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. #CSEdu
@futurebird Maybe follow a writing workshop approach. 10 minute mini lesson, students work on applying coding concept, you conference with them individually after checking on what they are doing, group share at the end where they show their code and what they have done while others make a positive remark or suggestion. End each week or whatever time range with a culminating project that shows their knowledge of three core ideas taught. A suggestion from a writing teacher…may not work.
-
> I think they become anxious when their code isn't working the same as what I have up on the projector and they want to get it fixed RIGHT AWAY so they won't fall behind.
Isn't this the whole problem? Maybe they intuit from you that the class is "keep up with the projector", when in reality the valuable skill is "if you're lost or confused, come up with hypothesis and critically explore them by yourself until you figure out what's going on".
@futurebird It's hard to sit back and think when you're under the pressure of "do it fast or you'll fall behind". Maybe decouple the two: projector classes shouldn't be done in front of the computer. Projector classes are for you to show something, and interacting with the computer are for the students to explore, and you can't do both at the same time.
-
These are middle school kids. I don't think they need someone to rush over and help them. I want them to think about "my code won't run" in a different way.
-
Like if someone offered me an assistant I'd say "that's OK." the class size is reasonable 12-18 students. I just need to help them understand errors better.
-
This is helpful for me. I had a hard time understanding why one student was upset, almost to the point of tears (they are very sensitive) that the error message said "error on line 32" but, really the problem was the way they originally named the variable.
"Why couldn't it just say the error was on line 4?
I tried everything I could to fix line 32. 🥺 "My sweet child... it's just not that smart, not like you.
The thing I keep saying is: an error message is not a person telling you what specifically went wrong this time. It's a string somebody writing the program months or years ago thought would describe what they *guessed* back then might cause the code to reach that state unexpectedly.
1. Code can always be wrong, sometimes in ways the programmer hadn't thought of (in fact often since they probably handled the ways they'd thought of) and,
2. Error handling code is code. -
I think they become anxious when their code isn't working the same as what I have up on the projector and they want to get it fixed RIGHT AWAY so they won't fall behind.
Then when one of them starts calling out they all do it.
I may take some time to explain this.
This never happens when I'm teaching math. Something about coding makes them forget some of their manners, and become less self-sufficient. "It's broke! I'm helpless!"
What is that about?
@futurebird When the computer doesn't do the thing when it's supposed to it can be like "why isn't the machine doing what I say?", they're not the source of the issue but the computer can be. When you're the computer, you only have yourself to fix the problem.
-
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 Maybe a change of emphasis focussing on "getting it working" as the task, while entering the code becomes a more mechanical step that just has to be done?
-
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. #CSEdu
@futurebird I’m pivoting off this just to share a funny story. An old CS prof shared this with me when I was staff in a CS department at a university.
One of his undergrads had come to him with a big printed listing of their code (back when that was how you did that! It was probably FORTRAN printed on fan-fold paper). They obviously wanted him to find the problem in their code. It became clear quickly that they hadn’t done anything to debug it themselves.
He started point at various places in the listing. “Right here, add PRINT ‘I am a dumbass’. And here: PRINT ‘I am a dumbass’” and so on. “Then run it and see how many dumbasses you get.”
Now, did he really do that? Is that just how he tells the story? Who knows. But it’s funny. And anyone who has ever written code will agree that this works sometimes.
-
The thing I keep saying is: an error message is not a person telling you what specifically went wrong this time. It's a string somebody writing the program months or years ago thought would describe what they *guessed* back then might cause the code to reach that state unexpectedly.
1. Code can always be wrong, sometimes in ways the programmer hadn't thought of (in fact often since they probably handled the ways they'd thought of) and,
2. Error handling code is code."Error handling code is code."
It had not occurred to me that a student might not see it that way "some guy wrote code to try to tell you what went wrong" but I can see how this might not be how a student might see the errors.
It's like when I realized as a kid that all books are just ... written by people. A revelation. I think I thought, on some level, books were a natural product of the universe. When I realized they could have typos, bad ideas it was so exciting.
-
@futurebird I’m pivoting off this just to share a funny story. An old CS prof shared this with me when I was staff in a CS department at a university.
One of his undergrads had come to him with a big printed listing of their code (back when that was how you did that! It was probably FORTRAN printed on fan-fold paper). They obviously wanted him to find the problem in their code. It became clear quickly that they hadn’t done anything to debug it themselves.
He started point at various places in the listing. “Right here, add PRINT ‘I am a dumbass’. And here: PRINT ‘I am a dumbass’” and so on. “Then run it and see how many dumbasses you get.”
Now, did he really do that? Is that just how he tells the story? Who knows. But it’s funny. And anyone who has ever written code will agree that this works sometimes.
My students are too hard working and sensitive to deserve such things.
But.
Well, I have met other people in my life.
-
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 a teacher of mine had a nice trick for this, that I reused when teaching: he would reply "I won't help you until you have drawings of what the code should do, and comments everywhere". Having the students make diagrams (if they didn't start there) helped them find architectural issues in the code logic, and writing comments had them be their own rubber ducks, and forced them to re-read things. In a lot of cases, they figured the issue out before being ready to call ^^.
-
@futurebird a teacher of mine had a nice trick for this, that I reused when teaching: he would reply "I won't help you until you have drawings of what the code should do, and comments everywhere". Having the students make diagrams (if they didn't start there) helped them find architectural issues in the code logic, and writing comments had them be their own rubber ducks, and forced them to re-read things. In a lot of cases, they figured the issue out before being ready to call ^^.
I do this with my older students and with those with more experience. This is the one course that I teach that EVERYONE must take. So there are kids there who have never programmed anything. Kids who were confused when I had them use a computer with a mouse since they'd never seen one in person before.
I'm glad we have such a course. But they just don't know enough to do this yet.
And I have an agenda: I want them to have fun.
-
This is helpful for me. I had a hard time understanding why one student was upset, almost to the point of tears (they are very sensitive) that the error message said "error on line 32" but, really the problem was the way they originally named the variable.
"Why couldn't it just say the error was on line 4?
I tried everything I could to fix line 32. 🥺 "My sweet child... it's just not that smart, not like you.
@futurebird @wakame I am in my 40s and I still, occasionally, spend hours trying to fix line 32.
-
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/
Thanks this is really helpful. We teach a graduate class on quantitative cell biology based in python. Many ppl don’t have prior coding experience, we probably need a section like this.
-
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 my student tutor had an annoying habit of answering questions like that with "try doing it right instead of wrong", which was pretty obviously just a way to not get flooded with this exact type of comment.
On the one hand, it's smarmy and unhelpful. On the other hand, sometimes it's useful to tell someone to sit down and not panic in your face so you can continue doing your thing (for their benefit)
-
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 what I would have suggested. Introduce the compiler, explain that you will encounter errors, but the error messages are designed to be as helpful as they can be.
(If you're using Python, error messages have been worked on over the last few major releases, with teaching particularly in mind, so it's worth using the most recent.)
-
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.
Test Driven Development can help, although there are skills needed, and you can have errors in your tests!
But the skills needed to write/troubleshoot a good test are more focused/limited than being able to code
Tests also encourage you to write testable code, which is usually modular/functional, and broken code elsewhere is less likely to affect it.
Monolithic code is hard to test/debug.
-
My students are too hard working and sensitive to deserve such things.
But.
Well, I have met other people in my life.
@futurebird Of course. I wouldn’t ever say that to someone trying to learn. But you could tell them the story about the grumpy professor who was a jerk, and they can laugh while learning what printf() debugging is.
-
"Error handling code is code."
It had not occurred to me that a student might not see it that way "some guy wrote code to try to tell you what went wrong" but I can see how this might not be how a student might see the errors.
It's like when I realized as a kid that all books are just ... written by people. A revelation. I think I thought, on some level, books were a natural product of the universe. When I realized they could have typos, bad ideas it was so exciting.
Same with the "average end user":
Your text processor or spreadsheet program also never says "This is the developer writing: I have no idea what you just did, but I didn't expect this."Only "Error 0x8002f0f0: Good luck trying to find out what that means."
