Blog Post

10. This is not a programming class

10. This is not a programming class

Note: This post is part of The Pedagogy Project on HASTAC.

Programming is one of those areas that, like physics or mathematics or chemistry, comes with a lot of baggage attached to it. Before they even write their first line of code, most students will have already determined whether or not they are going to be any good at it based on little more than how they self-identify. If they are a logic-type, they must be good at it; if they are a feeling-type, they must be bad at it.

What if they're both?

One of the basic assumptions of the UMaine New Media program I've taught in for the last few years is that the students in it need to be capable in all areas from conceptualization of disruptive systems to aesthetic design to technical implementation. Students in this program are constantly faced with learning things that are well outside their comfort zone. Since so many of them self-identify as artists of some sort, the area that consistently generates the most fear is programming.

The problem with addressing their fear is that it's not completely unfounded. Not because of some intrinsic property that makes people empathetic or logical, but simply because programming languages – like spoken languages – are built from the perspective of a certain ontological view of the world around us. The mental tools of analysis that go into using code ontologies are not the ones that students I've seen who self-identify as artists have developed. But they aren't that far off. Teaching the ontology of code before teaching its syntax has helped many of my students who didn't believe they could learn to program get over that belief and succeed at it.

Art-minded students can usually be set on the right track with one image:



Though I generally expand it out a bit further to make a point of what we're doing:



This is not a programming class. This is applied ontology.

Changing a mindset is not a problem to be solved with a single assignment. I usually start the semester by asking students to describe an object in such a way that its functionality could be reproduced from just the description. Something that is visually mechanical works best; I like to use an apple peeler.



The first try usually demonstrates the difference between English and Code worldviews. If I ask what an apple peeler is made of, the first answer tends to be metal or plastic. That's an entirely reasonable answer, but not one that is useful for modeling its functionality. From a code perspective, an apple peeler is made of several subobjects – a threaded rod, a crank, skewers, various blades and springs, etc. that all interact. What a thing is is synonymous with what it does within the scope of the system you're looking at and how it interacts with the other parts.

Once they've started to see objects as a functional group of parts, then they can move on to abstracting those pieces into properties, interactions, and contexts. An apple peeler might peel apples but it might also be used to wind a coil, so each object can only be defined in a specific context. Within that context some things might be relevant and others might not be: the color of an apple peeler doesn't change how well it peels apples, but the speed you turn the crank at probably does.

There are more steps involved, like the idea that creating a model means abstraction ("color" is a good property to track, "red" is not) and learning to write instructions without any unresolved external references. But the key point that I've found in my classes is that learning the mindset before jumping into syntax is far more effective with students who are afraid of programming than starting with "hello world!" and eventually getting around to objects.*

Learning syntax without understanding the context in which it will ultimately be used triggers frustration and fear. There is little or no code written for the first three weeks of my introductory programming classes, but when that time is spent on explicitly teaching programming ontology the students end the semester far ahead of where they were when I started with the traditional "hello world" and variables. Reports from faculty in follow-up classes indicate that they retain what they learned better as well. And, most importantly, a start where they are learning without frustration keeps the students who come in believing they can't learn to program from giving up and proving themselves right.


* Yes, this is written from the perspective of teaching object-oriented languages. YMMV with other languages.



Your description of learning the context of object-oriented programming was one of the breakthroughs I had almost two decades ago when learning how to program. I had spent years learning how to do "spaghetti code" but really didn't understand how functions related to one another.

One day, an older friend of mine finally explained coding to me in the terms of Mario Kart: think about the characters/cars you can choose. There are certain things alike with each of them, but what's different? On a napkin, he sketched out the different components to consider and told me "Programmers are either efficient or lazy...or both. They don't want to type the same code repeatedly. Functions allow all the components to interact and be self-contained all at once." As soon as programming was explained to me this way, a whole new world opened up. Finally, I could "see" what OOP could accomplish.

I wonder for your class, do you include a non-programming assignment where the students break down another object (maybe one of their own choosing) ontologically? Perhaps by mapping out the different functions and how they relate (or don't, such as color in your example)? I'm curious if doing another assignment either individually or as part of a group will reinforce the idea you presented to the group, and help identify students who are still struggling/need extra clarification.


Well, what can't be explained using Mario Kart, really? :)  It's a good example though. I repeatedly use the line your friend told you about programmers in this class too, except I leave out the "efficient" option. Later in the semester when we get to functions I also give them an arbitrarily short number of lines that is the limit for every function they write. If they need to write a longer function they have to divide it up into smaller functions that are called from the original. Sometimes this results in horrible code, but usually it helps them see the smaller problems inside each big task they're trying to accomplish.

Yes, there are a series of assignments that I give in the first few weeks of this class before we start writing code:

  1. Create an object ontology sheet for three items hanging around your room/house describing the subobjects that make them up and the properties of each subobject. Usually I have a semester-long project in mind so I tell them that one object has to be something specific, like a deck of cards.
  2. Reinterpret the object sheets within a specific context of use: what do you have to add, what is safe to take away?
  3. Add methods of use to the object sheets (verbs to go with the nouns of the properties). Make sure your sheet has any properties needed by the methods and vice versa.
  4. Create a set of instructions using only the methods and properties in your object sheet.* If your instructions need methods and properties that aren't part of the object sheet, add them.

The first attempt at each of these usually fails because they need to approach the assignment using a different set of assumptions than they're used to. That's expected though, and I let them redo these assignments after we discuss them in class.

The part that's tricky is the transition into actually writing code. By the time they understand the thinking behind objects they want to write objects, but there is still basic syntax that they need to learn before they can do that. The result is a couple of weeks of lost momentum, but it's made up for by a burst of productivity when they get to the point of implementing the objects they described in English at the beginning on the class.


* I use Zork as my in class example for this...and was thrilled this semester when one of the students not only knew what Zork was but had actually played through all three games!