@ShaulaEvans okay, here are some fun/gross/terrifying bug facts about polycheate worms (which live in the ocean):

1. The Bobbitt Worm is a marine ambush predator that burrows in ocean sediment and then shoots out to grab prey with its mandibles, the force of which sometimes cuts prey in half. It grows up to 3 meters long in extreme cases, although it's only about 25 millimeters in diameter. At least one article I read mentioned toxic bristles, but I wasn't able to find a legitimate source for that and suspect it was sensationalization.

2. The Bearded Fireworm does have toxic bristles (as do other fireworms). They can cause a painful sting that lasts for hours. They're also quite beautiful.

3. The Palolo Worm spawns by growing tail segments filled with sperm or eggs, and then on a specific night tied to the lunar & solar cycles, releasing these segments to float to the surface, where they disintegrate into a frothy mass. They're apparently delicious fried in coconut oil.

In case you want to do your own deep dive () on segmented ocean worms: https://en.wikipedia.org/wiki/Polychaete

@futurebird with optimism I can find simpler practice problems for low-level concepts like "write a Boolean expression with two operands that evaluates to True" or "write an assignment statement that combines the result from two function calls" and the checker can enforce those things. I think this kind of low-level practice is sometimes missing because it can't be tested by traditional value-based unit tests.

There's a chicken-and-the-egg problem with debugging: if students don't debug, they'll never learn how to really use/understand a topic. But if they don't understand it, debugging is nearly impossible and the chances of making things worse instead of better are high. Debugging seems easy once you've mastered the relevant concepts, but before that error messages often use unintelligible jargon and add with the "root cause is on another line" problem they can be hard to act on.

About a third of the way through my course, we start to emphasize adding prints to see what wrong with your code. My stock answer to every request for help becomes "Did you add a print to learn more? What did it tell you?" I'd bet if you can get students to do that first because you know that's how you'll respond it would help. A quick "okay add a print and I'll look at your code once In done talking" as a blanket response might work?

@futurebird I tell my students that debugging is 50+% of the work, *even* for me with 10+ years of experience. Then I tell them that what makes me a good programmer is not my ability to write error-free code the first time, but my ability to quickly debug code based on oodles of experience.

You could try intentionally making a few common mistakes and showing off the error messages that result if you're projecting an IDE instead of just writing on the whiteboard.

I've also built a Python library called "optimism" that can do "did you use X construct" or even "X inside Y" which helps write certain kinds of practice problems for beginners. It can generate an error message for "you're not using an if statement inside a loop but the problem requires that" for example. Reading other responses here I'm reminded that I should probably put more effort into the error messages...