Wanted: Advice from CS teachers
-
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."
-
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 just say: reading this makes me aware what a great teacher you are. Your overall approach and your thoughts about finding the bugs are inspirational. Also they demonstrate in themselves how to try and find the error that causes your students to act differently to their standard.
-
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 caveat: Not a teacher!
I'm not sure what level your students are at, what specifically you are teaching them or how much control you have over the course but...
If you've not seen it already you might like to look at https://hedy.org . It's a language designed for teaching that gradually adds syntax as you explore concepts until you reach a subset of syntactically valid Python. The error messages are also very useful, thoughtfully designed and tested in classroom settings.
Excellent talk by the creator here www.youtube.com/watch?v=6ED36HvQSvk
Honorable mention to Elm and Rust for having excellent error messages too!
-
Things to Try:
* look for typos
* look at what the error message indicates.If these don't work consider reverting your last changes to the last working version of your code. Then try making the changes again, but be more careful.
If you can't revert the changes, start removing bits of the code systematically. Remove the things you think might cause the error and run the code again. Isolate the change or code that causes the problem.
You can be a great programmer.
2/2
Also: If you see pages and pages of errors, start by looking at the first error message. Often, that's the cause of all the others. Students sometimes just give up when confronted with a wall of errors.
-
Sometimes when you are teaching you need to stop the lecture, change the plan because there is an error in the worksheet, or the problem is too hard.
What's really annoying me is that some students think that when their code doesn't run this is "a problem with the lesson" I should stop everything until we fix it.
But, my lesson is fine. The student just made a typo.
They are so focused on the code running they aren't listening to the lesson which would teach them WHY it's not running.
@futurebird I guess this was an advantage of punch cards for teachers. We had to take our deck down to the mainframe and put it in the queue to find out if it ran, then figure out why it didn't on our own.
Maybe try having the students debug for themselves instead of begging for handholding.
-
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 The metaphor I use with line numbers in error messages is "I fell down on line 32. I don't know where I tripped, but this is where I fell."
It is a hint, and you can find it from there, but the cause could be before. Students understand that tripping and falling are distinct, causal actions, and that knowing what you tripped on may be unknowable until you go back and look.
-
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 I am just a humble outdoor educator, so my tools are primitive compared to yours, but maybe they would be interesting anyway. I am interested how they compare to yours.
My classroom management methods all tie back to the concept of mutual respect, and I'll write a symbol of an eye, an ear, and a heart on the whiteboard. These represent and remind students "what does respect look like, sound like, and feel like?"
One thing respect sounds like is One Voice. (1 / )
-
@futurebird I am just a humble outdoor educator, so my tools are primitive compared to yours, but maybe they would be interesting anyway. I am interested how they compare to yours.
My classroom management methods all tie back to the concept of mutual respect, and I'll write a symbol of an eye, an ear, and a heart on the whiteboard. These represent and remind students "what does respect look like, sound like, and feel like?"
One thing respect sounds like is One Voice. (1 / )
@futurebird When we're doing something together as a group, the group has one voice. Sometimes it's my voice if I'm giving instructions. Sometimes it is your voice if you're sharing. It feels good when you have the respect of the group. We are not in One Voice all the time, but when we are, itis respectful and helpful to wait until the person before you is finished talking.
One group development game I play to reinforce this is called Buried Treasure. (It probably goes by many names). (2 /)
-
My students aren't lazy, but they *can* be a little perfectionist: scared to take risks or sit with not having the answer right away.
They are really upset when their code won't run... but staying calm and *systematically* looking for the cause of the problem, knowing that if you just work through the tree of possible causes you will find it is not something they are good at.
I think I need to teach this.
Maybe I will give them some broken code and we will find the errors together.
@futurebird This is a great idea. As a software engineer I would love to see debugging being actively taught as a skill. There are plenty of professionals who are lacking in that area.
-
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.
@MCDuncanLab @futurebird I also found exercises fixing someone else's code to be much less frustrating than fixing my own, and revelatory as to how something done apparently-right can work very wrong. I needed lots of practice with this before I could approach errors with a cool head.
-
@futurebird When we're doing something together as a group, the group has one voice. Sometimes it's my voice if I'm giving instructions. Sometimes it is your voice if you're sharing. It feels good when you have the respect of the group. We are not in One Voice all the time, but when we are, itis respectful and helpful to wait until the person before you is finished talking.
One group development game I play to reinforce this is called Buried Treasure. (It probably goes by many names). (2 /)
@futurebird One way I might play is have all the kids stand on a line they can't get off of. One volunteer can move freely, blindfolded, and has to listen to the group to find the treasure (usually a pool noodle on the ground).
During the game/debrief they'll almost always figure out that talking over each other doesn't work, and come up with a way to have one voice (often electing a leader).
This does not address the CS aspect of your challenge, but I hope it was helpful / interesting. (3/3)
-
@itgrrl also self taught, from what I can see this is rarely in courses - can ask some recent grads this week. @futurebird
@voltagex @itgrrl @futurebird Definitely not a standard part of academic courses. Software Carpentry workshops include it, in part by live coding the demos so the participants both see the instructor making mistakes *and* their process for resolving them. Teaching the trial & error loop also comes up most years at the PyCon AU Education Seminar (since it is far from being a solved 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 My employer at the ISP I worked for in the 90s used to say that, "Working with computers requires a huge ego. The computer is always telling you that YOU ARE WRONG."
The thing you're trying to teach is harder because it's two things at the same time: Learning how the language parser reports errors. The student learning to debug how they think.
I've been coding for years. Parser errors are hard enough and are often obscure in some languages.
-
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 @Pollinators to nerd snipe. Yet another concept has entered the fediverse
-
@futurebird @wakame The metaphor I use with line numbers in error messages is "I fell down on line 32. I don't know where I tripped, but this is where I fell."
It is a hint, and you can find it from there, but the cause could be before. Students understand that tripping and falling are distinct, causal actions, and that knowing what you tripped on may be unknowable until you go back and look.
This a brilliant 'trick' for understanding what actually may have happened.
-
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/
"The error message *tries* to help you": the error message was written by people who had no interest in helping you
-
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.
@futurebird @Zwifi how are you currently teaching that debugging is a skill and part of what they're learning? Do they take notes on, or see presentations of, how bugs (including typos) were identified and fixed? Maybe even presenting to each other the problems they each got stuck on, or debugging as a class on occasion so they can see the process in real time while they're not currently panicking?
-
Argh, this sounds very familiar, I've been trying to teach *from the very start* that encountering errors is useful - they're opportunities to learn, and to think / design in successively more detailed levels of abstraction - working "outside in" - calling methods which don't exist yet to sketch out the general shape of a procedure, watching it fail, then defining them... (1/2)
... This worked very well for a while, until I got a cohort who were already *deep* into LLMs who would encounter the errors, not wait for the rest of the class to catch up, paste the message into ChatGPT, and set out on confusing, frequently completely wrong paths that it was difficult to bring them back from
(2/2)
