OPINION: Learning to Code Isn't Enough
A learning scientist's attempt to temper the “learn to code” mania with a healthy dollop of reality
The 2020 Science report released in 2005 observed that science was changing in a subtle but fundamental way--from the use of computing to support scientific work, to integrating Computer Science (CS) concepts and tools into the very fabric of science. One only has to look at how data science played a role in the Obama win in 2012, or what movie-making has become today, to realize that the science of computing is changing the face of many fields in equally dramatic, if not quite as fundamental, ways.
Yet, a generation of middle and high school students moves forward without even a cultivated awareness of computational influences on diverse fields of human endeavor. Data from the Bureau of Labor Statistics about the growth of computing jobs magnifies this schism between opportunity and capacity. In high schools and college, misconceptions and sheer lack of awareness about computer science, as well as sub-optimal early introductory CS experiences exact a heavy enrollment toll. Exposure to computing in the K-12 ecosystem could remedy this malaise--provided it’s done right.
Articles promoting the idea of kids learning to code often point to how it helps build computational thinking skills--a key skill for all in the digital age, not only computer scientists. Seven years ago, Jeannette Wing’s hugely influential article, "Computational Thinking," argued that to reading, writing, and arithmetic, we should add computational thinking to every child’s analytical ability. The essence of computational thinking is in ‘thinking like a computer scientist’ when confronted with a problem. Among other things, this entails thinking logically and algorithmically--understanding not only notions of flow of control in a programmatic solution but also how to systematically break down a problem and then compose an algorithmic solution.
Block-based programming tools such as Scratch, Alice, Kodu, and web avenues like Khan Academy, Code Academy, and CodeHS (among others), place programming within easy reach of children today. Such tools are built on the “low floor, high ceiling” philosophy, which makes it easy for a beginner to build working programs. Scores of teachers working with elementary and middle school kids around the country, as well the massive Scratch community, will attest to the fact that even 9 and 10 year-olds who tinker in these environments create artifacts and animations literally within minutes of starting out.
Introductory exposure to coding in these environments is easy, hugely gratifying, and motivating. But how deeply do these children engage in computational thinking? The answer is, it depends. Wing underscored that computational thinking involves conceptualizing, not just coding and learning the syntax of a language, and it’s more about the ideas, not the artifacts. It is the thinking we employ to design solutions, not the end product or projects.
Decades of research with children suggests that young learners who may be programming don’t necessarily learn problem solving well, and many, in fact, struggle with algorithmic concepts especially if they are left to tinker in programming environments, or if the learning is not scaffolded and designed using the right problems and pedagogies.
Seymour Papert’s pioneering efforts in the 1980s around children, programming, and the development of procedural thinking skills through Logo programming inspired a large body of these research studies. This previous literature revealed the problems faced by children, and overwhelmingly called for a need to study the pedagogy of programming. Other research studies over the last 2-3 years (including one from the Scratch team at MIT Lab) suggest that tween and teen student projects may point to apparent fluency as evidenced by the computational concepts used in their projects. However, probing deeper sometimes reveals significant conceptual chasms in their understanding of the computing constructs that their programs employ.
My own experiences over the last decade engaging middle and high school students in numerous computational activities (from programming games and stories in Scratch to Robotics to mobile app programming using App Inventor, and currently as a middle school CS teacher as part of my doctoral research) have been that while children comfortably learn the WHAT (blocks or syntax) of programming languages and environments, the HOW and WHY is much harder as they construct programming solutions.
If the goal is to develop robust thinking skills while kids are being creative, collaborative, participatory and all that other good stuff, the focus of the learning needs to go beyond the tool, the syntax of a programming language and even the work products to the deeper thinking skills. While the fun features afforded by these programming environments make for great engagement, they often draw away focus to the artifacts, many of which employ relatively thin use of computational thinking.
Many online academies have mushroomed that focus mostly on a mechanical walk-through of the syntax of programming languages (just compare how programming is taught in CodeAcademy with the edX MIT 6.00x course).
This is not surprising at all. Algorithmic problem solving is not as easy as the “What schools don’t teach” Code.org video would have viewers believe.
The inadvertent peril posed by the “learn to code” mania and the cornucopia of websites advocated by avenues such as Code.org is that they may (unwisely) be equated to “CS education” for K-12 schools and educators lacking capacity and skills for teaching computing. While not so drastic, it is somewhat akin to confusing architecture with construction.
It also perpetuates the misconception that CS equals programming and that children should code for the sake of coding rather than giving due attention to other important reasons for why schools should want kids to program--to promote a way of thinking and problem solving, to use computing in intelligent ways in their future careers, and yes, possibly get excited about computer science as a discipline, and be primed for success should they choose to pursue CS.
Jane Margolis in her plenary address at a recent CS educators conference struck the same cautionary note as this article--that computing is greater than coding, and if we want to build the pipeline in CS or even help our children be better thinkers and problem-solvers, we need to broaden the scope of discourse from the narrow “learn to code” view.
Sure, getting all kids to dabble in coding will certainly be better than not, and the many “learn to code” online avenues and fun environments like Scratch and Alice provide access to kids who would otherwise never experience the joy and magic of programming. It is also an immensely powerful way to attract girls and underrepresented minorities to experiment, express and be creative. However, in touting coding as the end game, we are perhaps doing our children a disservice.
There is a shortage of coders in the nation, yes, but true innovation will come from those who understand and think about computing more deeply in disciplines beyond CS.
Not all coding experiences are equal, and what kids take away in terms of thinking and problem-solving skills depends on the depth of those experiences. It requires employing pedagogies and curricula that engage intentional thinking around solutions BEFORE any coding happens. Especially if these efforts are to be in service of “CS Education” in K-12, and aim to build a national workforce that can problem solve with computers (even if they're not computer scientists).
Thirty years of research suggests that that does not come as easy. It also provides guidance on how to do it right although there is more work to be done and is being done. Organizations such as the NSF are funding initiatives to support building CS curricula and teacher capacity to address these gaps. With the right intent and the right tools and pedagogies, we can help get our children there. Coding is a start--a cool, fun, worthwhile and exciting means to get started with computing. But it should not be mistaken for the end.
If the goal is to also provide exposure to deeper ideas in computing then it should be treated as such--a means--to that worthwhile end.