The foundational mistake is “teaching programming”. The goal should be to instill (“teach”) critical thinking and analytical problem solving skills, and a “programming environment” just another tool, like pencil and paper, which the student can use when exercising those skills on real-world problems.
Whereas “teaching programming” is teaching language features: what all the buttons are and what they do when you push them. Thus mastery of button-pushing becomes feted as the end-goal of itself, instead of being just some tiresome but necessary tool-practising crapwork (like memorizing the ten-times tables and drawing all the letters from A to Z) that you have to go through on the way to achieving your true goals (which can be anything).
Once again, I point to Papert’s Logo[1] as a good demonstration of just how simple that PE can—and should—be to serve that purpose. Logo’s core concepts can be communicated in just three steps:
1. This is a Word.
2. This is how you Perform words.
3. This is how you Add your own words.
Anything else that the platform provides, such as its dictionary of pre-defined words, can and should be explorable and discoverable; something today’s hardware and software can support and encourage without blinking. Let the students teach that crap to themselves if/as/when they need it, and keep the adults on hand just to observe when students start running themselves down a dead-end and prompt them to other possibilities they had not realized/considered.
Oh, and it really should go without saying that the PE’s error messaging must be the top of their class. Because errors aren’t the “wrong answers” of which a student should feel embarrassed and ashamed, but fresh questions in their own right which spark awareness, exploration, self-correction, and insight.
--
[1] https://www.amazon.com/Mindstorms-Children-Computers-Powerfu...