I agree with you on your first point where you say that the best way to get concepts is by breaking things. But two to five minutes for explaining such CS concepts as variables, functions, and even operators may prove to be nothing more than just a fleeting moment, especially if you are dealing with a group.
Do you mean 8-16 as an age range or a number of students in the class?
Also, not all kids get excited at the first sight of scale. It often requires taking time to explain things and give different examples of this phenomenon.
Many of us are taught music lessons early in life but only some become musicians. The main goal of these lessons is not really for us to become professional musicians in future, but to know that music is composed of notes, who the classical musicians were, what instrument are there, and so forth. The same thing applies to arts and painting classes. The basic goal is for us to get an idea about basic techniques and gifted people.
The main thing to learn is the fact that both music and painting are forms of expression and that we will continually encounter them in life. Also, with the help of these early lessons many uncover their inner genius and that helps them go in the known direction from that point on.
Since coding is an activity that trains one's computational thinking - a skill that is so relevant today - it better be introduced early in life too. It is also a form of expression, and knowing that it exists and how it can be applied is just as relevant as knowing about arithmetic, letters, music, art, etc.
I don't suggest that the format of the current classes is the right one (in fact, I believe that it is not), but it is essential to have a child-friendly methodology and teach coding, or rather "programming", as a skill early in life.
I absolutely agree with Nikos' approach to teaching programming young learners without using an actual code. If we teach kids the idea of programming early - it will then be much more intuitive for them to pick up the language formalities later. Because by that time, such a fundamental question as "why" is already answered in practice.
In other words, the time for a real language comes as an actual need that has been experienced in practice and doing. And that makes all the difference in understanding what you need and why.
It's all over the web that more and more parents and teachers come to appreciate the idea of teaching kids to code. But the problem is that they don't know where to even begin or what tools to use. As a result, kids looking to learn programming today are faced with two main extremes:
(1) storytelling, game dev, and animation programs; and
(2) real-world languages or tools based on IDEs;
Programs in the first category are all fine, except for cases when the app is too compute-intensive, or 3D objects are clumsy or rough-looking (but these problems are just temporary).
But those using real-world IDEs to introduce programming are effectively training young pilots on real fighter jets. Such tools seem too complex and intimidating even for experienced computer users. What they really ought to be using is a "flight simulator", but currently there are too few tools that allow to do that and all pretty limited.
Even when we have something that useful it makes absolute sense to use physical games in the gym to introduce the notion of composing instructions for something/someone else (a parent-robot in Nikos' case :)
Nikos, thanks for sharing your work, and congrats on joining Knewton!
Hope you don't mind me including a link to videos of your class once again:
Do you mean 8-16 as an age range or a number of students in the class?
Also, not all kids get excited at the first sight of scale. It often requires taking time to explain things and give different examples of this phenomenon.