[another_story]

Interesting, because as a former CS teacher I regularly did this. We'd go through some material and then I'd demonstrate it being used in different contexts, sometimes writing code that wouldn't work and sometimes writing poor code (while loops that should be for loops, inconsistent variable names, etc...) and the kids dug pulling it apart. It's much easier to critique than to create when you're beginning coding.

On that note I've been giving a lot of thought lately on how to develop curriculum which does a better job of teaching coding skills without necessarily needing code. Design thinking, but at a smaller scale, and later translatable to beginner level problem solving. Where kids get hung up is they often don't have a toolkit for this type of thinking, and building that up, while still making it interesting, is a challenge.

[readthenotes1]

I did as well and believe my classes improved as a result.

I was taught "flow charting" as an attempt to teach coding without having to code. Of course, the teachers missed the point and forced template-driven syntactically correct charts that were more painful to build than the programs.

I have never taught software to complete novices, but I would think that it's difficult to teach something without teaching the thing. Have you tried the "wax on wax off" approach? That is, break things down into stunningly small pieces and build them together? You could spend days grounding on the fundamentals. (It works for training sports, rapid demonstrate/mimic/correct cycles on the basics)

[another_story]

I've tried something like what you're describing. Most years I'd start with a week or two of solving problems that don't involve any code at all.

For example, a day one teaser (these are 12 year olds) I liked to give was an 8 by 8 grid on the floor. They would get in groups and devise a way to move from a start to an end location. Then they would enact it, first me receiving their directions and later other students. I would of course take their directions a literally as possible, with them frequently getting exasperated ("that's not what I meant!").

We'd go from that to generalizing some rules and formulating steps. Once they had working rules, I'd add obstacles or change the start and end locations.

My goal with these was to develop the skill of seeing discrete, reusable steps, and how they mirror each other between problems. Learning loops and conditionals without ever writing coding, for example. Seeing the need for variables as storage, etc...