@futurebird@sauropods.win 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:
- Recent CS education research suggests that functions are one of the hardest intro programming concepts for most students, and shouldn't be introduced till some other concepts are mastered first (search "concept inventories for introductory computer programming"). It can help to first practice associative arrays/hashtables/dictionaries. Modularization into functions is harder still. The fact that many of your students are struggling with creating a function might indicate that they haven't mastered the concept yet and you might do well to back up a bit. If they need some remedial work, I cannot praise Parson's puzzles enough
- When running a lab-style section, where students are actively working on something with your support, I think it helps to interleave lecture time, work time, and debrief time. When you lecture, lecture rules (including controlling when interruptions can happen) apply. Work time is when you let interruptions happen more freely as you walk around to see how folks are doing. When I run such things I tell the students at the beginning of the section what the plan is. After a week or two they get it. I think it's useful to keep each work session on the shorter side, 10-15 minutes, with a well-scoped task and well-defined goal, and then have a debrief afterward where students can describe their experience, vent, brag, what have you. That way they know they'll have opportunities to talk and might be less inclined to shout out randomly
- If you don't have assistants to help you, recruiting other students to help field questions can be very effective. In the past I've had success dividing students into pods of 2 or 3, but only after observing the class for a few weeks. I strategically designed each pod to have at least one student who seemed to be on top of the material and another who seemed to be struggling. This setup requires communicating with the students regularly and adjusting the group assignments throughout the course, but it can lighten the load quite a bit, especially after the students get to know each other. I design classes such that the first few weeks are for setting the stage and warming up, and for me to get to know the students
- I've found it can be helpful to tell students some variation of "I know it's frustrating that your code doesn't work. Even today, code I write doesn't usually work the way I want on the first go. This is an experience you're likely to have the rest of your life when writing code. One thing to take away from this course is how not to be set back by this feeling. It's a normal part of the experience of coding, and it's telling us something". If that lands you can follow up by asking them what they think their frustration/struggle/what have you is telling them. The self reflection can be helpful and you can learn important things about your students this way (it can also lead to awesome discussions). Some students react very positively to hearing that this is a normal part of the process (they think there's something wrong with them, or that they are doing something wrong, if they're feeling frustrated).