Coding in the service of learning

In a recent blog post by @MatthewOldridge, he questions the ‘whys’ of learning to code. And rightly so, I think. If you are at all following educational trends, you are probably aware that people are seriously discussing the merits of coding/programming in terms of a new literacy. For example, you have probably seen all or part of this video:

On the day I posted this, the video has nearly twelve million views. Unfortunately, I think the video’s message veers off course at times—it often sounds more like a sales pitch than an impassioned plea for educational reform.  But this is not the first time this topic has been discussed.  Probably the most significant initial examination of the interplay between programming and learning was presented by Seymour Papert in his book Mindstorms: Computers, Children and Powerful Ideas. I think this book is a doorway, at least, it was for me. Before reading it, I thought one way about how technology can influence learning.  After reading it, I began thinking in a new way. Even though it was published in 1980, I think its message is still powerful today. (Papert’s construct, the microworld, was also the topic of my thesis.)

Critique of the video

So, on one hand, the video’s message is absolutely correct.  Learning to program can be rewarding and lead to a job, or, at least, a skill with which you can earn money… much like being a lifeguard can earn you money.  For me, it was a great summer job when I was in university.  And it can be a great career, too.  But it’s not for everybody. I definitely support the notion that all children take swimming lessons and learn to swim.  But, not all children who learn to swim will become lifeguards.  I would definitely support the notion that all children explore coding (in the service of learning). But, not all children who learn to code will become professional programmers.  Nor should they. This is where the notion in the video, and the resulting ‘coding bandwagon’ in education, are a little out of whack. Everyone does not need to learn to code to a high degree (i.e., programming).  You can be technologically literate but not know how to write a computer program.  I know many people who know how to use a variety of digital devices, and understand how they interact, they know how the web works, how email works, how to buy and print movie tickets online, how to take pictures or record a video on their device, how to tweet, how to leave a comment on a blog… You are probably one of the millions of people who know how to do all of these things and that makes you literate in today’s digital society. I rarely see ‘coding’ or ‘programming’ listed in frameworks of modern educational objectives or in so-called ‘21st century learning’ frameworks (e.g., here, here, & here).

My experience with coding

I grew up in the late 70s, during the dawn of personal computers.  The early computers were text-based, digital marvels that did absolutely nothing until you programmed them to do something.  I remember going into stores and playing around on them and trying out little programs to see how (or if) they would work. They were quite simple:

Rather inane but fun to play around with. Anyway, I learned how to code by talking and learning from people I met in the stores who were also interested in programming languages. This became a sort of social network, but F2F… After two years of formal computer programming courses in grade 11 and 12, I discovered that I had developed a ‘real’ skill. At the time, I decided to myself that it was the first real skill that my work in school provided me with (forgetting about reading, writing, algebra, and the hundreds of other skills I learned in school). Nevertheless, I took no small satisfaction in the knowledge that any process I could work out with a paper and pencil I could translate into a computer program that did exactly the same thing. One of the later benefits of this skill was that I was contracted one summer to write a carpet tufting simulation program so that samples of carpet tufting designs could be created on the computer screen as a preview before being made by the machine. The money I earned from writing that program paid all of my university costs for a year.

An example of codified thought

I think coding and programming tasks in schools certainly have value so long as they are a means to an end. Programming projects are especially useful because they seek to solve a problem or provide an application that automates or simplifies a task. Programming is the concrete explication of abstract ideas and processes. I think that most programmers are very familiar with this concept. Ideas and processes, that begin as a purely cognitive conception, become concrete and real when translated into a computer programming language.  Once codified, they can be applied by anyone using the software.

Years ago, while writing a datebook program (similar in functionality to a calendar app that stores events), I needed a function early on to determine if a given year was a leap year or not.  Working it out on a piece of paper, I could describe the process like this:

I knew exactly what to do mathematically and ‘procedurally’ to find out if a given year needed Feb 29 or not. The next step was to translate this process into code that the computer could understand.  In programming parlance, I had to define a new function in my program in which I could submit any year I wanted to, and the function would reply with a 1 (yes) or a 0 (no) regarding the existence of Feb 29 that year.  Here is the function I wrote:

(The ‘mod’ part in this code stands for modulo which means:  apply a division operation on two integers and then only retain the remainder portion.  If the modulo equals zero, it means the dividend divides evenly by the divisor.)  The middle three lines beginning with the word ‘if’ are the codified versions (in Borland Turbo Basic) of the three English sentences describing my process.  The other bits of the code tell my program that I am defining a new function and gives it a name (fnLeap%) so that I can use I wherever I want to in my program. In Java, this might look like this (although my Java is rusty; correct me if I am wrong):

And in Scratch it might look like this:

What about a real classroom example?

Regarding Matthew’s question of the ‘why’ of coding – what follows is an example of students who use coding to learn and gain a deeper understanding of a concept. In the example below, I wanted to use the conceptual change model to challenge my grade 6 students’ understanding of polygons. My students had played with Scratch long enough that they had a good understanding of how to move Scratch the cat around on the stage using the Motion blocks.  They also knew how to use the Pen blocks so that Scratch drew a line as he moved on the stage. My students had become adept at both describing, in mathematical terms, the attributes of polygons, and at constructing polygons using a variety of pencil and paper tools.  However, I noticed anecdotally that a variety of minor misconceptions were apparent pertaining to angles, such as reflex angles, the relation between 360° and 0°, and relative angular measurements. My students were able to construct various polygons and angles specified in the Ontario math curriculum but, if challenged to transfer those skills and their understanding to a different domain, my guess was that some degree conceptual confusion would result.  So I decided to create a programming task using Scratch which utilized the conceptual change model. Learning objectives were as follows (taken directly from the mathematics curriculum):

• classify and construct polygons and angles
• construct polygons using a variety of tools, given angle and side measurements
• measure and construct angles using a protractor, and classify them as acute, right, obtuse, straight angles, or reflex

First, using concept mapping software that the students already had experience using (SMART Ideas), students created a flowchart that outlined the steps for constructing an equilateral triangle using pencil, paper, ruler and protractor.  I wanted the flowchart to act as a learning artifact that students could use in a later reflection. Next, I told my students that they would be using Scratch to draw their triangle on the stage.  Before beginning the activity, they were asked to predict what, if any, changes would need to be made to their existing flowchart for drawing it on paper.  Students made a duplicate flowchart and then made modifications as required from their predictions. Students were challenged to create a program that results in Scratch the cat moving in such a way as to draw an equilateral triangle of any size on the stage. At this point, I paid very careful attention to students’ activities because it would be at this time they would potentially face cognitive conflicts.  For example, because Scratch the cat rotates relative to his current position (rather than relative to a line just drawn), the supplementary angle for 60° must be used (120°) in this case in order to tell Scratch how to draw an equilateral triangle.  Students worked with partners but each had to write their own code.  They discussed and helped each other, and I was also engaged in coaching and suggesting ideas as required. Here are two Scratch coding examples that result in an equilateral triangle:

Once the students successfully created the triangle, they examined their prediction flowcharts and directly compare it to the program they have just written that successfully moved Scratch the cat in the shape of an equilateral triangle. Students spent time discussing with their partners the differences between their predictions and the code that produced the triangle (the conceptual conflict) and together they had to work out exactly why they were different and what was going on in Scratch’s world as opposed to their pencil and paper world.  In so doing, the depth of their conceptual understanding of constructing polygons grew.  This whole process was repeated for other polygons such as squares, hexagons and octagons. I think that the greatest thing about computer programming in the service of learning is that both the student and the teacher can see thoughts on the screen. Not finished, perfectly formed, organized thoughts… but constantly changing, experimental, incremental thoughts that changed in the way they were arranged second by second… Programming provides a concrete way to discuss and share these thoughts.  In the example above, creating the program in Scratch acted an ‘object to think with’ (albeit a virtual one) for each student trying to accomplish a simple task: instructing Scratch to move in such a way so that he would draw an equilateral triangle.

Final thoughts – coding vs. programming vs. software development

I think that a distinction has not been properly drawn between coding and programming, or between programming and software development, in the current discussions of ‘all students need to learn to code.’ I hinted at a distinction in my post above but I want to make it more explicit now. There are many frameworks that attempt to define levels of computer programming competence; I still like Pea and Kurland’s from 1984 (starting on page 152, the levels are fully explained; the parenthetical explanations are my summaries of their descriptions):

• Level I – Program User (adept at using someone else’s code for its intended purpose or modifying it for a new purpose)
• Level II – Code generator (adept at writing original, short code pieces that accomplish a simple task)
• Level III – Program generator (adept at writing interconnected code – a program – to accomplish a complex task; not necessarily user friendly)
• Level IV – Software developer (adept at writing commercially valuable and usable code that is easy to use for large numbers of end users)

Without going into too much detail, my students (see the example above) who could use the Scratch environment were operating at Level II – they could write small snippets of code; single purpose mini-programs that accomplished one task. Yes, my students could code.  But I would not describe them as programmers.  And not anything close to software developers. Yet, at Level II, my students were writing code in the service of learning.  Code was not being written so that they could later become programmers or software developers. Code was being written so that they could see their own thought processes on the screen and be able to reach out and move them around and organize them in such a way that reflected their understanding of a concept.  Some students might enjoy this challenge so much that they will be motivated to develop their abilities further towards Levels III and IV.