Wanted: Advice from CS teachers
-
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 I think CS students and also everyone else should use the list, but in reverse order.
1). Calm down, you’ll get over it and find a fix in no time. Everyone does.
2) Read the error and read it again. It tells you pretty much where, or sometimes even what exactly is the problem. Fix is right there.
3) The error makes sense, it is not magic. Ever.
4) It is probably a typo, you’ll find it after competing the first 3 points. Go to 1). -
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 Kids don’t know how to fail anymore. How did that happen?
-
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 used to get the same teaching basic electronics. Plenty of schools for getting it wrong. Polarised components wrong way round, resistor and capacitor values wrong, wires in wrong holes, bad soldering, very, very bad soldering. The worst was a student who managed one huge blob of solder on a board bridging all eight pins on a DIL IC (probably a 555). -
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 > The error will make sense.
Have you heard of this thing called C++?
-
@futurebird > The error will make sense.
Have you heard of this thing called C++?
Yeah...
what I'm trying to convey is that there is a *reason* why the code isn't working and it will make sense in the context of the rules the got dang computer is trying to follow.
It might be annoying or silly, but it will "make sense"
-
@futurebird
I know this from people I taught programming.And I think the main problem is that the computer is judging you. In a way.
This can come in two forms:
a) The program fails to run, shows you an error, etc.
b) The IDE adds an error or warning to a line saying: This is wrong.So there is "objective proof" right there on the screen that you "are a failure". This is not some other person saying it, this is a piece of technology.
This is also something I hate from a usability/user experience perspective.
The computer doesn't say: "Sorry, I don't understand what you mean with that line."
It says: "This line can not be processed because the user is dumb."(Not quite, overemphasizing.)
When taking about critique or blame, there is this typical antipattern: "Everybody uses a fork."
No, they don't. I use a fork, I want you to use a fork, but instead of saying that, I invoke a mystical "everybody".
@wakame @futurebird Those errors also have their own language and you have to learn it. You have to be able to interprete stuff like "Error 231 in Line 981: None type is not iterable". Most error messages are not "normal" language you can understand with your normal language skills.
(feeding the error messages into an LLM and asking to explain them really helped me, btw.)
-
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 assigning code broken in specific ways & having a rubric for teaching the troubleshooting sounds like it should be SOP for coding courses, is this not normally part of the curriculum?
(def not dumping on you, asking as an Old who is a self-taught potato coder who never did a CS degree & feels like the way I learned basically anything that I do know was: type it in from a magazine or other source / modify working code that’s similar to what I need -> make mistakes in transcription / tweaks -> code doesn’t run or runs with errors -> troubleshoot the mistakes -> learn stuff
) -
I think this meme captures a point I am trying to make very nicely.
I love this thread and I love this meme.
I'd share this meme with them, and also share that error messages are like Captain Obvious: they might be accurate about showing when a problem exists, but often less helpful when fixing it.
I'd also highlight that bugs are a normal part of programming (and that code can "work"but still be shite).
From a classroom place, would "silent coding" followed by QA work as a structure?
Or is that what's in place when they call out?
-
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
@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.
-
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 in my experience the jump from teaching scratch, where there are no syntax errors, to python is huge.
None of the courses ive taught (not my own) included anything covering how to deal with parser errors and i think its an entire lesson in itself. Not sure any students i had would have the patience to follow that lesson as it would be hard to have the "i made the computer do something" pay off.
Maybe a parser error cheatsheet is the answer?
-
Yeah...
what I'm trying to convey is that there is a *reason* why the code isn't working and it will make sense in the context of the rules the got dang computer is trying to follow.
It might be annoying or silly, but it will "make sense"
@futurebird I know what you mean, and you're perfectly right when it comes to sane programming languages. However, C++ compilers have a habit of spewing out error messages the size of a Tolstoy novel in response to mistakes as trivial as a missing comma. Now I assume you're not teaching the kids C++ as that would be quite irresponsible.
-
@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 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"
This is how I normally teach (although with middle school students I keep "me" bits to under 8 min each) this is why it's so annoying when they call out during these sections. Something they wouldn't ever do normally.
Something about coding and seeing the error makes them not see it as "time to listen"
-
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'm not a teacher but I have given interns and others learning projects. Like "here is some code that should do <the thing> but it doesn't work. find why it's not doing <the thing>". I also used to come into the room and ask "what's broken?" making the framing, there's always something not working and we're here to find out way. and always starting my help with "what have you tried"
-
R ActivityRelay shared this topic
-
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 an excellent exercise and most of your students will get a lot out of it. Be prepared though for the 3-6 who simply will not believe you. Especially if they've used ChatGPT. My CS friend has students who don't believe him when the thing in front of them differs from ChatGPT just like my language students will not accept that the machine translation is not correct/common usage.
-
@futurebird @wakame I'm not a teacher but I have given interns and others learning projects. Like "here is some code that should do <the thing> but it doesn't work. find why it's not doing <the thing>". I also used to come into the room and ask "what's broken?" making the framing, there's always something not working and we're here to find out way. and always starting my help with "what have you tried"
That is something I should definitely try sometime.
When the broken code comes from another person, it is more "improving something" and less "getting your work dissected".
-
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/
It's probably a missing or extra comma, quote, or paren.
"looking for it in a calm, systematic way" after the requisite freak-out & meltdown....
-
[Remark: I am not a teacher, but I taught/coached some people 1-on-1.]
Working with a computer is not like working with a human.
A computer can't be "wrong". Not in a human sense. It's just a machine.
So if your program works, then reality and physics and so on validate your work.
You have made your will manifest outside of your head, independent of judgement or opinion of others.
Part of you has become immortal.If it doesn't work, then there is nobody to console you, nobody you can blame for not understanding you.
What you did is objectively wrong.I think the second thing deals a rather unique blow to your psyche.
You can't blame your building materials, or other people, or anything else. The blame is yours and yours alone.Of course you can "correct" your mistake, fix your bugs and so on.
But I still think this is a large piece of humble pie you have to digest first.This comment is spot on I think. I’ve seen this with little kids and devices like iPads. When the iPad doesn’t do what they want, they will get mad and say “it’s not doing what I want” to which I have to reply “it’s doing exactly what you told it to do”.
Also, I think for most people computers are a “black box”, so when it errors students may assume they don’t have the skills to fix it.
-
"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"
This is how I normally teach (although with middle school students I keep "me" bits to under 8 min each) this is why it's so annoying when they call out during these sections. Something they wouldn't ever do normally.
Something about coding and seeing the error makes them not see it as "time to listen"
@futurebird I'm also interested how to add LLMs to the mix: how to use them in a way we use IDEs now: we still know how to program/read code, but IDEs are so useful.
This will add another level to the me/them, where sometimes I'd want them to use LLMs, other times not.
But first I need to convince the school it's a good approach: I'm an external teacher, and as such have very little influence...
-
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 give them code that is flawed and without/withbad commentary to fix from the beginning. Also to teach them that this is the default state of *any* code they will encounter in real life.
-
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
@futurebird You probably already know @b0rk‘s Pocked Guide to Debugging. The thing I love so much about it is how she cherishes the bug, instead of squashing it (in the illustrations too). I love this attitude. Not sure if students can learn to think that way? There is a beautiful poster too:
https://wizardzines.com/zines/debugging-guide/
️ https://store.wizardzines.com/products/poster-debugging-manifesto
