Text

|


flickr photo shared by mrkrndvs under a Creative Commons ( BY-NC-SA ) license

I am going to be honest, today I was found out. I understand the place and power of programming. However, I was one of those people who had overlooked Scratch as somehow being ‘easy’. One of those people how felt that it was a good place to start, to explore and remix, but not really worthy of real work. As I listened to Gary Stager speak about making I realised that I had been missing a trick all along. What matters is not how it looks or even how it works, but rather what it allows you to do – and it allows you to do a lot. This experience was no more obvious than when I was tinkering with Lego WeDo.

Having had some experience with Lego Mindstorms, I was interested in the difference to WeDo. The first thing that stood out was that there is just one motor and two sensors: motion and tilt. While to operate it you need to be connected to a computer (or in the modern version, an iPad using apps like Tynker). Although there were instructions provided, I was more interested in how it all actually worked. I therefore decided to try and make a simple propeller that would be controlled by tilting.

My first step was to connect the WeDo to my computer. Unlike Lego Mindstorm, WeDo allows both its own software or Scratch. After searching around, I made a simple line of code that demonstrated how the two sensors worked. This involved developing an appreciation for the values produced by the senses, as well as blocks required to get them to work.

Once I did this, I then wondered if I could use the tilt mechanism to not only turn it on and off, but also control the direction. After testing a range of options, Richard Olsen helped out by suggesting that I create a loop with two different parameters, where if the tilt was above 2 then it would go one direction, while if it were below 2 it would go the other way. This worked, but it was very messy. After struggling to determine whether it was actually turning, I added a yellow brick to the makeshift propeller in order to make it clearer. Although we could get the propeller turning, controlling it was a little haphazard.

After some reflection, it was identified that one of the issues was the time on the motor. We therefore adjusted this from 1 second to 0.1 second. This provided precision, but was at the expense of speed.

It was thought that maybe a part of the problem was that there was too much going on in one line of code. So after some discussion from others, we split the program into two parallel lines. This solved everything, providing both speed and precision.

As I moved around the different stations throughout the day, so many devices devised were based around the use of block code. Whether it be Dash and Dot or the Hummingbird kit. One of the points that Stager makes again and again is that programming itself has not dramatically changed over the last thirty years. What matters is what we can do with it and more importantly, how we go about it.

School, especially in science and math classes, typically only honours one type of learning and problem- solving approach, the traditional analytical step-by-step model. Other more non-linear, more collaborative, or more artistic problem-solving styles are often dismissed as “messy” or “intuitive” with the implication that they are not reliable.

For more information on making and the work of Gary Stager, check out the following:

Text

|


flickr photo shared by mrkrndvs under a Creative Commons ( BY-NC-SA ) license

A few years ago, when every second student was reading one of the books from the Hunger Games series, I was asked by a student whether I had read them. I explained that I hadn’t. Shocked, the student questioned how I, an English teacher, couldn’t have read them. I asked the student whether he had read Dostoevsky’s The Brothers Karamazov. Confused, he said no. I asked him, why, even though it was considered a classic text of the Western Canon, he had not read it? Surprise to say, the irony was lost on him and the conversation did not go much further. With a feeling of shame, I subsequently went off and read the whole series.

In many ways, I think that the debate over coding in the curriculum follows the same lines. Many call for its inclusion with little explanation why. Another thing to add to an essentialist curriculum. Often the debate is about what is being done and whether staff are adequately prepared, rather than clarifying why coding is even being taught and how we should actually go about it. The first conversation that we need to have though before all this is surely what constitutes coding.

For some coding signifies a bunch of characters used to make the web, others it is about making things happen, for some it is all about the app culture associated with going mobile, while for others it is deeply connected with the formulas, flows and algorithms associated with computational thinking. The reality is that coding means different things for different people in different contexts.

In a recent episode of the #2regularteachers podcast, John Pearce suggests taking our understanding of coding beyond the tool or application, instead considering it as a ‘way of thinking’. For example, rather than seeing a Raspberry Pi as a mini computer which allows you to play Minecraft, we need to consider the affordances that it allows, such as programming a camera to capture an experiment at regular intervals or detecting wifi signal to map free internet points around Australia.

For years when I taught robotics with Lego Mindstorm, I would spend weeks getting students to learn the intricacies of NXT before exploring the possibilities of making. This year I decided to skip the weeks of instruction and instead focus on just making. It was not long before students realised their limitations and dug into the possibilities associated with programming in order to improve their designs. With a purpose, they worked their own way through the various tutorials provided.

The challenge to me is to go beyond the question of instruction and understanding of different languages. Beyond debates about fitting it within an already crowded curriculum. Instead the focus should be on creating the conditions in which students are able to take action and create new possibilities. Maybe this involves Minecraft, Ozobot or Spheros, maybe it doesn’t. Most importantly it involves going beyond worrying about training or competency, as Ian Chunn would have it, and instead embracing the world of making by leading the learning.

So what about you, what does coding mean to you? What have been your experiences? Positive and negative. What do you see as the biggest challenge moving forward? As always comments are welcome.