Wanted: Advice from CS teachers

[lappenjammerdiezweite@social.vivaldi.net]

@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.

[az@post.lurk.org]

@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!

[catselbow@fosstodon.org]

@futurebird

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.

[jhavok@mstdn.party]

@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.

[willyyam@mastodon.social]

@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.

[semitones@tiny.tilde.website]

@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 / )

[semitones@tiny.tilde.website]

@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 /)

[press_rouch@mastodon.green]

@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.

[iris@neuromatch.social]

@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.

[semitones@tiny.tilde.website]

@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)

[ancoghlan@mastodon.social]

@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)

[jhaas@a2mi.social]

@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.

[hanscees@ieji.de]

@futurebird @Pollinators to nerd snipe. Yet another concept has entered the fediverse

[bytebro@mastodonapp.uk]

@willyyam

This a brilliant 'trick' for understanding what actually may have happened.

@futurebird @wakame

[richpuchalsky@mastodon.social]

@futurebird

"The error message *tries* to help you": the error message was written by people who had no interest in helping you

[iris@neuromatch.social]

@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?

[mistertim@assemblag.es]

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)

[mistertim@assemblag.es]

... 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)

[jonquass@techhub.social]

@futurebird
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

[sandorspruit@mastodon.nl]

@futurebird I have done some classes, explicitly saying I had not prepared anything, completed the exercises improvising there and then, made some mistakes of my own and corrected them. Showing that correcting yourself is part of the game.