Coding for success
Photo: Science Photo Library
The Kernel’s developer columnist Andy Young takes a nostalgic look back at computer science education and makes a passionate case for upgrading kids’ skills today.
Hoxton, we have a problem. Much has been written about how we need to improve the way we educate our children about technology. This is all great, but it’s not enough.
We need to teach our kids to code. All of them. This should be compulsory education, a core pillar of modern schooling. Many people are worried about a shortage of trained programmers, but this misses a wider issue – one of the biggest modern threats to our individual and collective success. They will thank us for it, and curse us if we don’t. Stick with me, because I want to show you why.
This is a timely topic – Google’s Eric Schmidt’s comments on the state of computer science education in the UK last autumn were nothing short of damning. Here in the UK, it is hard to argue that computer science education is remotely adequate for industry needs – try telling that to anyone who has tried to hire developers in the past three years. Sure, much great talent is out there – but the supply and demand balance is off the scale.
The announcement that the UK’s broken ICT curriculum is finally to be replaced by a computer science programme developed with input from academia and industry offers hope, even if this is a work in progress. This sounds great, but it would be rather shortsighted to pigeonhole the issue as simply one of training sufficient professional developers to meet an industry need.
I believe that we should be teaching all our kids to code – every single one, to the ultimate benefit of each of them, their lives and whatever jobs they come to do. But first, we need to tackle an overarching problem – “normal people” simply don’t understand what it means to be able to code.
Misunderstood programmers
The other week I attended a talk by Lean Startup messiah Eric Ries. During Q&A someone requested that, while his principles sounded great, did Eric have any tips for how to apply them in an environment where it was difficult to get the programmers to take notice? After Eric’s response, the audience member suggested that Eric write another version of the book “especially for programmers”.
Wait, what? Eric is a programmer by trade. The ideas around lean startup arose from his personal experiences writing code. The book contains numerous examples of how to avoid wasting time writing code nobody will use – genuinely a programmer’s pet hate. For funk’s sake, he’s already written a version of the book for programmers – it’s the same darn book! Programmers understand the same language as the rest of us, believe it or not…
So give the guy with the question a round of applause – and quietly revoke his licence to ever work with a tech team again. But minutes later, another question with a similar theme – it’s clear, many people simply don’t understand programmers. And it’s not just a lack of understanding – somehow some kind of mysterious aura has arisen around the dark art of programming, a wondrous craft desired by many but conquered by few.
In order to truly understand how and why we should teach our kids to code, we really need to understand and appreciate what being able to code is all about.
Learning to win at life
The computer stands with the greatest developments in modern humanity (and has made many of the other great developments possible). Let’s not just brush over such a crass truism, though – what do we mean by this, exactly?
Computers are tools for automation – fundamentally of calculation (“computation”) but which can be applied to endless tasks, once we factor in the multitude of peripherals and interfaces now available. Computers help us automate and repeat the many complicated steps that make up the search for the answer to some of our hardest problems: whether that’s a biologist attempting to model a genome or an office administrator tasked with searching an endless archive of data.
The use of tools is a big part of what make us human, and the computer is humanity’s most powerful tool. When David beat Goliath or when today’s researcher makes a breakthrough, it’s the tools that help us win. In offices and homes the world over, each and every one of us at some point undertakes tasks of a repetitive, tedious or complicated nature, tasks that could, are or eventually will be automated or eased by computer. The computer makes us more efficient, and enables and empowers us to achieve far more than we ever could otherwise.
Yet the majority of us are entirely dependent on a select few, to enable us to achieve what we want. Programming is the act of giving computers instructions to perform. This is true whether the output is your word processor, central heating or aircraft control system. If you can’t code, you are forced to rely on those that can to ensure that you can benefit from the greatest tool at your disposal. Whether it’s an app for your phone or a nuclear power station, it seems as if there’s some freaky class divide developing between those who can code versus those that can barely figure out their Facebook privacy settings.
Who can shy away from the attractiveness of giving instructions and having things done on your behalf? The ability to code is what brings the power of computing to the masses. We need to break away from a culture where we consider people to be “technical” or “non-technical” – not everyone takes to literature or eloquent composition of prose, but we need to attack the phenomenon of the “non-technical” in the same way that we tackle illiteracy.
Coding is not engineering
Many people may disagree that learning to code is for all or should be compulsory. “Why bother?” they may say – “We don’t need that many coders, most wouldn’t use the skills – it’s not that useful.” But it’s critical to understand what learning to code is not. Learning to code is not learning C++, or Ruby, or HTML. Learning to code is not learning architecture, or security, or memory allocation. Learning to code is not training to be a professional programmer.
Learning to code is learning to use logic and reason, and express your intent in a consistent, understandable, repeatable way. Learning to code is learning to get under the skin of a problem and reduce it to it’s simplest form. Learning to code is learning to harness power external to yourself and provide instructions to realise your ideas – whether that be directly to a computer, to delegate to one or more professional programmers or even a human team that work for and with you in any dicipline. Learning to code is ultimately a fantastic way to gain a multitude of transferrable skills.
Education start-up Codecademy deserves high praise for its success signing up over 350,000 people to learn to code this year through their Code Year initiative, even New York mayor Michael Bloomberg. The problem I have with Codecademy is that their definition of “learning to code” appears to be “learning to become fluent in the syntax and functionality of a programming language” (in their case, Javascript). This is the equivalent of learning history by memorising dates and events – you will come away feeling you’ve learnt everything but understood nothing. A friend who signed up told me “I’ve done the first two lessons and it was painful – it’s not for me at all, but I’m determined to do it anyway!” – sadly it seems they are not the only one.
Contrast this with the fantastic website/service If This Then That (Ifttt). While on the face of it is entirely unrelated to the mission of teaching people to code, the tagline sums it up – “put the internet to work for you”. The service enables anyone to use a simple interface to set up rules such as “if I upload a photo to my Instagram account then save a copy to my Dropbox”, all based on the simple conditional statement – one of the foundational pillars of programming. This type of meaningful result is exactly what a basic ability to code is all about – it would be fantastic to see an educational service such as Codecademy based on such real-world principles.
Learning to code is not necessarily developing the ability to code a solution to any problem from scratch. On the contrary, the best way to teach someone to code is within a meaningful context, where they are given an existing solution and guided how to alter and customise it to their preferences or requirements, as often required in the “real world”. Learning to code is learning not to be afraid of experimentation and developing a basic understanding of concepts that allow you to take things and tweak them to fit your needs. With a little bit of code it is possible to achieve everyday things like mail-merges using Gmail and Google Docsor configure Outlook to automatically save email attachments to a folder – all that is required is a rudimentary understanding and confidence in following the instructions.
The halo effect
I shall be eternally grateful to my late grandfather, who tutored me at maths to GCSE. I vividly remember him introducing me to the concept of prime numbers when I was about nine – we turned to the computer and he guided me through the construction of a simple program that calculated primes and printed them out, initially to the screen, then to the dot-matrix printer after we filled the screen. The output came in real-time, quickly slowing to one every few seconds, then minutes, until we left the program running overnight and returned the next day.
This seems totally bizarre – how many people have a vivid memory of learning about prime numbers, of all fascinating subjects? But not only did the experience bring the tedious subject to life and cement my understanding, we quickly moved on to concepts of density and predictions as to how many numbers the computer would “find” within a certain range. Of course it’s not critical that all students perfect the ability to produce such programs themselves – there is a huge benefit in bringing a theoretical concept to life in a practical way. Code is simply the tool for automating the boring stuff.
This is of course the point: although it’s based on theoretical principles, syntax and conventions, coding is inherently a practical activity. Far from being boring, applied coding is an incredibly creative process, one that provides a healthy challenge and rewards with a great sense of achievement. This is how it should be taught: make it social, make it inspiring, make it fun. Let students create things that actually work and can be used. Teach people examples in practical settings – let them build logic gates for train sets, loops for alarm clocks, sensory feedback for toys and games.
Not every kid will become a programming genius. Not every kid will enjoy the experience, nor find that coding is “for them”. But not every kid with a football goes on to play in the Premier League. Sport in schools is not (solely) to produce professional athletes. For the vast majority it is simply the path to some fun and a healthy lifestyle. It is the same with code – a better understanding of technology, exercise in logical thought, the feeling of empowerment and lack of fear to fix our own problems will help each and every one of us – while simultaneously addressing the talent drought of the tech industry.
The next generation
So it’s not about training the next generation of programmers. But equally, of course, it is. Hiring great programmers is tough. There simply aren’t enough to go around. We need more talented coders, and we need to start them young.
The great seller of books Malcolm Gladwell gets on my nerves. But near the beginning of his book Outliers, he uses the case study of Bill Gates to illustrate how Gates’ success arose from relatively unique circumstances. Gladwell observes a number of factors. Gates grew up just as the personal computer was coming of age. The school he attended give him unusual levels of access to the computer lab, and so on. Gladwell’s 10,000 hours of practice “required” to achieve extreme proficiency may be a catchy number (and correctly credited to a certain K Anders Ericsson), but regardless of the magical theories, we can all agree that in principle practice causes improvement.
Let me tell a little Gladwellian story myself. I believe it’s fair to assume I can code ok. I had my first experience with programming aged seven. I’ve certainly had my 10,000 hours, if not twice over. But when I began my BA in Computer Science at Oxford University, just four people in the class had prior coding experience. Not that this itself is particularly something to worry about, partly since the faculty consciously aims to select those with highest potential for learning and places almost no weight on existing ability to code. Incidentally I don’t even hold the belief that a university degree in computer science is remotely necessary in becoming an accomplished programmer (I believe university is a thoroughly good option for most people for other, non-academic reasons, but that’s another story).
More to the point, if we expect the majority of kids to wait until 18 to begin with three years learning the core concepts of computing at university, even if this gives them a solid grounding from which to subsequently pick things up quickly on the job thereafter – how on earth do we expect anyone to get their 10,000 hours of accomplishment in before they reach their 30s?
From Gates to Mozart, the majority of the greats throughout history have been recognised for their accomplishments by their early 20s. Whether this is a reflection on the speed at which the young mind is open to learning, or the external pressures on adult life is hardly relevant. When we have a system that essentially relies on the fact that the top performers in an industry will necessarily have bypassed our formal education system, we know we have a huge problem on hands.
It’s no wonder we find it hard to hire – we need more coders starting young.
It wasn’t always this way
Looking back, the history of coding education in the UK is fascinating. Few seem to realise that things weren’t always this way. Historically the UK has been at the forefront of computer science, from Alan Turing’s 1936 paper “On computational numbers” to Tim Berners-Lee’s invention of the web. Even while dismissing our current sorry state of affairs, Schmidt himself praised the British computing education of the ’80s.
When the first home computers arrived in the early 1980s, they were extremely limited in functionality. It is easy to forget now, but typically, when you turned them on you, were greeted by a blank screen with flashing cursor. The default state of the computer was to wait for instructions in a simple programming language such asBASIC. To use any pre-supplied software required loading it in from floppy disk or – even – cassette tape.
At this time there was clearly a need for instructional guides and educational materials to help people use the things. What’s interesting is that it was taken for granted that this was be something kids would be interested in too. A plethora of publications was released aimed at children of all ages, supported by cartoons and illustrations. I can still remember my first steps with the “Introduction to computer programming” published by Usborne in 1982 – check out the proud proclamation on the front cover: “No computer needed”! Anyone doubting the appropriateness of computer science for kids should acquaint themselves with the 1985 Simon Seymour book “How to talk to your Computer” – summary: “Ages 5 to 9. This book focuses on the “step-by-step” nature of programming. Teaches BASIC, line numbers, PRINT, and END. Also teaches Logo, showing how to draw a square.”
So what went wrong? This first wave of quality computer education was not driven by government or educational policy – it came from a genuine interest in the new technology. A generation of Gateses grew up alongside the computer, understanding and conquering it naturally. As the technology developed, graphical interfaces and games consoles reduced the barriers and removed the challenges, and the original incentive to learn disappeared as naturally as it arrived. We took for granted a generation that had developed into talented enthusiasts through their natural interactions with computers. Ironically it was the improvements we made that removed the need to understand how computers work. This unplanned but hugely valuable spike of expert, natural programmers was over as quickly as it arrived.
It’s not just the kids who have been dumbed down when it comes to understanding computers – when the machines first appeared in homes and offices in the ’80s and ’90s people embraced the now laughably cumbersome and technical interfaces as the cutting edge – tools that revolutionised their efficiency and abilities. A self-employed chartered surveyor, my father had an early personal computer to prepare his reports – the quaintly named Amstrad PCW (“Personal Computer Word Processor”) 8256. This was before the days of graphical displays and the luxuries of WYSIWYG point and click editing: the screen had 25 rows and 80 columns for glowing green text against the black background. “In 10 minutes, it changed my life” – check out Alan’s marketing, aimed at secretaries – hardly the nerds! (picture credit)
My mother – who had secretarial training but was most definitely non-technical – used to apply basic formatting to dad’s reports by enclosing headings within special tags such as <center> for alignment and <b> for bold. Twenty one years later, what used to be the most rudimentary of secretarial skills remains as the core of HTML – the language of the web – and Fast Company sends a reporter to discover whether it’s possible for a “non-nerd” to learn this mysterious dark art. It’s frankly depressing.
Are advances in technology making us dumber? I find that hard to accept – we’ve spent the entire history of our humanity improving technology, and it seems difficult to believe our prehistoric or medieval ancestors were smarter than us. However it certainly seems plausible that within the last 10 years advancements in modern computing – with all the associated conveniences – have accidentally lured us into some sort of “local minimum”. Reasonably fresh from my university artificial intelligence lectures I’m not counting on bowing to our new silicon overlords anytime soon, but it seems certain we’ve been inadvertently drawn away from fully harnessing the power of or latest and greatest advances.
Room for improvement
Today there’s certainly no shortage of projects and initiatives to help kids learn to code in various ways and forms. Some are from big players like Microsoft, whose Imagine Cup - a yearly global coding and technology competition – last year attracted 358,000 students aged 16 and over from around the globe. At the grassroots end of the scale there are a number of schemes such as CoderDojo, which was started by young Irish iPod hacker James Whelton in his school last year, and has since spread to a number of locations around Ireland, London and San Francisco.
With a more entrepreneurial twist, UK charity Apps for Good aims to inspire young people in secondary education to use technology to tackle problems for social good. The programme rolled out across 40 schools across England in 2011 and has exciting aims to substantially increase its reach in 2012. Separately, services such as Codecademy and Treehouse demonstrate the latest in online learning techniques, but still have have some way to go. Certainly there are more resources available today through the internet than ever before. But somehow it’s hard to compare with those engaging books of the 1980s – I can’t help reflecting that nobody will give a URL as a birthday present.
So somewhat ironically, after 25 years of innovation of the personal computer, we are now going back to basics to figure out afresh how to teach our new generation. I disagree with Josh March in that we don’t need to use overly dumbed down languages – kids are smart, let them loose and see what they come up with. We need to remember that the point is not to produce half a million kids who know Javascript, Ruby or any particular technology.
Rather, a thorough grounding in logic, reason and problem-solving – coupled with the empowerment and inspiration that being able to harness technology to our personal advantage brings – will result in a smarter workforce, more engineers, innovators and managers that better understand technology, and a better quality of life for all.
So let’s teach the kids to code. All of them. Did I say that already? It’s really not that hard.