Gfrktyl

Let me urge a bit of caution if you try to combine teaching of youngsters with their parents. Before you decide, you should look at the work of Piaget on the stages of development. Adults and teens from about 12 can learn abstractly, but those younger probably haven't yet developed the changes in the brain (including physical changes) that make that possible. Starting from around 7 kids can learn things like computing, but only very concretely.

I bring this up so that you don't wind up with classes that serve no one very well and frustrate everyone. Some programming environments stress the concrete and are good for youngsters (Scratch, Logo, and other visual systems) but adults learn very differently.

If your goal is primarily to have the parents help their younger kids to learn while learning just a bit themselves, then, I think you can be successful. Just keep it concrete and probably visual. But if you are asking more of the parents, then they might not be so satisfied and you will be inundated with questions that come from their deeper way of thinking and that won't have answers that the kids can grok.

On the other hand, if you want to start with teens and older you should have a group that is much more uniform in their mental structure and abilities so it would make a wider variety of techniques possible.

The minimum age

I honestly don't think there is a minimum age. While it's true that very young children have a harder time thinking in abstract terms than adults, it does not mean that children are incapable of it. For example, I started teaching my daughter very basic shell commands at 7 years old. She's now 10 and is relatively fluent with the command line and can even write basic C programs.

For her, the most important thing was to make it a requirement for her to use at least the very basics of the language in order to utilize the computer. For her, I gave her a Debian-based system that was all hers. However, while I gave her a flash drive with a few games to play, I did not provide desktop icons for them. She had to learn how to open a terminal, change directories, mark files as executable, and run them. That satisfied her for a time, but eventually she wanted to do more, like set a timer on the computer. That's when I taught her how to use the sleep command.

Other children might not learn the same way. You may not be able to, or want to, restrict their access to easier to use operating systems. Each child learns best in a different way. Despite that, there are a few things that anyone requires to learn a programming language:

1. They must be comfortable typing (real typing, not hunt and peck typing).




2. They have to have a language that lets them do something, not just see "Hello, World".




3. They need to enjoy it as a learning experience, not a chore.

The choice of language

I would strongly recommend against JavaScript. The language is convoluted and often does not make sense intuitively. As for HTML and CSS, those are not programming languages but languages designed for markup. Unless you go into the complex HTML5 + CSS3 territory, they won't be enjoying it any more than you enjoy learning new serialization formats (which I presume you don't).

Instead, I would recommend something like Bash. For a language that is more powerful, I would suggest either C or Python. The latter is certainly easier to learn, but C can help give a better understanding of low-level memory handling (yes, even young children can learn the difference between the stack and the heap!). Additionally, Python likes to enforce a maxim where there's only one correct way to do something. This can limit creativity. There's nothing more enjoyable than giving a child a task and seeing them come up with a solution that you didn't even think of yourself!

Getting them interested

No one likes being forced to understand an abstract concept that they do not enjoy. If programming is taught as a strict logical language, it will be no more fun than math is for many kids. If, on the other hand, accomplishing a task will allow them to reap a reward, motivation goes way up. This can be done easily with robotics. Everyone, both boys and girls, love robots! Machines like the Lego NXT can be programmed either using a silly graphical interface, or in pure C.

Basic programming can be learned by using an operating system shell. For children raised in the 80s and 90s, that often came from BASIC from various personal computers (Amstrad, Sinclair, etc.). Nowadays with fancy GUIs, that skill has been lost. You can re-introduce it with a shell of some kind, whether it's something like FreeDOS (a FOSS version of MS-DOS) or a Linux or UNIX distribution, a shell allows someone new to programming to see immediate results.

This is a much less useful answer than I wanted it to be, but I'm posting it in case it helps someone.

I'm not a teacher, but I've found that most 13-year-olds can learn to program using production languages (Python's a good one). However, I'll regale what I remember of my experience learning my first programming language. (WARNING: Tangents ahead.)

On a Windows 98 SE¹, aged five or six² I was trying to open All Of The Things™ to see what would happen. I happened to right click autoexec.bat, and there was an option called "Edit"... which opened up Notepad! When I double-clicked it, it popped up a message saying that I "couldn't run Windows when Windows was already running" but when I pressed "Edit", there it was! Code that I could read!

It wasn't long³ before I realised that you just needed the .BAT extension. All of the programs I'd written looked like this:

@echo off

cls

echo Hello!

echo This is a secret message.

echo Press a key

pause > NUL

Because I'd never seen any examples of a batch file other than these examples, I didn't know that you could run arbitrary programs from Batch files. I did know that you could run command /?, so when I found another batch file with an IF command in it, my programs evolved to:

@echo off

cls



echo Secret Message!

if exist secret.txt type secret.txt

if exist secret.txt pause

if exist secret.txt exit



if not exist secret.txt echo Enter your secret message > secret.txt

edit secret.txt

Crude, I know, but I didn't know about the web back then. (In fact, I thought Ethernet was the modern version of "Internet" (a modem port) and used neither, save as a magical device that brought back flash games when the browser crashed or I accidentally hit F5.)

I also discovered that Windows popped up a scary warning message about system instability when I renamed the .bat file to .com and tried to run it. I always wanted to make a proper executable program.

I later learned Scratch 1.4 on a Windows XP machine (aged 6 or 7), though I was thrilled to bits when I discovered that XP supported Batch Files too.⁴ Scratch didn't let me make .EXE files, but that didn't really matter because I could make proper games and had all of the blocks available to me. (Now I have "documentation", where I can find new blocks, but I didn't know about that at the time.)

Later, I learned JavaScript on Khan Academy, but got frustrated when I couldn't just copy the JavaScript into a .js file and run it... so I gave up. This was because I wasn't told the difference between JavaScript proper and the Khan Academy-provided functions. (I also wasn't told that you needed a web browser to get a DOM and graphical rendering.) I later got a Scratch account and was introduced to Small Basic by my primary school head teacher; the rest is history.

I expect that, if I'd had programming super-geniuses around me to help, I could've been building web pages with JavaScript (instead of saving Word Documents as boring, non-JavaScripted HTML/inline CSS files and manually stripping out the Word cruft through trial and error) and programming fully-featured executables in Small Basic (instead of not even being able to imagine the concept of a compiler) aged 8. Though... the skills that allow me to quickly pick up new languages now were acquired through lots and lots and lots of doing-it-myself and figuring-it-out, so being babysat and hand-held through the process would have hindered, not helped.

¹: a parental discard (as with every laptop up to my very first (which I recently fixed up (read: replaced non-functioning Windows with functioning Debian) and am currently typing this answer on)) which, if I remember correctly, was reinstalled twice after it became completely unusable (MS Paint scribbles were painstakingly preserved via floppies).
²: perhaps around the time I discovered the File Associations dialog and was disappointed that I couldn't make a .wizzwizzfile type that was a valid WAV, TXT and BMP file (an idea I got from my open-everything-in-Notepad phase, which lead to the destruction of Microsoft Paint and many, many tears before it was recopied from the installation disk)
³: at 30 minutes a day, maximum; permission had to be sought every time I wanted to use a laptop
⁴: I remember noticing that XP supported multi-line IF, but 98 didn't; my only emotion was annoyance, and only very minor excitement at discovering the annoying workaround and manually porting the programs back by duplicating the IF line.

How is this relevant? Well, it tells us a few things about how young children can learn programming:

• 
  The child needs to be curious. Don't just sit them down and start talking at them. Don't just show them a flashy animation or a neat game and say "You can make one of these!"; they need to have questions. If they're not interested in figuring it out, they're not interested.
  
  I recommend asking a parent / young-child-teacher how to get a child interested in something.


• 
  The child needs to have something to tinker with. For me, it was Windows 98; as a DOS-based system there was an accessible, interesting "puzzle", but as a Windows system there was a nice friendly GUI that wasn't easy to break.
  
  I still have a deep-rooted fear of white-on-blue monospace jumpscares and system beeps, so I'd recommend giving the children something that, when it fails, uses no new UI elements (no persistent red bold text, no popups with a yellow warning sign, etc.). If possible, it should keep on trucking. My recommendation would be Debian with LXDE, with a short GRUB timer, without wireless web access, for the following reasons:
  
  
  
  
  • 
    YouTube is very good at distracting without educational value. You don't want the child to discover YouTube. Even the most banal flash games have more educational value than endless novelty, since they can provide inspiration. YouTube stifles boredom, so stifles curiosity. The computer shouldn't become a YouTube machine.
  
  
  • 
    Manuals can be downloaded. The only thing that can't be downloaded is Stack Overflow, but they're too young for that anyway; you need to be able to distinguish between good and bad answers to use SO, and SO assumes a minimum amount of knowledge. man manuals are the right sort of difficulty, I think, since they're as easy to understand as their topic, but boring enough that they aren't your first port of call (you try to figure it out yourself first).
  
  
  • 
    GRUB shouldn't be discovered early. GRUB should be part of the pretty pictures that show up while the computer is booting (after the manufacturer logo and before the scrolling text), but it shouldn't hang around for 5 seconds. 5 seconds is long enough for a child to get bored, mash some keys, and the computer to not start up. But eventually the child will get curious about what those pretty pictures are, and mash some keys.
  
  
  • 
    Debian is mostly stable. It doesn't BSOD when you do strange things, and even if your keyboard-mashing happens to be a valid ELF file and you set the executable flag and run it, you're not going to overwrite the kernel or trigger a system crash (just the humble segfault).
  
  
  • 
    Most things are text files. In Windows, if you manage to crack the shell-level dereferencing of .lnk files (not .Ink files) and open one directly in Notepad, you'll see a binary file with T e x t t h a t l o o k s l i k e t h i s that you can't edit easily because those "spaces" are actually null bytes; in Debian, if you "right-click -> Add to desktop" a program, you'll get a text file (INI, iirc) that you can tinker with.
  
  
  • 
    Debian's used in real life. The only other OS (family) that I know of that matches enough of the criteria is DOS-based Windows, but almost nobody uses that any more (so its knowledge, while still serving me well multiple times a week, is a lot less useful) and its warning messages are scary. Debian's are scary too, but not quite as scary and only when you've used sudo to mess something up. Which brings me to the next point:
  
  
  • 
    Non-elevated users can still do loads, without permanently breaking much. Liberal use of read-only Python scripts with the set-uid flag set can extend this further.
  
  
  • 
    Lots of Debian's written in scripts. Mostly Python or Sh, which are both good to learn and relatively easy to fiddle around in because they're text files. Showing the child IDLE will keep them occupied for hours. Make sure to show them help!
  
  
  • 
    You can access all of the code. Simply press Up in pcmanfm a few times and you're in the root directory!
  
  
  • 
    Source code is available. It'd be a good learning experience to be taught about compilers and go "Ooooh, that's what the programname.c files were!" (since the child will probably try, and fail, to run these files bearing similar names to runnable programs).
  
  
  • 
    Almost all programs accept --help. While it's not as easy to discover as DOS's /? (perhaps a reason to favour DOS), if a child is told about --help they can work out how to use pretty much anything. Same with man and info.
  
  
  • 
    You can set up backups with rsync, tar and cron. Backups. Backups a thousand times. You do not want a sad child who has just erased everything they can write to by trying out rm -rf / --no-preserve-root (or, at least, you don't want them to be sad for any longer than necessary to learn that lesson early, which in my experience is about 5 seconds). I recommend making backups to a remote machine every 10 minutes, and using tar's incremental backups feature to ensure that every version is saved.
    
    Note that I didn't say "make sure they can't delete all their files"; nothing should be off-limits. Plymouth shouldn't even run on startup, nor should the OS boot into startx immediately (though for a very young child you might want it to).
  
  
  
  


• 
  A teacher who knows everything and can be asked questions is useful. I would've liked this a lot. Unfortunately, no such teacher exists... but is that such a bad thing? You can show them how to find stuff out for themselves, if they're old enough! I tend to use DuckDuckGo, since it doesn't constantly advertise Chrome and YouTube at you in deceptive popups at the side. The child can ask to look something up, plug in the Ethernet cable (located elsewhere; hence the laptop), find the documentation page and unplug it again; if they get to the point where they need to look stuff up frequently (the Stack Overflow point) you can start teaching them like an adult. Until then, answer all their questions, and when they ask a big one you can teach it to them. Be interested in what they're doing, but don't give unsolicited lectures ("Do you want to know about X / how to do Y?" is good, but "X does blah blah blah" is not).


• 
  Code should have immediate effects. When you run the program, something should happen. Scratch is good for this, but a diet of Scratch and nothing else is not as effective as it should be. You want to train a polyglot.


• 
  A tutorial that uses good style, or no tutorial at all. I've used tutorials with good style and bad style, and learned languages without any tutorials (just a few example programs) and it's pretty tricky to unlearn bad style. You can get good style by osmosis, but that's much easier when you've got good style in the first place. I'm not sure where I learned the importance of style, so you'll have to figure that one out yourself.

To summarise:

• Age: 2
  
  Use ScratchJr or similar. It has pretty buttons and you can make things move, and it gets you interested in programming.


• Age: 4
  
  Use MIT Scratch (offline), and have an OS that can be pulled apart. Lots of the things that are done won't be directly programming-related (e.g. spending 20 minutes completely destroying the UI) but it's all learning things that you probably take for granted that you know (e.g. that multiple things can use the same value for font colour, or that pink and green are lovely colours for window titlebars). Have Python available.


• Age: whenever they seem ready
  
  
  
  
  • Start to teach them "grown up" programming languages. Don't say something like "Scratch isn't a real programming language"; that's disheartening and false.
  
  
  • Introduce them to the Scratch website; it's a good programming community.
  
  
  • Start introducing more abstract programming techniques.
  
  
  • Once they've reached the "minimum knowledge" in both a single "grown up" programming language and in programming in general, show them Stack Overflow, the Font Of All Knowledge™. (Perhaps also Wikipedia, the Font Of All Knowledge™, but only if you don't mind them being very distracted for a few months.)
  
  
  
  

Never.

My parents sent me to programming courses when I was 7-9 years old or so, first half of the 80s. Completely useless knowledge today, but that is not the worst part of it - the worst part of it is that at a time when I should have learned to interact with other humans I spent a lot of time in front of a computer. I also took the STEM way through school and university because of this. It wasn't until I was around 25 I realised that this was completely wrong for me and I would never have elected to go to this courses as a kid unless my parents had pushed me.

Programming is easy to learn, and probably will be even easier in 10-15 years when these kids have grown up. Kids don't need artificially more screen time or earlier introduction to computers than they will have anyway.

These kids are far better of if you play boardgames with them, take them on a walk in the forest, read a book for them, play some football, teach them to swim, play an instrument, visit a farm and interact with cows and pigs or something like that. And yes, it is mutually exclusive with programming.

If a 16 year old wants to learn programming on her/his own initiative, fine but don't force young kids to live their parents dreams.

Besides, recently there has been a lot of articles about how the Silicon Valley elite stops their children from spending time with their phones and computers. That should make you think.

https://www.businessinsider.com/silicon-valley-parents-raising-their-kids-tech-free-red-flag-2018-2?r=US&IR=T&IR=T

https://www.theguardian.com/technology/2015/may/23/screen-time-v-play-time-what-tech-leaders-wont-let-their-own-kids-do

https://www.thriveglobal.com/stories/silicon-valley-execs-are-wary-of-the-devices-they-created/

and so on.

That includes programming. Just. Don't. Do. It.

I've been teaching kids (7~13) for last four years or so, with languages including Scratch, Python, Java, and C++. Surprisingly, kids can understand these languages even at young age.

The best time is about at 7 ~ 12, starting with Scratch. Minimum age would be around 7 because, even for a beginner, many examples and practices will involve some sort of creating a game or app that requires basic math or science knowledge such as x, y coordinate, calculating numbers, etc. Also, in general, screen time is harmful, in my opinion, especially for very young kids. Spending several months to a year on Scratch, and then teach them how to type fast using some typing game websites. Then, you may teach them Python first, and then JavaScript when they become 10 to 12 years old.

Basic knowledge in math such as arithmetics and better yet the concept of variables and functions in algebra can be very helpful when kids gain some experience with programming.

I started with BASIC on the ZX80 at 8 (self taught), I graduated to Z80 machine code at about 10. So, I'd guess js would probably be fine from 10+

Having taught small groups of children HTML, CSS, and JS as holiday programmes, my thoughts are:

• be aware that many parents send their kids to classes for one or both of these reasons:
  
  
  
  
  • to babysit them
  
  
  • to "enrich" the children in something the children are not really interested in.
  
  
  
  


• If young students (< 12) are not interested, you can get them about as far as understanding that there are bits of the code they can change that will change messages or backgrounds. If older students are not interested, they will get more out of it, but you will have to focus more on "making it cool" than understanding concepts.


• Whether or not there is a good level of interest, the children will at times be bored, tired, or some will be behind and others ahead. You need to have some easy and fun distractions/topic changes, or ways to keep the fast ones busy, and look for signs that students are losing the ability to concentrate. At this point it is unlikely to re-invigorate them with some whiz-bang, they either need a break or have reached their limits for the day. (So you need activities they will enjoy that don't require concentration.)


• In the 5-10 age range there is a mixed bag of typing skills. Some students are very slow or struggle to recognise special characters. (So, Scratch. Or GameFroot)


• I would say that age is much less important than age range. If you have everything from 5 to 15 year olds, you are not teaching them all the same thing, even if they are all doing the same activity. If the students are of a similar age, you can teach concepts appropriate for that age without trouble and be aware of who is falling behind.


• Parents and children should be OK; the parents expect that the content is at a level the children will understand. But children and adults is not good, because the children slow things down so much. However 15+ is fine, and 12+ is probably OK, especially if they are interested.

You can start at 7 (maybe younger): I have taught this age. We used scratch (the language), it is well suited to this age, and older.

I have only taught a single student at a time, at this age. We coded next to each other, taking ideas from each other. e.g. I would add arrow key control, the student would copy that bit of code, I would ask “Can we do this for a second character?, How do we …?” We make good progress (In similar number of (but shorter) sessions): arrow keys, drawing, multi-sprites, mouse control, edge bounce, sprite detection, score, …

If you teach them problem solving you will help them far more than if you teach them syntax of any programming language. Those that know problem solving generally won't be coming to such classes to learn syntax.

To have both kids and adults participate, I advise you to teach "physical programming" instead of stuff on computer. It will be much easier to find a task interesting for both adults and kids no matter their age, and it will give even young child feeling he/she achieved something. Additionally, it is far more social than sitting in front of a computer - you could have everyone participate and "program" a single robot/car/... at the same time, or you could have pretty interesting competitions perhaps even with a small prize for the winner.

Now, when to start - I wouldn't teach younger than 3 simply to avoid liability if they end up eating blocks or whatever. But if you push that liability to parents, you can teach even younger ones. Primary school kids are old enough you could have a group without parents present.

To start as early as possible: Cubetto is a wooden robot that knows forward and rotate left/right (by 90 degrees). Plus a single function that can take 4 commands. It is a decent choice for classroom as it is fairly sturdy. There are other alternatives with similar difficulty (say code-a-pillar is cute and cheaper, but it will break faster). Tasks mainly involve variations of "how will we get from our current position over there". Difficulty range is suitable from 2-7 or so, though you could create some "challenges" that wouldn't be trivial even for most parents.

Primary school, teenagers, nearly everyone: Lego. Nearly everyone has Lego bricks at home, many have technic bricks too, so having something that fits right in is great. Plus, difficulty range available is pretty huge - it won't be trivial even for adults that know programming. You can start with about 6 year old children here. Nearly endless options what to do, competitive challenges are organized for primary schools every year and you could steal some of their ideas and put a fresh spin on it (depending whether you want to increase or decrease difficulty - depends on your group age and skill).

tl;dr- You probably shouldn't encourage youngsters to take your course if it's designed for adults. Adults who want to program need to learn about specific syntax and technologies that can be used today, while children are better off focusing on the abstract concepts.

Adults and children tend to have different learning needs

Adults who want to program need to know the specific syntax, technologies, tools, and environments that exist today. They need to know the quirks of different browsers (for JavaScript/HTML/CSS), the idioms of their chosen language, and the best practices for writing actual code.

Children should also learn about programming, but their learning goals will tend to be different. They have no need to know anything about today's web browsers, API's, idiomatic styles, etc., any more than a modern programmer needs to know about how to program an old-time computer with punch cards. It's useless information – or, worse, potentially harmful misinformation that they'll be worse off for having to unlearn later.

If a child's parents try to enroll them in your course, you might advise them that, while it's probably a good idea for their child to learn about programming, you're going to teach the details behind how to write programs for today's systems. By contrast, their child is more likely to benefit from a course that focuses on the concepts behind how computers work, without wasting the student's focus on modern implementation details.

There may be exceptions

Some younger students might actually want to learn modern implementation details. For example, there're kids out there who want to learn more for the same reasons adults do, such that they'll need to know the trivia behind present-day JavaScript/HTML/CSS even though that trivia is likely to be useless by the time they're an adult.

In those cases, you might need to consider allowing them in your course on a more logistical level. For example, are you prepared to handle a misbehaving child? Are there any laws about childcare that must be observed?

If you've got all of that covered, then you might choose to allow younger students into your course.

My minimum age would be 12-13ish.

I taught myself programming at the age of 13, on one of the first gen 8bit home computers. I consider myself to have been the ultimate nerd back then. I slurped up every bit of information I found in books or magazines. So that's that.

My youngest child is 9 now, and quite the nerd as well - but for her that still means games, Minecraft etc. I daresay I have tried a little bit to encourage her exploring with Scratch etc., but hit little interest. Mainly because it is hard to motivate a 9yo finding a "domain" to program in - the joy in purely abstract stuff (like first data structures, control logic etc.) is just not there for her, yet. She would be motivated by results (like, and I kid you not, "Daddy, I would like to program... can you show me how I can program my own Minecraft, next weekend"). But anything you can program today is by necessity so vastly inferiour to even the simplest web game etc. they can play, that it's hard if they are not internally motivated.

For these ages, I found the Nintendo Labo series excellent, or websites like Pixel Papercraft, where they can combine child-adequate real world skills (working with pen, paper, scissors etc.) with "tech". I fully expect us to upgrade to something like Lego Mindstorm or whatever gadgets there will be around when she's about 12-13. And I may introduce her to some programming using Javascript or something else which leads to immediate results (don't, also, dismiss the IOT angle, i.e., Arduinos and the like - having lights blinking etc. can be fulfilling as well; and their language is far simpler than any PC language with its plethora of libraries and special stuff going on).

There may, obviously be exceptions, and it's harder in our case because she is only starting to learn English, so all the really good resources are closed to her yet. That may or may not be a factor you can alleviate if you roll your own course, obviously.

I like Scratch: It is a great start to learn programming.
Children were taught programming in the company where I worked. The greatest successes was with 9→12 year old children. The younger ones did not show much interest. But did tasks well.

I am not sure if just a simple age number would suffice.

I think, for a child to be able to learn programming, the following requirements need to be met:

The child needs to be able to write simple English

For an English native speaker that means being able to write fluently. For a child that is learning English as a second language, that might be a lot later. When my father tried to teach me programming at the age of 10, my English was so poor that I struggled more having to memorise keywords than I did learning programming concepts. In the end I gave up quickly. But when I tried it again at age 14, that was no problem anymore.

The child needs to grasp basic math

I think the association between maths and programming is overrated (being a great programmer does not necessitate being a great mathematician). That said, the knowing the basics of maths is necessary or at least greatly helps understanding some basic programming concepts. While the specifics of mathematical variables and functions and their programming counterparts differ slightly, knowing their mathematical version helps a lot to understand these programming concepts. Also, if they are old enough to understand the mathematical concepts, they are old enough to understand simple programming concepts.

The child needs to be interested

Especially at a young age being interested in the topic is more important than anything. And by that I don't only mean that the child is interested in the idea of programming, but that the child actually likes doing it. Children (same as many other people) might have misconceptions of what programming is. They might like the idea of whipping up another Minecraft in half an hour, but they might not stick with it as soon as they learn that programming entails hours of concentrated hard work only to make something that looks rather simple.

Another aspect of this is that many parents would like their kids to learn programming and send them to a programming course, even though the kids don't care for it at all. In such cases it is almost impossible to teach them anything at all.

Abstract thought

Depending on what exactly you want to teach, some things might require some abstract thoughts abilities that are only develop during the development of the child. But firstly, the age where these abilities are developed vary wildly. Secondly, these abilities are rarely what limits a child from understanding programming.

As a side note: don't start with JS/HTTP/CSS. This might be a good start for an adult, but it is a terrible start for a child.There are just way too many dependencies that they need to learn before they can make something cool.
In my work teaching youth programming I found, that to keep them motivated it is important that they learn to do something cool, something fun and something that they can show off. I like to use Python. Within the first ten minutes or so I teach them about text input and output, ifs and variables. I don't go into details here, just do the very basics. Then I let them start on their own little text adventure game. After they built the first few scenes, I show them loops, to make a combat scene or something like that. Then I show them, that it is much easier to organise each scene into a function, that is called from another function. Then I show them how to use returns and a main loop to avoid a long call stack (each scene function now returns the nect scene's function that is executed in the main loop).
On the second day I use a library like pygame to show them how to make a little graphical game, like a scrolling racing game. Again, skip specifics and only teach the minimum necessary. There is enough time for specifics later.

Just don't ever use the textbook approach with kids, where you basically go through a 500 page book and still are stuck in the commandline having built nothing at all.

There is no minimum age. A prodigy may start with 2 [IQ 140-160] without guidance and some of the less intelligent beeings may never learn to setup a PC [IQ ~80-85]. Consequently, the question makes no sense.

I would just start a class and see who stays there. For the average people I would expect an age range of ~12 to 14 years as a normal starting point.