Features

Like many programming teachers at all levels of schooling, I found that only those students who were good at abstract thinking and verbal learning were thriving in my class. But was that an inescapable feature of the subject, or just a failing of my own teaching? This page will explain how I designed CodeMotion specifically to make programming accessible to a wider range of students.

But first, here is the feature list for the current version of CodeMotion:

Teaching with words

High school programming classes tend to be very unstructured. Often you will see a few students working alone on the assigned task, but others off working by themselves on some project of their own, while still others cruise around the room watching what everyone else is doing. The teacher may simply be sitting in the back grading papers and helping with the occasional problem.

When I first started teaching computer programming, I thought that surely I could improve on this. Being a competent programmer myself, I felt confident that I could teach concepts in a way that would be more engaging and understandable than a textbook. So, I decided to reserve some class time each day for lecture. This, of course, meant that the whole class had to move through the material at the same rate, and so I also introduced homework and tests to keep everyone on track. My intention was to teach computer programming in the same style as an ordinary academic class.

After the first year, it became clear that this approach was not working. I had greatly underestimated the importance of allowing students to experiment, make mistakes, and work through new ideas by working independently on the computers. I had mistakenly assumed that with a good enough lecture I could pull them up to a level of understanding that only comes through practice.

In the second year, giving more time for the student-computer interaction, I had somewhat more success. However, I still had a big problem: some very bright and highly motivated students were failing to grasp the basic ideas of programming. I went over and over those ideas in lectures and individual help, trying out several different analogies to clarify the concepts, but somehow the understanding was not being transmitted.

Teaching with models

Eventually I realized that the problem was not in the words I was using, but in the channel of communication I had chosen. In order to visualize what is going on inside the computer when a program runs, a programmer needs to be able to imagine the very abstract world inside the computer, a world that runs according to rules that are very dissimilar to our daily experience. I had assumed that I could transfer an understanding of those rules to a student by wrapping up an abstract idea in words and then waiting for those words to reassemble the idea inside the student's head. Unfortunately, most of my students were just ending up with a jumble of words and nothing else.

Personally, I am very comfortable extracting an abstract concept from a description in words. Reading a book is my preferred method of learning. Most successful programmers also tend to be people who learn in this way. But this learning style is not very common in the larger population, and so it is a problem when a subject is taught only in that way. My other class, physics, had relied on visual, concrete, hands-on learning, and this was probably why it had been successful with the same students who struggled in my programming class.

Some research has suggested that programming is an inherently abstract subject and that therefore concrete learners should simply be screened out of programming classes. However, I tend to think that if a large group of students are incapable of learning from your class, this indicates a deficiency in your teaching, not in the students. I decided to look for a way to teach programming that would follow the model of my physics class, allowing students to gradually grasp the underlying ideas by experimenting with concrete models.

Making programming concrete

Some beginner programming environments try to make programming more concrete by changing the content the program deals with, using shapes and lines, turtles, or storybook characters instead of text and numbers. Others try to change the form the program is expressed in. One popular approach is to represent the commands with blocks that can be snapped together, eliminating the errors associated with typing in text. These approaches make programming less intimidating, and allow a student to quickly write a simple "nouns and verbs" program. However, they have had no real success when it comes to teaching the new concepts unique to programming. Learning these concepts, it seems, is difficult no matter what form they are wrapped in.

CodeMotion takes a much different approach. Rather than trying to mask the complexity of real programming, it presents the student with a simple but accurate model of how the program really works. As a program is running, the student can watch a visual display that approximates how an expert programmer would imagine that program's behavior. This give a concrete meaning to the abstract ideas, so that the student can start from seeing how specific programs run and gradually internalize the rules that those programs follow.

So, for example, once students progress beyond programs that are a simple sequence of commands, they typically want to make their programs respond to input from the mouse and keyboard. The way to do this is to write a certain procedure for the computer to follow for each particular input event that might happen - for example, pressing the mouse or hitting a key. This is a big leap for students to make, because suddenly, instead of writing a single set of instructions that just runs once, they are writing a lot of small programs that somehow have to work together coherently.

Things get even more complicated when the student wants their program to do something at the particular place where the user clicked. Since there is no way to know in advance where that will be, the program has to receive information about the mouse position and store it in a "variable" that can be used within the program in the place of a predetermined point.

A textbook or teacher will try to describe how this works using analogies - the procedure is like a technique in karate that the computer has learned to respond to a particular action of the user, and the variable is like a container that holds some value and from which you can retrieve that value whenever you need to use it. In this way, we try to directly build up the student's ability to imagine how a program runs.

With CodeMotion, a student can directly observe events being listed as they happen and then being expanded out to show the instructions contained in that procedure. They can see how the mouse location is kept inside a variable as that procedure runs, and they can see that a reference to that variable name in the program is replaced with the value currently in that variable. Starting out with a few very simple examples of this type of behavior, they can gradually build up a solid understanding of how procedures and variables work.

In the first workshop I taught with CodeMotion, one of my students reached this point in the program, ran a demo, tried clicking in a few different places, and then said, "Oh, I get it now - that 'p' isn't talking about a particular point; it's like a bucket that holds whatever point the mouse was at." For the first time in my programming classes, a student had been empowered to draw the right conclusion by experimentation and observation, rather than needing the right interpretation to be forced on them by the teacher.

Structuring the learning

Although treating programming like an academic class was a failure, I still believe that I was correct in wanting to introduce structure. Beginning programmers tend to spend a lot of time and frustration struggling trying to accomplish a complex task, such as writing a 3D game, without first learning the fundamentals. This is why I benefitted greatly from textbooks that scaffolded that learning process, introducing the basic concepts first and then gradually moving on to the more difficult areas.

In designing CodeMotion, I wanted to provide some guidance for how students move through the material, while still allowing independent, self-paced learning. My solution was to design exercises which can be corrected by the computer, so that the student gets feedback on what they did wrong and can efficiently arrive at a solution. The computer requires the student to demonstrate mastery of each topic before moving on to the next. This system still allows the student freedom in which exercises they choose to do, since more exercises are offered than are required to move on.

There is also a system to allow students to choose which topics they tackle in which order. In strategy games, there is often a complex "tech tree" describing how accomplishing one thing might make other things possible. For example, in order to build a knight I might need to build both a barracks and a stable, and building the stable might require already having a blacksmith. Each unit in CodeMotion has a similar "tech tree" that shows which topics become available as students master other topics.

Because the computer can set assignments properly paced for each student, and then check their work on those assignments, it is theoretically possible for a student to learn programming through CodeMotion entirely on their own. Of course, for most students it will always be easier and more motivating to learn in a class with a passionate teacher and a group of peers who are studying the same thing. In this environment, the power of CodeMotion is that it frees up the teacher to be moving around helping individual students rather than needing to run the whole class.