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.