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.
This entry was edited (2 weeks ago)
myrmepropagandist
in reply to myrmepropagandist • • •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
myrmepropagandist reshared this.
myrmepropagandist
in reply to myrmepropagandist • • •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?
Thatโs a moray
in reply to myrmepropagandist • • •myrmepropagandist
in reply to myrmepropagandist • • •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.
myrmepropagandist reshared this.
Flic
in reply to myrmepropagandist • • •myrmepropagandist
in reply to myrmepropagandist • • •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/
myrmepropagandist reshared this.
myrmepropagandist
in reply to myrmepropagandist • • •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
Linus Gasser
in reply to myrmepropagandist • • •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, github.com/ineiti/livequiz, or other interactions.
For the exercise sections, the "me" parts are of course much shorter.
GitHub - ineiti/livequiz: Have your students fill out a quiz and discuss the results live.
GitHubmyrmepropagandist
in reply to Linus Gasser • • •@ligasser
"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"
Linus Gasser
in reply to myrmepropagandist • • •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...
hoertauf
in reply to myrmepropagandist • • •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:
๐ฐ wizardzines.com/zines/debugginโฆ
๐ผ๏ธ store.wizardzines.com/productsโฆ
Debugging Manifesto Poster
Wizard ZinesBryan Wright
in reply to myrmepropagandist • • •The Human Capybara
in reply to myrmepropagandist • • •Just an idea but what about "switching" students around so they have to check someone else's code?
I used to do that with my students, asking them to grade each other papers.
It's always easier to see others' mistakes and it flatters their ego... I mean, self-confidence.
Also it's a sneaky way to make them realize that teaching is NOT easy.๐
Amy Worrall
in reply to myrmepropagandist • • •Rosy Maths
in reply to myrmepropagandist • • •Also, I've noticed that learner programmers very rarely read the error messages with any level of attention.
Ooh, you could do a reverse challenge.... provide them with the error message and have them write the code that produces it!
Roger BW ๐ท
in reply to myrmepropagandist • • •Rpsu (326 ppm)
in reply to myrmepropagandist • • •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).
Mans R
in reply to myrmepropagandist • • •> The error will make sense.
Have you heard of this thing called C++?
myrmepropagandist
in reply to Mans R • • •@mansr
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"
Mans R
in reply to myrmepropagandist • • •Cavyherd
in reply to myrmepropagandist • • •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....
MCDuncanLab
in reply to myrmepropagandist • • •James Gilbert
in reply to myrmepropagandist • • •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.)
Rich Puchalsky โฉโ
in reply to myrmepropagandist • • •Jon Quass
in reply to myrmepropagandist • • •I've been a professional software engineer for over a decade now. I still make errors.
What's interesting is that at a certain level it's possible to write code that in isolation works exactly as you want it to, but it doesn't work in combination with the rest of the existing code.
But I also have tools to help me. My IDE checks for typos or syntax errors for me and flags them. It suggests solutions and offers to apply them. I have build tools written by other engineers to catch problems I might not have ever thought about.
No one person knows everything, but anyone can learn enough to be effective
Asilata Bapat
in reply to myrmepropagandist • • •Rosy Maths
in reply to myrmepropagandist • • •Abram Kedge๐ด๓ ง๓ ข๓ ณ๓ ฃ๓ ด๓ ฟ๐จ๐ฆ
in reply to myrmepropagandist • • •> Maybe I will give them some broken code and we will find the errors together.
I think this is an excellent idea!
itgrrl is looking to #GetFediHired!
in reply to myrmepropagandist • • •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 ๐)
Adam โฟ
in reply to myrmepropagandist • • •this sounds fantastic - very keen to hear how it goes. I often find myself and others not able to break down an error message or missing a key part that's right in front of me.
Some languages, frameworks and IDEs make it easier than others.
Thatโs a moray
in reply to myrmepropagandist • • •Press Rouch
in reply to myrmepropagandist • • •Deborah Preuss, pcc ๐จ๐ฆ
in reply to myrmepropagandist • • •Emily Beasley
in reply to myrmepropagandist • • •I taught an Intro to R for Biologists course a few years ago and my students had the same problem... and the solution was exactly this, giving students a list of the most common errors for reference & fixing some broken code together.
More than anything it helped my students' confidence- I think a lot of them just needed a place to start. After a week or two they weren't even using the list I gave them and fixed errors on their own
Ashwin Dixit
in reply to myrmepropagandist • • •When they reach more advanced levels, you will have to teach them to step even farther back, look outside the frame of the monitor, and account for a different layer of the stack.
What if your code works, so well in fact, that it threatens the empires of incumbent elites? What if they break down your door, unperson you, arrest you illegally dozens of times, jail you, brutalize you, deny you legal and medical care, and leave you in pain?
1/n
A Flock of Beagles
in reply to myrmepropagandist • • •vepล jako pepล
in reply to myrmepropagandist • • •Thibaut
in reply to myrmepropagandist • • •Yes, I started to teach how to fix broken code in some classes: read and understand errors, where to look, etc. These are skills they really need but we let them figure them out by themselves. By teaching them how a code can be broken and how to fix it they figure out what is correct code.
It's much better this way than the other way around IMHO.
And yes they are scared to do mistakes, it's even worse in electronics classes!
Je ne suis pas goth
in reply to myrmepropagandist • • •Rosy Maths
in reply to myrmepropagandist • • •Maybe some direct instruction troubleshooting lessons?
Distribute code broken in specific ways and show them how to tell which problem is showing up?
The calling out is definitely contageous, I recognise that. Can you structure in class troubleshooting time as you go - perhaps each kid has a visual token so you can see at a glance who needs help and who can give it? Something like a card with different colours front and back for ๐/๐?
Not a Spring Onion
in reply to myrmepropagandist • • •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".
myrmepropagandist
in reply to Not a Spring Onion • • •@wakame
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.
myrmepropagandist reshared this.
cuan_knaggs
in reply to myrmepropagandist • • •Pete Alex Harris๐ฆก๐ธ๏ธ๐ฒ/โ๐ชโซ
in reply to myrmepropagandist • • •@wakame
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.
myrmepropagandist
in reply to Pete Alex Harris๐ฆก๐ธ๏ธ๐ฒ/โ๐ชโซ • • •"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.
Nerb
in reply to myrmepropagandist • • •And sometimes its not even the code but instead something inside the device.
Recently decided to add a feature to a device I made for myself that added WiFi functionality to it. First thing noticed when the device started was it rebooting every 3 seconds
Since it had been fine before this my mind said dumbo you did something wrong. Spend time carefully going through the code and not finding any problem. Looked online and did not see complaints similar to what I was experiencing It was when I gave in and used someone else's library that the problem was found.
All I did was initialize the library and poof the every 3 second reboot started again. Was sure I had a bad device but went through the Github issues and found someone with the same complaint. Turns out the device works fine minus WiFi with 5v external power but needs 6v with WiFi. The WiFi bootup pulls the voltage down and the internal watchdog sees the low power and reboots. Ugg.
LibreFaso
in reply to myrmepropagandist • • •There's a famous anecdote about Yachar Kemal, the uber-famous turkish author : one day when he was visiting the countryside, a shepherdยน asked what was all the ruckus.
Another villager answered "you don't know ? the guy who wrote 'Memed, my hawk' is here, he's visiting !".
And the shepherd was completely puzzled :"but... nobody wrote 'Memed, my hawk' ?"
(in the sense of "it exists, it hasn't been created, and especially not by a mere human").
ยนIIRC
William Witteman
in reply to myrmepropagandist • • •@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.
Jeffy ๐ณ๏ธโโง๏ธ๐ณ๏ธโ๐๐บ๐ฆ โค๏ธ๐ฑ๐บ
in reply to myrmepropagandist • • •i think Microsoft in the 90s set up this attitude towards computers that still lives today: โitโs your fault if it doesnโt workโ.
I never had to use Windows โ ever โ and every time I would sit down to try, something glaringly bad would be right there interfering.
And Iโve been a dev and UX person for nearly 40 years.
Not a Spring Onion
in reply to myrmepropagandist • • •I totally cried when I was 14 and I tought in my naivety that I knew almost everything and then a simple program failed.
[Edit: And seriously: I think it is hard to understand if the voice from god tells your that there is an error line 32, that this could be somehow wrong.
I mean, this is a computer, right? It doesn't make mistakes.
Maybe emphasizing that the IDE and the compiler and everything else was written by humans and that they discover bugs in those programs all the time could help.]
David Smith
in reply to Not a Spring Onion • • •@wakame can confirm, I work on the standard library for a major programming language and my working assumption is โyou can tell Iโm writing a bug because my hands are movingโ.
Which is why we have tens of thousands of tests and multiple code reviewers and elaborate compiler checking and teams of people dedicated to making sure everyone elseโs code that uses my code still works and everyone โdogfoodsโ the changes and and andโฆ stuff still slips through every once in a while.
Not a Spring Onion
in reply to David Smith • • •"If debugging is the process of removing bugs, then programming must be the process of putting them in." - Dijkstra
Andrew Pontious
in reply to Not a Spring Onion • • •myrmepropagandist
in reply to Andrew Pontious • • •@apontious @wakame @Catfish_Man
๐ ๐ ๐
cake-duke
in reply to myrmepropagandist • • •> 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".
Javier
in reply to myrmepropagandist • • •when I bumped on that problem with my students, I made a lesson focused on:
* provoking error messages
* reading them, learning where in stacktraces is the info about them
* correcting the error
and categorizing them systematically: oh, NameError: this means I'm using a var that does not exist, maybe this is a typo here, or a typo there when I defined it.
It helped them not panic when seeing errors and gave them tools to fix common ones on their own.
Avner
in reply to myrmepropagandist • • •Wesley Cook โก๐ฒ
in reply to myrmepropagandist • • •James ๐ฆ #FBPE ๐ช๐บ
in reply to myrmepropagandist • • •myrmepropagandist
in reply to James ๐ฆ #FBPE ๐ช๐บ • • •@freequaybuoy
"I have the exact same thing as you but it's not working"
99 times out of 100 no, no you do not have the "exact same thing" you've made a typo.
Because the whole point of it being a computer is that if you have the exact same code it always does the exact same things.
Semitones
in reply to myrmepropagandist • • •Adam โฟ
in reply to myrmepropagandist • • •apologies for replying to so many parts of this but one thing I can think of (noting I am not a trained teacher)
Are there any particular high performers or people who are normally finished before others in your class?
Can you enlist them to help out? I get this may go against wanting them to wait but it may stop or slow the barrage, or even encourage problem solving in the group.
I am definitely looking forward to hearing how it all goes. Best of luck - it's kind of endearing to hear students haven't changed that much since I was one.
myrmepropagandist
in reply to myrmepropagandist • • •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.
myrmepropagandist reshared this.
Je ne suis pas goth
in reply to myrmepropagandist • • •myrmepropagandist
in reply to myrmepropagandist • • •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!"
myrmepropagandist reshared this.
LappenjammerDieZweite
in reply to myrmepropagandist • • •Semitones
in reply to myrmepropagandist • • •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 / )
Francis Cook
in reply to myrmepropagandist • • •myrmepropagandist
in reply to Francis Cook • • •@dianshuo
It's always been a thing though I do think it's been getting a little better.
Scott Murray
in reply to myrmepropagandist • • •Wow! A touchy bunch.
You already have a ton of replies here AND know what youโre doing so you donโt need me (random internet person but former professor with lots of experience teaching anxious undergrads coding) to chime in.
FWIW when teaching I tried to normalize โerrorsโ even by referring to them as โmessagesโ because calling it an error feels like โoh I already did something wrongโ. But โerrorsโ only happen because computers are truly not very smart; an error is when it canโt understand our instructions, what we are telling it to do. The human canโt make an โerrorโ; only the computer does. Anyway Iโd also shorten the cycle between coding and compiling - having students re-compile/run the program after every tiny little change shortens the feedback loop, normalizes โerrorsโ (like exposure therapy), and makes troubleshooting easier.
Again you donโt need my input at all โ thanks for the flashback to my teaching days! ๐
Best of luck with this group! โค๏ธ
jz.tusk
in reply to myrmepropagandist • • •This might be a bit too far (my teaching has been of older kids), but what if instead teaching them "coding" or "programming", you teach them "debugging"?
I mean start referring to that class exclusively as "debugging". "Okay class, it's time for debugging. Open your....". That way if they write something that doesn't work it's not a mistake - they've produced something that's important for the next step, which is understanding error messages, locating the place in the code ....
A Flock of Beagles
in reply to myrmepropagandist • • •Quinn Norton
in reply to myrmepropagandist • • •grob (teeth era) ๐บ๐ฆ๐ณ๏ธโ๐๐ณ๏ธโโง๏ธ
in reply to myrmepropagandist • • •Sensitive content
Jimmy
in reply to myrmepropagandist • • •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.
vga256
in reply to myrmepropagandist • • •when i was teaching undergrads with lecture sizes of 200-400 students, they were unbelievably effective at writing everything i said down and understanding 1% of it
it wasn't until my third year teaching that i realized they hadn't learned how to learn yet. teaching them how to learn became my job.
i don't know if i succeeded in doing that, but it fundamentally changed my understanding of what education is. it's not teaching coding or philosophy or history - it's teaching how to listen.
Miguel Guhlin
in reply to myrmepropagandist • • •Paco (2026: New) Hope
in reply to myrmepropagandist • • •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.
myrmepropagandist
in reply to Paco (2026: New) Hope • • •@paco
My students are too hard working and sensitive to deserve such things.
But.
Well, I have met other people in my life.
Paco (2026: New) Hope
in reply to myrmepropagandist • • •Ken Milmore
in reply to myrmepropagandist • • •myrmepropagandist
in reply to Ken Milmore • • •@kbm0
Well perhaps they have nostalgia for those responsibility-free middle school days.
MC Folschette
in reply to myrmepropagandist • • •Doug Wade
in reply to myrmepropagandist • • •David Chisnall (*Now with 50% more sarcasm!*)
in reply to myrmepropagandist • • •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.
myrmepropagandist
in reply to David Chisnall (*Now with 50% more sarcasm!*) • • •@david_chisnall
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.
myrmepropagandist reshared this.
mhoye
in reply to myrmepropagandist • • •Dawn Ahukanna
in reply to myrmepropagandist • • •@david_chisnall
Yes! AI-LLM is a โword calculator for grammatically correct responsesโ. No intelligence present
Intelligence = ability to acquire and apply knowledge and skills.
Ray McCarthy
in reply to myrmepropagandist • • •@david_chisnall
Except only Marketing believes that LLM / Generative AI can write code or write essays.
It's either plausible junk or plagiarism.
Eric Lawton
in reply to myrmepropagandist • • •Now I'm curious about whether LLMs' code compiles and executes error-free on their first attempt.
(Aside from the question of whether it meets requirements, as originally intended; always the hard part).
@david_chisnall
myrmepropagandist
in reply to Eric Lawton • • •@EricLawton @david_chisnall
"Now I'm curious about whether LLMs' code compiles and executes error-free on their first attempt."
At first it did not, but they have added a routine to run it through a compiler until it at least runs without syntax errors and probably produces output that seems like what you asked for for a limited example of input.
This is a bolted on extra check, not some improvement in the base LLM.
But some people are acting like it does represent advances in the LLM.
myrmepropagandist reshared this.
Mx. Eddie R
in reply to myrmepropagandist • • •"I have improved my LLM"
*looks inside*
*improvement is 100% classical handcrafted algorithmic code*
myrmepropagandist reshared this.
Ben Lubar (any pronouns)
in reply to myrmepropagandist • • •//before each linemyrmepropagandist
in reply to Ben Lubar (any pronouns) • • •@ben @david_chisnall
They've added some new feature that will pull up a little virtual machine and it will let you run the code in there. It also seems to test that the code will at least compile first.
I worry that people seem to think that the LLM just... "evolved" these features when clearly a human person had to add them.
myrmepropagandist reshared this.
Mx. Aria Stewart
in reply to myrmepropagandist • • •@EricLawton @david_chisnall @maco Are they though? The only sensible way to evaluate it is as a system โ nobody uses the raw LLM, it's always through layers of API, tokenization, and now models or at least separate "trains of thought" leveraged against each other to refine the output. Using the tooling to conform output is a good hack to keep the systems able to deal with new things by using new tools instead of needing new training.
And it's not exactly an extra check โ it's embedded in a feedback loop.
myrmepropagandist
in reply to Mx. Aria Stewart • • •@aredridel @EricLawton @david_chisnall @maco
I've had so many people say "it knows how to write code now" as if this is somehow ... new and different from generating text. As if there as been some foundational advancement and not just the same tool applied again.
Mx. Aria Stewart
in reply to myrmepropagandist • • •maco
in reply to Mx. Aria Stewart • • •@aredridel @EricLawton @david_chisnall Iโve heard pricing on these is based on โtokens,โ which I understand is in the tokenization/lex/yacc sense. I think thatโs based on the number of tokens output, not input.
When it has to make two or three tries at generating code that actually compiles, does each attempt get charged, or just one?
myrmepropagandist
in reply to maco • • •@maco @aredridel @EricLawton @david_chisnall
I've only ever used free offers including a few I experienced in workshops, so I don't know about the pricing.
myrmepropagandist
in reply to maco • • •@maco @aredridel @EricLawton @david_chisnall
I strongly suspect they are vastly undercharging and counting on building dependency and jacking up the prices later.
The free workshops seem to be all about that and didn't impress me much. But, I did get to play with the tech so I could better understand it which was worth it despite all of the sales pitch infused through the process.
maco
in reply to myrmepropagandist • • •@aredridel @EricLawton @david_chisnall oh yes, I had the impression there was some of that going on. Some of the services did jack their prices up some time a year or two ago; I remember there being sticker shock. I think people expected what was free at first to go to like $20/mo and it actually went much higher.
But I have no details. I havenโt used any of it.
FlyingMana
in reply to myrmepropagandist • • •And thats not yet including the increased energy prices caused by the co2 tax increses now coming.(not that any of the big companies would pay this)
llewelly
in reply to myrmepropagandist • • •there are certain languages (such as C) in which that would be a cruel trick; lots of code which contains subtle undefined behavior bugs that don't show easily will compile without errors, or in many cases, often without warnings as well. Not all undefined behavior is detectable at compile time.
David Chisnall (*Now with 50% more sarcasm!*)
in reply to myrmepropagandist • • •I would make a slightly different point, I think.
When I was at university, doing a degree in computer science, the first language they taught us was Pascal. The second was Prolog. I canโt remember which order the third and fourth were taught in, but they were Java and Haskell.
Of these, Java was the only one widely used in industry. In my subsequent career, I have rarely used any of these. But I have used the concepts I learned repeatedly.
The tools change. Eventually, modern IDEs will catch up with 1980โs Smalltalk in functionality. But the core concepts change far more slowly.
And this matters even more for school children, because theyโre not doing a degree to take them on a path where the majority will end up as programmers, theyโre learning a skill that they can use in any context.
I spent a little bit of time attached to the Swansea History of Computing Collection working to collect oral histories of early computing in Wales. Glamorgan university was the first to offer a vocational programming qualification. They had one day of access to a computer at the Port Talbot steelworks (at the time, the only computer in Wales) each week. Every week, the class would take a minibus to visit the computer. They would each take it in turns to run their program (on punch cards). If it didnโt work, they would try to patch to code (manually punching holes or taping over them) and would get to have another go at the end.
Modern programming isnโt really like that (though it feels like it sometimes). The compile-test cycle has shortened from a week to a few seconds. Debuggers let you inspect the state of running programs in the middle. Things like time-travel debugging let you see an invalid value in memory and then run the program backwards to see where the value was written!
But the concepts of decomposing problems into small steps, and creating solutions by composing small testable building blocks remain the same.
The hard part of programming hasnโt been writing the code since we moved away from machine code in punched tape. Itโs always been working out what the real problem is and expressing it unambiguously.
In many ways, LLMs make this worse. They let you start with an imprecise definition of the problem and will then fill in the gaps based on priors from their training data. In a classroom setting, those priors will likely align with the requirements of the task. The same may be true if youโre writing a CRUD application that is almost the same as 10,000 others with a small tweak that you put in the prompt. But once it has generated the code then you need to understand that itโs correct. LLMs can generate tests, but unless youโre careful they wonโt generate the right tests.
The goal isnโt to produce children who can write code. Itโs to empower the children with the ability to turn a computer into a machine that solves their problems whatever those problems are and to use the kind of systematic thinking in non-computing contexts.
The latter of these is also important. Iโve done workflow consulting where the fact that the company was operating inefficiently would be obvious to anyone with a programming background. It isnโt just mechanical systems that have these bottlenecks.
And this should feed into curriculum design (the Computer Science Unplugged curriculum took this to an extreme and produced some great material). Thereโs no point teaching skills that will be obsolete by the time that the children are adults, except as a solvent for getting useful transferable skills into their systems. A curriculum should be able to identify and explain to students which skills are in which category.
(And, yes, I am still bitter my schools wasted so much time on handwriting, a skill I basically never use as an adult. If I hand write 500 words in a year, itโs unusual, but I type more than that most days)
Simon Brooke
in reply to myrmepropagandist • • •@david_chisnall When I was at school, back in the 1960s, the careers advisors told us "don't learn programming, within four years computers will be intelligent enough to program themselves."
I suspect school careers advisors will still be saying the same thing in the 2060s.
Ethin Probst
in reply to myrmepropagandist • • •fraggle
in reply to David Chisnall (*Now with 50% more sarcasm!*) • • •Anthony
in reply to myrmepropagandist • • •I don't know your class or students, and all of this might be stuff you already do or not relevant at all, but here are some things that popped into my mind from my own experiences, in case it's of any use:
Hopefully something in there is of use. I have references for concept inventories and Parson's puzzles if those would help. Good luck!
myrmepropagandist
in reply to Anthony • • •@abucci
I'm kind of shocked that functions are hard. Are they hard for students who understand functions in the context of mathematics?
Nick
in reply to myrmepropagandist • • •EveryOpsGuy
in reply to myrmepropagandist • • •Dave Ames ๐จ๐ฅ
in reply to myrmepropagandist • • •Eight steps to promote problem solving and resilience and combat learnt helplessness in computing
philbagge.blogspot.comFubaroque
in reply to myrmepropagandist • • •aliengasmask
in reply to myrmepropagandist • • •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?
U.Lancier
in reply to myrmepropagandist • • •rag. Gustavino Bevilacqua
in reply to myrmepropagandist • • •When "teaching Internet" (to adults), to explain algorithms I asked "describe what you do between you boot (wake up) and go to work".
A high % went to work wearing their pajamas, according to their algorithm
It was my way to teach "don't take anything for granted".
Stรฉphane Charette ๐จ๐ฆ
in reply to myrmepropagandist • • •I take it there are no assistants in class?
I have no idea if we're talking young adults, high school, or primary. But in high school in the 1980s for grade 12 CS we had to assist in the grade 9 CS class. When a student would raise their hands, one of us in grade 12 would rush over, leaving the teacher uninterrupted.
myrmepropagandist
in reply to Stรฉphane Charette ๐จ๐ฆ • • •@charette
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.
myrmepropagandist
in reply to Stรฉphane Charette ๐จ๐ฆ • • •@charette
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.
Alan
in reply to myrmepropagandist • • •Zwifi
in reply to myrmepropagandist • • •myrmepropagandist reshared this.
myrmepropagandist
in reply to Zwifi • • •@Zwifi
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.
Iris Young (he/they/she) (PhD)
in reply to myrmepropagandist • • •Zwifi
in reply to myrmepropagandist • • •Pete
in reply to myrmepropagandist • • •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.
az
in reply to myrmepropagandist • • •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 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!
Hedy - Textual programming made easy
hedy.orgJeffrey Haas
in reply to myrmepropagandist • • •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.
Hans-Cees ๐ณ๐ณ๐คข๐ฆ๐๐๐๐๐๐
in reply to myrmepropagandist • • •Tim Cowlishaw
in reply to myrmepropagandist • • •Graham Bingham
in reply to myrmepropagandist • • •What a great set of discussions and thanks for being a teacher! (They pretty much make the world go round, imho.)
I'm not one, but have taught some people coding over the years. Most recently I've seen that LLMs compound the problem you describe, because when the student has posted hundreds of lines of code to answer some fairly standard coding assignment, they have jumped so far into the deep end, that it's very hard for them to get out. The pasted code does all sorts of things they don't yet know about. Hopefully not your situation. Hopefully a lesson in its own right, but getting this young person to slow down and *do it themselves* was non-trivial.
On a different tack, a project manager I knew once said energy project needs a project teddy bear. Any coding issues have to be explained to the bear first before getting senior help. The bear apparently solves 60%+ of the issues. Apocryphal, maybe.
Coolcoder360
in reply to myrmepropagandist • • •not a teacher, so take with a cup of salt, but maybe having them not coding during your speaking parts could help?
Like, locking their screens or all looking at you rather than typing at the machine.
My guess is that anyone calling out like that got distracted with the coding and was not strictly paying attention to what was being said, so when they get the error, they may not see or hear anything aside from the error in front of them.
GhostOnTheHalfShell
in reply to myrmepropagandist • • •Present them or a piece of code and tell them this piece code has a problem with it and ask them to figure it out if you can find a fun thing all the better.
Have them perform a code review and look at code and say well figure out the failure modes of this piece of code.
I would actually have code refuse be part of your class.
That Dinkum Thinkum
in reply to myrmepropagandist • • •I teach physics, but I know what you mean. I usually start by saying that 500 years ago ppl. like Leonardo da Vinci would easily have understood how the (classical) physics of a modern car works, but they would never have believed we could manufacture the parts with such precision. So the class is more about error control than new concepts.
I also remember it being quite a mental leap for me as a student.
Butch Hattrick โง๏ธ
in reply to myrmepropagandist • • •back in 1984, during my first computer class in high school, I can totally recall all of us students being the exact same way. Only difference was, the teacher would say "questions at the end" or ignore people calling out, and just get on with the entire lesson. Seriously.
And when it came to the walking around part, all you got was questions about what you were trying to do, or questions to make you think, you NEVER got the work done for you.
That was actually a fun teacher.
TBYG
in reply to myrmepropagandist • • •lemgandi
in reply to myrmepropagandist • • •An old mentor of mine introduced me to a useful acronym: KMAFYOYO
'Kiss My Ass Fella, You are On Your Own'
It is even phonetic.
Andy in Indy
in reply to myrmepropagandist • • •Maybe give them a homework assignment: Pay close attention to how many times in a day you hear somebody misspeak and correct themself, no matter how small it is. We all do this a lot, but it happens so fast and so often that we rarely notice.
When it happens in a computer program, we call that a bug. But the computer won't have the zillion shared context clues that human language enjoys. It can't work out what you mean by itself. And it has very limited ways to ask for help.
dimsumthinking
in reply to myrmepropagandist • • •TBYG
in reply to myrmepropagandist • • •jmht
in reply to myrmepropagandist • • •myrmepropagandist
in reply to jmht • • •@jmht
Why what?
jmht
in reply to myrmepropagandist • • •"My code isn't working!" "Why?"
I realize that's a flip response to your inquiry, but, ultimately it is what you're looking to enable your students to do, right? They should be able to say more than "it isn't working" which is uninformative. So, it isn't working .. what else can you say about what is - or isn't - happening and what hypothesis can you give as to why? And if you have a hypothesis, how can you test it?
TheFwGuy ๐ช๐บ๐ฎ๐น๐บ๐ธ๐
in reply to myrmepropagandist • • •40+ years experience in SW/FW developing here and the simple truth is that not everybody is cut to program computer.
Is not only matter of knowledge, is matter about how a person think and is curious about the world and things working.
Every single one person who interrupt and ask, will end up using google and AI to write a program.
No personal ideas, no spending hours trying to understand the problem and the nature of errors.
In my career I saw "new" generations of developers knowing less and less. Almost nobody of new generations knows what a computer is and how is working. It seems a useless information but is exactly what make you understand the errors.
Errors exists all along the "chain", from your code to code you are using (compiler/OS/drivers/etc.) up to the electronic.
Maybe the way you and others teach programming should change, making more like a mystery hour ๐ค
felix (grayscale) ๐บ
in reply to myrmepropagandist • • •Cat
in reply to myrmepropagandist • • •Dawn Ahukanna
in reply to myrmepropagandist • • •๐ฒ
in reply to myrmepropagandist • • •Peter Drake
in reply to myrmepropagandist • • •Wouter Lindenhof
in reply to myrmepropagandist • • •Software developer trainer here.
Silly question, but do they read the *entire* error description? And once they solved it do they understand the relationship between the cause, the message, and the fix?
It might be worthwhile to force them to slow down by asking them to write down the entire message on paper.
Try making a game out of it: Who can generate the strangest error message with the fewest amount of โbadโ code.
myrmepropagandist
in reply to Wouter Lindenhof • • •@DevWouter
They are middle school kids totally new to programming so reading the whole thing is a challenge and they will encounter too many words they are still learning.
And really their errors are nearly always typos. Or not putting their function call in main body of the program. Or using a variable they have not defined.
So, for them reading deep isn't that important IMO.
The responses can be very verbose and technical.
Wouter Lindenhof
in reply to myrmepropagandist • • •I like to compare learning to code to learning a foreign language with a native of that language that doesnโt speak my native language. Similar process with similar challenges.
I would recommend starting with collecting the most common errors, simplifying the problem area, and categorizing them. That should help with pattern recognition, give them a vocabulary to describe their issue beyond just โIโm error,โ and provide them with a direction in which to search for a solution.
CubeOfCheese
in reply to myrmepropagandist • • •a couple things I do. (It sounds like you're already doing some of these with slight variation):
1. Tell them I make errors when programming. My former boss who worked for 30 years as a programmer still makes errors.
Errors are not a bad thing. They are part of programming. Part of the process.
Errors are hints. They are clues to figure out how to make the program work.
Edward L Platt
in reply to myrmepropagandist • • •Steven G. Harms
in reply to myrmepropagandist • • •a powerful conceptual tool that I have after working in Boot Camp and in professional training is this: your code has billions of configurations, all of them except one are incorrect.
Therefore youโre going to spend the majority of your time with not working code. When it does work, that is the exception.
Therefore, your goal will be to learn how to gather information and diagnose the nature of the wrongness so that you can get it to the one working state this blunts the Instagram effect.
Dreaming of bogwitchery
in reply to myrmepropagandist • • •Paul_IPv6
in reply to myrmepropagandist • • •Michal Young
in reply to myrmepropagandist • • •Goopadrew
in reply to myrmepropagandist • • •Sam Livingston-Gray
in reply to myrmepropagandist • • •@quixoticgeek if you can put a student's screen on the projector, maybe walk each one in turn through "read the error aloud, ask what it might mean, see which line it's complaining about, read that line aloud," and so on?
Could help reinforce that these problems can be worked through. Also changes the social calculus from "I cast Summon Help From Authority Figure!" That part could go either way, but handled well, it could build camaraderie ("see, we all make mistakes")...
Andrew Stacey (he/him)
in reply to myrmepropagandist • • •I will venture an answer - I haven't read all the replies to your post so I may be saying things that are already said.
I'm a UK-based secondary (aka high school) maths teacher who also teaches CS, including introducing students to programming (usually python).
Here's some thoughts of things to try.
1. Practise finding errors. Give them code with errors and ask them to find them. Set problems to generate particular error messages. eg Can they write code where the mistake is on line 3 but the error message says line 33?
2. Have a list of general prompts that you will say. If the error is on a different line, just say "Take a look at line N" then walk away to the next student. If they've named a variable badly, say "variable names can't have spaces". Make them do some work here.
3. Clearly delimit demonstration time and coding time. "Fingers off keyboards and mice" is a common phrase in my classrooms (and I will stop the entire demo if I hear a clicking).
4. Make them keep notes. I use Google Colab so that they can interweave notes with code snippets (at least in the early days) to encourage this.
5. Partner up. It's often easier to find the error in someone else's code than in your own. Could even have a "walk around time" when all the students go and look at others' screens to both get ideas and see if they can spot errors.
That's what springs to mind on reading your thread. I hope some of it's useful! As with all advice on the internet - keep what helps and ignore what doesn't.
ersatzmaus
in reply to myrmepropagandist • • •I'd respond with a few key questions:
- In what way is it not working?
- Why do you think that is?
- If you can see errors, what do they tell you?
- How can you find out more about what is or is not happening?
And there's the all-important "What are your assumptions, and are they correct?"
Flipper ๐ฌ๐ณ๏ธโ๐
Unknown parent • • •@raganwald
The best, most succinct, explanation of the difference here came from @pluralistic:
Coding makes things run well, software engineering makes things fail well.
All meaningful software fails over time as it interacts with the real world and the real world changes., so handling failure cases well is important.
Handling these cases involves expanding one's context window to take into account a lot of different factors.
For LLMs, a linear increase in the context window results in a quadratic increase in processing. And the unit economics of LLMs sucks already without squaring the costs.
Which is why AI, in its current incarnation, is fundamentally not capable of creating good software.
(I've heavily paraphrased, so apologies if he reads this).
@futurebird @EricLawton @david_chisnall
Morten Hilker-Skaaning
in reply to myrmepropagandist • • •jason
in reply to myrmepropagandist • • •JamesWarlock
in reply to myrmepropagandist • • •G1itchbit
in reply to myrmepropagandist • •I'm not a CS teacher, but I have taught both my kids how to code.
In order to program, you first think both backwards and forwards. For design, you think about what you want, and work backwards from that. For coding, you think about what the present problem needs, and work forwards from that. You imitate the computer in your mind step-by-step to check.
When debugging, it's the same. You think about what happened, and you work backwards from that. What must have been true for that to happen? You can usually find the place where the error must be from that. You might add some code to verify your assumptions. For each piece, you imitate the computer in your mind, forward step-by-step, to find where the divergence is.
LibreFaso likes this.
Giuseppe Aceto
in reply to myrmepropagandist • • •Someone responded well, with a longer updated list, but the goal was to defuse the negative reaction, it kind of worked.
LibreFaso
in reply to myrmepropagandist • • •Not sure that I can qualify as a CS teacher (I only taught a few informal classes, mostly Scratch) but as a user I can relate.
There is some existential dread in having your basic tools not working without warning.
A bit like physicists in the three-body problem start despairing when physics starts to behave in an unpredictable way.
I have this when I work on Arduino and a thingy doesn't work as it should.
1/?