Things we learned teaching children to code in 2014
This year a friend and I set up a Community Interest Company (a UK version of a not-for-profit and non-governmental-organisation) to introduce creative programming to young people aged 8 to 18, especially girls and those who are hard to reach, such as young carers.
At the moment we’re running two primary school aged clubs (for 8 to 11 year olds), and two secondary aged clubs (for 11–16) — which covers around 100 students in total. In January we start one new secondary club, and two college courses (for 16+).
There are a bunch of reasons I believe why fewer and fewer (and it is fewer) students are studying computer science, especially girls — which I’ll probably write about in another story. The thing that matters more is what we’re doing about it — and how we’re trying to make the whole process more enjoyable.
One of the biggest aims in establishing our own CIC was to research and learn how to teach students better — it seems that the act of teaching programming hasn’t really changed over the past 50 years, and nobody has really looked into who “target audience is” or the children are who actually should learn computing.
So here’s what we learned over 2014.
Relatability
Kids are *constantly* using technology — smartphones, tablets, computers etc. Why are most schools in the UK teaching Python? Most children don’t know what Python is or where it’s used. Why aren’t we teaching kids how to make mobile apps or web development — things they actually use regularly and know about already?
We began our Autumn term by teaching the secondary aged students how to create their own emojis using SVG and it went down a really well— we have nearly four times the number of regular girls attending our club. SVG uses XML so students had to learn about tags and attributes, which are the basic building blocks of creating your own website, which is what we’re aiming for.
Constructionism
Enabling students to build their own things has always been one of our main aims — instead of creating “tests” for our students to pass we’re enabling them (or will enable them as soon as they turn 13 thanks to COPPA) to create their own digital portfolio of work. However we did learn that students engaged a lot more with our material if we could allow them to see results of their work almost instantly.
Thanks to the wonders of tools like JSFiddle; the need to set up a basic web page is gone and students can go straight into writing the fun code where they can see their work online at the press of the“run” button. Most students we taught ended up with a basic emoji during the first 10 minutes of writing code, and had made it entirely their own by the end of the hour.
JSFiddle also has the benefit of giving students their very own unique URL so they can show off their work to friends and family (and thanks to relatability they also somewhat understand the work their friend has done).
Simplicity
This could probably be split into two separate sections; simplifying *what* you’re asking the students to do, and simplifying *how* you’re asking the students to do it.
Firstly the “what” — we give our students only as much code as we think they can handle — usually this is usually only one or two lines which they can play around with for example drawing a circle and playing with the cx, cy, or fill attributes. Not endless “copying this paragraph of code” (which they don’t understand) into a line in their project (that they also probably don’t understand).
Secondly the “how” — students just will not follow a long list of instructions — they’ll get bored or distracted or want to do something entirely different. Typically teachers will print out an A4 worksheet for students to work through each of the steps presented — I learned at University that “chunking” the information into groups of steps students had to progress through worked a lot better — students weren’t then so intimidated by what they thought would be hard work.
This is actually a lot harder to do in reality because there’s no real tool to distribute worksheet content and some code. We tried for a while to use GitHub’s gist but that ended up being hard to chop our worksheets up into manageable chunks for the students. So we had to cobble together our own system which still uses gists — but allows us to present them in an organised manner. You can take a look our emoji worksheets here.
Creativity
We know students like being creative, that’s why there was almost 11 times more A-Level Art students than there was Computing in 2014 (and of those 75% of the Art students were female vs the 7% in Computing).
With our emoji work students get shown literally three lines of code to make the piece of paper, a circle, and a polygon — what they did with it was entirely up to them. Instead of regular code lessons where students get walked through how to build a specific system, and every student ends up with exactly the same project.
Every single one of our students came up with an amazingly different emoji idea— we’ve had a pea with a hat, a rainbow man with a moustache, and an emoji that gradually throws up sick, to name but a few. One of these days I’ll build a gallery to showcase every students emoji (or even better I’ll get a student to build it for us…).
Conclusion
My co-founder often talks about what we’re doing like we’re building software go-carts. Children build go-carts to learn about physics and the features of vehicles. If you put a child in a Audi, they flick switches, make brrring noises and turn the radio up very loud. Very annoying to the parents, dangerous to your expensive car, and provide very little learning experience.
An Audi is far too complex for children to relate to whereas a go-cart allow children to interact with the world in an immediate, visceral way, demonstrating and experimenting with immutable physical laws. All the while having fun and excitement, and learning the limitation of imagination applied to physical reality.
Building software go-carts from a blank sheet of paper allows children to interact with world in an immediate, abstract way, demonstrating and experimenting with the immutable mathematical and design rules. All the while having fun and excitement, and learning the limitation of imagination applied to technological reality.
We desperately need more people willing to help young people learn to code in a way that is more enjoyable for the students. We hope that you find what we learned useful in some small way.
Written by Danielle Emma Vass — www.de-velopment.com
Twitter — @de_velopment
GitHub — @daniellevass
