> I've had a lot of success with a simple trivia game that lets them start by modifying the questions/answers & the replies it gives.
The beginning of my own path to being a programmer, long ago, was playing with games made in RPG Maker 95. If I didn't understand how to pass an obstacle, I would "cheat" by opening the game's world-database file up in the game editor, finding the "object" with the logic that was inhibiting my progress, and then modifying it to allow me to bypass it.
After that, I progressed to just opening games in the editor to "figure out what the author actually wanted me to do here" so I could go back to the game and do it; and then, finally, just observing how people had constructed their games.
All in all, it felt very natural to transition from there, to making my own games in the editor.
I think it was a (probably unintentional) brilliance on the part of the company who produced the software, that the games produced only by using the "hardcoded" features of the game-editor were so simplistic and limited--while also allowing a complete, Turing-complete scripting capability. It meant that, very quickly after starting down a path saying "I want to make a game", I was forcing myself to learn programming concepts in order to extend the engine with the features I wanted in a game.
After a while of doing that, I had absorbed enough about programming to understand that the game-editor tool itself wasn't "magical", and that the whole of its hardcoded game engine could be represented with a not-overwhelmingly-large piece of the same scripting-language logic I had already been writing.
After that moment, it just felt "natural" to move on to reading some Javascript tutorials online, and to pick up a book on C.
The realization that there was no magic in the software I interacted with, but instead merely sequences of small, logical steps I could identify and replicate myself, using a library of atomic mechanisms (branches, loops, etc.) specified to a computer in a formal language: I think that is the one thing that needs to be captured by anything that claims to "teach programming."
And, personally, if I were going to teach programming, I'd try to do it just as I did above: give them completed game, but an overly-difficult one, one which they aren't just modifying for the sake of modifying, but modifying because that's what will let them win.
And, at first, I don't think "programming" even needs to be introduced. Just introduce the framework, the idea of modifying an existing interactive thing (don't call it a program), even if it's just by opening a visual editor and erasing a rock that's in your way.
Then, in later exercises, you can make the "thing that's in your way" much less simple--a sprite whose state is wrong, an event that won't trigger until a flag is set from somewhere else, a person who expects some variable to hold an impossible value where you have to construct the trigger to set that variable yourself; etc.
Eventually (but probably within one semester of an after-school-club setup!), this "adversarial modification framework" could work up to the point of something like Core Wars, where the student is writing writing complex agentive processes controlling shield drones to protect the player-character from enemy fire as they move toward a goal.
From there, you've got a decent jumping-off-point to the "wanting to mod the engine to get it to do the cool things other people have made it do" phase, and from there to the "why not just write it all myself?" phase.