Teenagers are pretty much all losers. Teaching them how to write software is a mere drop in their vast ocean of ignorance, but it is a noble cause that works well to remind us real people that we are better than they are because we can do cool stuff that they cannot.
Teaching is an art form, and is fundamentally about showing off the things you know in the hopes that not too much of it rubs off on your students, because otherwise you lose your competitive advantage. However, you have to be willing to reveal the occasional ace up your sleeve, because how else are they meant to be smitten with your radical knowledge and skills?
To teach you also need a keen audience, but us mature adults know it’s hard making teenagers enthusiastic about anything unless it’s werewolf or vampire related. For those willing to take the challenge this is a collection of my best advice.
Teenagers learn very quickly when using their hands, hence why it’s so important that they don’t touch code until they’re already at university. But give a teenager a simpler and more accessible programming language such as Python and suddenly their learning escalates.
I don’t believe this is as much to do with how easy a language is to understand, read and write as much as it is to do with how quickly a novice can slap together a working application. Don’t be discouraged from teaching teens how to write C applications for Arduino, but make sure that the distance from taking your pre-cooked example to a unique behaviour/application is just a few lines of simple, understandable code.
My personal rule of thumb is that after fifteen minutes of introduction they should be happy to make their own contribution, see the results change in a meaningful way and also see the potential for where to go next. Don’t be caught into the trap of thinking that an easy and modern language is a substitute for a cool and well planned project, you’ll be caught with your pants down and probably put on a register.
When your art students can’t colour within the lines you’ll have a natural desire to slam their heads into the table until you see red, this is justifiable because colouring is easy. Programming, however, ain’t. Your beginners will have great fun copying and pasting lines of terrible code over and over again, with no natural notion or respect of the loop, switch, goto, generic, boxing/unboxing, and the list goes on.
It stands to reason that in any class room of such beginners you’ll be laden with horrific code obscenities that you’re eager to avoid next time you teach. I’ve found that trying to dump all of these concepts onto students before they get going is boring, but correcting code that they’ve written after the fact is demoralising for them.
I try to let them solve problems however they wish, and in regular intervals I will introduce a new paradigm as you would a new workshop tool. Everyone pays just five or ten minutes to learn the new thing, you show them what it’s for and what it helps prevent (likely to be things they’ve already done) and then you let them correct their own code as they see fit.
Everyone is different. Some students will gain extra satisfaction from correcting their own past mistakes, some will refactor just to fix their code, some will prefer to leave their previous work and simply improve as they continue. This approach satisfies all cases. If you can’t oversee buggy, mind meltingly stupid code without slipping into a coma then you shouldn’t be teaching, you should also avoid working for government contractors.
When someone asks you “what can this be used for in the real world?” or derivatives thereof they are actually asking you “how can I use this to show off to friends at school and/or family at home?”
Being able to give a good answer to this question has a long lasting and direct impact on a persons engagement during the session. If you’re working on something awesome, but it requires software or equipment that they can’t get easily at home, then you miss out on an easy motivator.
It’s always tempting to have students use your awesome preferred IDE and operating system, and a language that you love. But the focus should be on the project itself, and not your lackluster environment and poor decisions. Put as much effort into making the projects “take away” as you do making the projects fun and awesome and you’ll see a huge increase in enthusiasm from the group. You get extra bonus points if the project can be set up or demonstrated at school, especially if you supply a usb stick to run the software from.
I’d be a cretin for not mentioning the Raspberry Pi at this point, and sure, it helps with this requirement, but don’t be fooled into thinking that it’s a single solution that fits all. Most students are naturally going to hate working with a Raspberry Pi, so to know that these new skills can also easily be used on their home PC is important.
Making video games is great, but perhaps not for the reasons you may imagine. For a young, aspiring engineer, making a video game that is fun to play is less satisfying and captivating than a video game that is fun to design. You shouldn’t need to be told why as you’re hopefully an engineer yourself, we enjoy difficult problems and logical puzzles, and games are usually a grand repository of programming puzzles to solve.
The real question, perhaps, is why games specifically, if not because they are fun to play? Well, compare a video game to some programming problem in the same vein, such as a simple database, chat bot, calculator, etc. The advantage that games have is that teens are usually adept at using them, whereas the other options are either unknown to them or boring to use.
Challenge a teenager to create a great user authentication system and they’ll probably expect guidance as to what the features should be, and then begrudgingly follow those instructions. However, challenge any typical teen to create a great video game and you’ll witness their brains explode with creative juices.
Instead of always asking teens to make games, try and use this logic to come up with better, more structured or more varied project ideas.
Imagine you stole a baby, let them grow in captivity with only a rabid dog as company, and then at age 15 you gave them a potato running windows vista with 64MB of RAM and told them to write a web server in assembly using notepad. Assume this tier of work from your students and you will not be disappointed, as they will find special and unique ways of cocking up and making a mess. This is all fine and as it should be.
A teenager typically doesn’t need to work for a living, and has their entire lives to learn how to code correctly. Your job right now isn’t to launch a company. Your job is to convert these impressionable, vulnerable youths into the mindset that engineering is a fun hobby and a viable career choice, and then cater to their creativity as they explore this new idea.
Use your best judgement to determine when intervention is necessary, and when it’s right to correct someones work infront of them. But keep in mind that pages and pages of ugly code is a trophy to these miniature folk, and to you it’s a testament to hours worth of practice, determination and captivation into a subject that very few get to experience as a young teen.
Don’t be that typical and annoying shoulder lurker, and when you have to fix or debug things take this as an opportunity to suggest general improvements but not enforce them, then sod off and let them get back into their project. It does actually really help in this situation that most teens stink and are annoying to be around.