AlexVsCoding - How I learnt to program through teaching others.

If you prefer, the video attached is a 20 minute talk that I did on the same subject at the event Update in MediaCity Salford. Thank you for taking the time to watch or read through this and hope that it inspires you accordingly.

So I did a talk in Manchester earlier in the year and I was looking to do a write up to accompany it (since with it being my first talk/time constraint there's things you miss out). I'm going to be talking about my experience of learning to program and how teaching children rapidly expanded my understanding of this area. I'm also going to be talking about the benefits of teaching children how to build video games and how you can get involved yourselves.

Early Years

So when I was about ten, my dad, a tremendously creative teacher in Computing and Design Technology, introduced me to programming. He sat me down and set me the challenge of creating a house in the software Flowol that looked like this:

5 hours passed, and what I presented to my dad was this:

Evidently, this didn't go very well, and my interest drifted closer to the art and design side of the games industry.

I went to do a college course which bought me closer to the industry and fueled my interest, but alas, the course was visual oriented and the programming in the course structure was limited to monkey see, monkey do.

What really gripped my attention around my teens was Forge, a creative component of the Halo games. This gave me a basic template and tools to construct things in, along with a full community that taught me the workflow of of testing a product, documenting development along with advertising and distribution. I built a dodgeball arena with auto-return system and a set of zombie maps which changed their structure over time to shift the balance of play. Whilst this was a massive contribution to my development as a games designer, restrictions that the software held were my core drives to get better at programming since there was so much more that I wanted to do!

I began to get involved in programming again when I was at university, But after several failed years of projects, the straw that broke the camels back was a team project that disintegrated mid-year. This was when I realised that the programmers lacked the skill at the time to build suitable engines for developing games upon. To deal with this, I set up AlexVsCoding. This was a promise to myself in the form of a blog that I would not stop until I learnt or found a tool that allowed me to build my own video games.

Action script was my first port of call: building the basic structure of city simulator Poo Tycoon made the programming experience easier since it was dealing primarily with changing variables. Outside of that, progress was slow and expanding my knowledge outside of the basics I found challenging.

The Game Changer

I visited Eurogamer in 2011, with the aim of getting myself a placement. I got a new suit since I had no idea what to expect and made a royal goose of myself when I realised it was a casual event. Many of the stalls were covered by PR teams, which as lovely as they were, I was expecting to be talking to the developers. Feeling slightly cheated of my money, I wandered into the indie section and bumped into a fellow called Alistair Aitchenson.

He was a very friendly and helpful bloke who gave me a plethora of advice of how to get started with programming. I took away from the event 3 names; Flash Punk, Flixel and Stencylworks. The first two I attempted to use but couldn't even figure out how to install the kits and then discovered Stencyl. The interface was nice and visual, but for a good quantity of my early experiences in the software I just found development kits and wombled parts for my first project, Narcissus.
Fast forward a couple of months and after a suggestion from a friend, I spontaneously registered for a summer camp program at 6am - an hour before catching a train to Manchester for the recruitment fair. There I applied for a role in mountain biking at a summer camp. The owner immediately shot that idea out of the sky and followed it up with another question - "what can you tell me about games design?"

I still knew very little in Stencyl and hadn't even listed games design as an option since I thought the camps would be rustic. I scraped all of the knowledge I had thus far together and pitched him a programme. I pulled it off and before I knew it, the contracts were signed and I was to be a teacher of games design!

Great right? Hmmm

My parents are both teachers and understandably their initial reactions to the news was horror, to the extent that my dad took me to a pub to talk through a nice long list of possibilities (what happens if you suffer a total meltdown and have to come home early, how are to going to teach games design to 20 kids with no previous experience, this is clearly slave labour etc). After a good hour of grilling, I managed to stay resilient to going.

Getting Started

Sure enough, a couple of months down the line and I found myself at camp with a handful of tutorials I'd put together and after the first two weeks of induction and excessive amounts of preparation, I braced for the unknown. Other than a class that had failed several years back, this was the first year of the class so unlike the other departments there was no previous generations of staff as backup!

Whilst many children in the first session were receptive to the designing of helicopters for the visuals of their games, they weren't keen on the gameplay mechanics of the tutorials (ironically the helicopter game was essentially a tutorial of how to make flappybirds). Their projects branched off in all sorts of terrifyingly diverse directions and each child as stubborn as the next to deviate from their vision.
This made a standard teaching structure near impossible, so I resorted to helping each child individually with their unique issues. Whilst in the first year there was an average of around 15 kids per class, this was still a strain since each one wanted or was building something different.
Despite the complications, the constant discovery and reinforcement of hundreds of different questions meant my mind slowly began to accumulate lots of different knowledge.

The learning experience at home and teaching in class was the comparison between an avalanche and snowfall: learning to programme at home made me feel like I had to learn everything at once and there was a tremendous crushing weight. Teaching in the classes provided me with a constant downpour of questions, each one like a snowflake, different from the last but easier to handle and held context. Addressing each one of these separately meant that my knowledge accumulated over time. The diversity of questions had me spending evenings constructing entire projects just to try and solve questions.

Baptism of Fire

Despite the vast knowledge that the classes were bringing, my brain could only take so much. As the weeks passed, the children became more frequent as word spread of the games design class like wildfire around the camp and I became weary. Thinking back to my dads previous statements, I knew I had to find a solution.

To cater for this, I put together a crowd control system - the Problem Board. The basic premise was inspired by flow theory, what Mihaly Csikzentmihali used to explain the levels of engagement an individual feels when doing an activity.

In the classroom commonly found were found three main types of children:

1. Those with too much of a challenge with not enough skill, triggering anxiety and stress.

2. Those with too much skill and not enough challenge, leading to boredom and misbehavior.

3. "Goldilocks children" who had just the right amount of skill and challenge to keep them engaged.

Every class consisted of an hour, in which time each student gets 4 minutes of help (60/15), which isn't much time to solve complex problems. To address this, I assigned the children who were bored to the children who were anxious. I did this by getting the children to write down their technical problems, then rewarded them by giving them the time they saved the teacher by solving someone else's problem.

This helped address issues at both ends of the spectrum and saved me a world of stress as responsibility shifted to the kids.
Teaching their peers cemented the knowledge into the helping student's brain, along with planting the seed of their knowledge in the minds of others. The burden of simple to solve questions was lifted from my shoulders, giving me the time I needed to get to the bottom of the really hard questions whilst kids scampered around the classroom clutching sheets of paper.

By the end of the first summer, there had been 120 kids pass through the doors and each left with a video game on a CD and a big silly grin on their faces.

The Aftermath

The first thing I did at the end of the summer was completely gut out the programming for Narcissus. From what must've easily been over 500 lines of code, I refined down to less than 30 lines that ran much better than its original counterpart. The process of constantly constructing code all summer had conditioned my brain into being able to visualize how to construct games from just a description.
Not only was I working on the projects of the children, whilst away for the summer I had made so many shooters for the students that I decided to put my concentrated knowledge to good use and built my own game, Trenchbrain.

To add to this, many of the prototypes I built to test mechanics I developed further into full scale games, or the knowledge gathered used in later projects.

Since then, I've had 2 more summers at the camp and in that time a total of 500 kids have built video games and the teaching staff has expanded to 3 dedicated staff members. I've had a total of 1500 hours of teaching time in the classroom along with around 100 hours in UK schools.

So why consider teaching in order to learn to programme?

1. Teaching games development gives you the opportunity to work with and mold the next generation of talent in the games industry. I had the very proud moment of having a visiting returning camper tell me because of his time in my class, it had inspired him to pursue a career in the games industry and the game he produced in class he used as his entry project to University.

2. It never gets old seeing their faces light up as their character moves for the first time.

3. Running a classroom improves your project management skills, as keeping track of 60 different projects a day is to say the least a challenge. The classes run for approximately 1 hour a day for 3 weeks, so it's essentially a 21 hour game jam!

4. Outside of the need for financial gain and in the age of unfiltered imagination, innovation flourishes. Despite my worries of returning this summer to an impossible ocean of flappy bird clones (due to the number of clones seen on developer sites), out of the 200 students I had this year, only one made a flappy birds clone (which was a remake of an original project from the previous summer). The pure variety of different projects you get to work on is amazing. I've helped kids build real time strategies, Kung Fu battle arenas, racing games, archery tower defenses, bullet hell shooters, point and click scavenger hunts and much, much more.

5. From a developer perspective, it's also pretty practical if you're short of cash and need to live cheap. Many Kickstarters have a large portion of their funds dedicated to living costs, but working on the campsite and the department allowed me to constantly expand my knowledge and in the evenings develop my own projects whilst getting paid, fed and housed. This does require for the most part burning the candle at both ends, but this is just as comparable to working at a grocers stacking shelves throughout the day and developing games at night. Compared to stacking shelves, the experiences in the classroom will expand your knowledge and engross you in a wonderful subject.

6. Not only is there a diversity in projects, but also in age, nationality and gender. The age range varies as young as 6 all the way up to at the oldest of 18. The youngest children are weighted to the visuals of the project and hilarious narratives whilst the older students focus on visual fidelity and solid gameplay mechanics. The older kids are very receptive to helping the young ones with problems and this allows me more time to tackle their complex requests.

The campsite had a strong international presence, so in turn we had many kids who couldn't speak a word of English, but could express themselves through games development (and for the programming with the help of translation software!)

From starting initially as a class filled with boys, the presence of girls in the classroom thankfully began to occur. There was one camper who when considering the class was thinking otherwise for the lack of girls. I replied by telling her that if she left the class, then the next girl/s who were considering joining the class would think the same. A wonderful moment near the end of this year was having a full class of girls (with a large female presence in other classes as well).

How to get involved

Well, it's never been easier. As an inhabitant of the UK, here is the list of possibilities I've found thus far:

1. Coding Club
Teaching 9-11 year olds in after school clubs is an excellent place to start. They primarily use the software Scratch to build their games with and requires as little as an hour a week of voluntary work. They also have community meet ups of teachers at Coding Pub for the sharing of experiences and knowledge.

2. Overseas Work
My experience in this field is primarily in the US, so signing up with an agency will usually provide you with a place to work, live and learn at either a summer camp or a tech camp. The wages are usually very low but loyalty is rewarded over time for returnees. Even if the establishment you apply for doesn't feature a games design course, take the initiative and set one up yourself! It's definitely a life changing experience that I thought worth the cost and effort. I'm sure there are opportunities for similar work in other countries under similar programs.

3. Fire Tech
This is an example of one of these non-US programs. Fire Tech is a UK based summer program that runs a variety of classes in programming and robotics. They run for 6 weeks of the year and pay significantly higher than their US counterparts with the same benefits and without the cost or hassle of flights and Visas. But, whether you get the same cultural experience as working abroad with a variety of different people is debatable.

4. Teaching in Schools
This is an interesting one. Whilst the education system requires a qualification in order to teach in the UK, the recent choice to make programming compulsory in schools has opened up a gold rush of employment for those experienced in the field. Many current teachers are as new as the children to the software they are expected to teach, so those with the knowledge of programs such as Scratch and Stencylworks are welcomed with open arms. The opportunity to teach the teachers and even work as support staff for lessons is now an option for a way to make some income to supplement development costs or an entirely different career path altogether.

I hope that, like how Alistair inspired me, this might encourage some of you to consider learning programming and whilst doing so, helping others through the path of teaching. As always, I always love to hear what your comments are and experiences on the subject. If you have any questions, don't hesitate to get in contact.