Jenson & Droumeva (2016) remind us that “‘computational thinking’ and algorithmic logic ought to be considered a kind of ‘core literacy’ that needs to be incorporated into the school curriculum alongside numeracy, textual literacy and scientific thinking” (p. 112). Though as a teacher I understand the sheer exhaustion of educators hearing about yet another type of literacy that must be taught, I also understand that our classrooms need to evolve to catch up with the latest policy documents on 21st century thinking. I happen to think that the first thing we need to do is reduce class sizes so that teachers can get some work done that doesn’t feel so much like crowd control. Then I think that perhaps the second thing we need to do is educate teachers about computational thinking skills and the absolute necessity of preparing students for a world so different from the one in which they were educated.
There were a number of aspects of coding literacy in this set of articles that I found very interesting. First up – the idea of teaching students to understand what an algorithm is and how it works in order, in part, to undermine its apparent power. In terms of social media, it is essential that students understand their role in applications like Facebook where their information is being sold to corporations who are the site’s real customers (Rushkoff, 2012). In addition, students should understand how imperfectly these algorithms work. It was a funny and happy coincidence that I finished reading the Rushkoff article, checked my email, and found a message from York asking me to consider professional learning options geared to my needs and goals. The options listed were entirely outside of the scope of my work and interests and this swing and a miss made me smile, given what Rushkoff had to say. Sorry, York.
I’m also interested in the idea raised by Bogost (2015) that we like to think of computer programs like Google as clean and simple computational activities when, in fact, they are “a confluence of physical, virtual, computational, and non-computational stuffs—electricity, data centers, servers, air conditioners, security guards, financial markets” (n.p.). We like to distance ourselves from the messiness of how things are made, the work that goes into them, how they decay and both their human and environmental costs. Bogost writes that using Google is “just like the rubber ducky [which] is a confluence of vinyl plastic, injection molding, the hands and labor of Chinese workers, the diesel fuel of ships and trains and trucks, the steel of shipping containers.” We are all so guilty of this distancing; I love my iPhone and hesitate to think of the humans involved in its creation and the waste the product generates. Instead, I focus, like so many others, on those beautiful Apple stores with their bright lights, white walls, and sleek products. Taking the magic away undermines the product’s hold over us and our students, but it also makes the things themselves – their creation, their programming – more accessible. Bogost (2015) implores us to “keep the computer around without fetishizing it, without bowing down to it or shrugging away its inevitable power over us, without melting everything down into it as a new name for fate.”
Finally, I think there were some very important points made about the lessons that can be learned through coding literacy (and through learning how to design games) that are reminiscent of earlier texts we have discussed. One of these is about collaboration. In his 2007 article Are Video Games Good for Learning? James Gee talks about video games providing opportunities for cross-functional teamwork. Rushkoff (2012) speaks of a new kind of team-work that comes from learning to code those games and thereby participating in “the values of a digital society: the commons, collaboration, and sharing”. Indeed, collaboration is a key aspect of 21st century learning (Jenson & Droumeva, 2016).
So, with all of this in mind, I turned to Twine for the very first time and then spent the next far too many hours playing and learning and coding and adjusting and learning and coding and playing (sort of in that order). In making my Twine, I had some really fun meta-cognitive moments through which I could see the real benefits of learning how coding works, at least in a basic way. For example, when I got through the first few passages and then tested it, I felt such a rush of pleasure at looking at this product that I had made! Figuring out how to get an image to work, how to change the CSS (and what CSS means) in order to get a look that I like, trying and failing to embed video (which it can’t yet do – oops), adding a background photo – all of these things were great accomplishments and I’m certain I was building up 1) my understanding of how programs work and 2) my confidence in my ability to tackle computational thinking challenges. After the first iteration was up and running, I rested on my laurels for a minute or two and then started tweaking my work. I wanted to adjust the size and colour of the title, for example, and had to look up how to write and insert those bits of code. I wanted to make the transitions smooth, so I looked up code for that and had to figure out where it went. In doing so, I found myself reading through many different sections of code and – sort of – understanding what I was reading. I also loved how the web or branch structure of the passages help to redesign what a story is and what it can be. In fact, when I finally showed my Twine to my sons, they were both really excited. My older son immediately wanted to write a “game” that he was going to make as a “choose your own adventure” story, though he is too young to remember those books. My younger son wanted immediate lessons in how to get started. Alas, it was bedtime and I was exhausted from a long day bent over the computer, learning an entirely new skill and making something cool of my very own.
Drumroll please….. My first Twine: Lessons in Haitian Ballet