One observation, based on my own habit of completely redoing classes, is new syllabuses suffer severely from lack of tuning. In practice, a "worse" syllabus which I've taught a few times before is as good or better than a new "better" one.

I'd say to put a moratorium on "improving" the class. You've taught it this way once, you've seen what didn't quite work and so on. Use that to make tweaks to smooth it out.

One thing that jumps out -- real-world examples. All students say they want them, but as you wrote, they always involve way too much domain specific knowledge. The actual thing you're trying to teach gets lost in the mess. Cut them and go back to the old "teaching" examples. It's not a complete loss -- when students complain you'll be able to say "yeah, we tried that -- didn't work".

Then just work on general smoothing. If lots of students loved a certain 3rd-party video, go ahead and add a link to it. Think back over test Q's you were sure more people should have known, but didn't. If students were weak on a topic they needed later in the course, expand it a bit and cut one of your darlings. I love teaching recursion, and did it at the end of 1st semester intro to programming, but it's tough to give a good assignment on, students needed more work with arrays, so it was cut.

One of the hardest things for me is to look over my shiny new baby syllabus (and the rest) and realize I had some good ideas, but also a lot of wishful thinking. And thinking it wouldn't need lots of tweaking was pure hubris. I feel like teaching ComSci at least has a metaphor for this -- writing a new program is fun. But you don't have a product until after the drudgery of debugging, adding nice interfaces, and so on.

One observation, based on my own habit of completely redoing classes, is new syllabuses suffer severely from lack of tuning. In practice, a "worse" syllabus which I've taught a few times before is as good or better than a new "better" one.

I'd say to put a moratorium on "improving" the class. You've taught it this way once, you've seen what didn't quite work and so on. Use that to make tweaks to smooth it out.

One thing that jumps out -- real-world examples. All students say they want them, but as you wrote, they always involve way too much domain specific knowledge. The actual thing you're trying to teach gets lost in the mess. Cut them and go back to the old "teaching" examples. It's not a complete loss -- when students complain you'll be able to say "yeah, we tried that -- didn't work".

Then just work on general smoothing. If lots of students loved a certain 3rd-party video, go ahead and add a link to it. Think back over test Q's you were sure more people should have known, but didn't. If students were weak on a topic they needed later in the course, expand it a bit and cut one of your darlings. I love teaching recursion, and did it at the end of 1st semester intro to programming, but it's tough to give a good assignment on, students needed more work with arrays, so it was cut.

A longer-term project is to look at previous, or even concurrent, courses in the major. Some things in the old syllabus may have taken advantage of those topics (maybe they all wrote small bash scripts, but have never seen HTML), or meshed better (and even if you wrote the old syllabus, it may have meshed coincidentally).

One of the hardest things for me is to look over my shiny new baby syllabus (and the rest) and realize I had some good ideas, but also a lot of wishful thinking. And thinking it wouldn't need lots of tweaking was pure hubris. I feel like teaching ComSci at least has a metaphor for this -- writing a new program is fun. But you don't have a product until after the drudgery of debugging, adding nice interfaces, and so on.