Monday, June 17, 2013

Teaching Kids To Code Part 4: Coding To Learn

I started my last post by stating that we don't learn to code to learn to code. 
Nobody but a fancy fad-setter would think that. 
Like The Fancy Lad On The Left

We learn to code so that we can code to learn. That's a fairly a vague statement though, so I'll continue this series by interpreting and commenting on the rest of Mitch Resnick's key arguments in his TED talk. Since he created Scratch and I teach it, I'll use that software as the base for my thinking. 

As a reminder, here is the remaining summary of Mitchel's TED talk:  

3) When kids learn to code, it opens up opportunities to code to learn.
4) Programming teaches working collaboratively, thinking creatively, and reasoning systematically  so therefore everyone should learn to code.

So let's jump into it.
Like The Fancy Lad On The Left

When kids learn to code, it opens up opportunities to code to learn.
I like this idea because as a 4th grade teacher, it reminds me of the big transition that many of my students go through with how they view literature over the course of the year. Children entering fourth grade have been learning to read for the past three or four years, and for many of them fourth grade is one of the first times where they begin to consistently read with the alternative lens of "reading to learn." This takes on many forms, but here's an example: When I teach reading there is a emphasis to learn the author's craft because learning what the author does well not only helps with comprehension it helps with our writing. I choose this example because it illustrates how learning a skill in one content area can affect another content area. They're reading like writers. The children are reading to learn. 


But Not From Newspapers... That's A Dead Technology

So what can we learn when we code?
When answering this question, it's not fair to respond with any learned skill that is only applicaple to programming. "They learn iteration, conditionals, events, and processes." Those are strictly computational concepts that exist primarily in programming. Learning and mastering one of these concepts is still "learning to code" since there aren't a whole lot of other disciplines that benefit from learning these concepts.

It's also not fair to include anything that can be taught better through another venue. "Kids learn to create! They learn to craft digital stories or create animations through programming." There's no correlation between being a competent digital story teller and being a competent programmer. And although there are plenty of animations created in Scratch, there are still about a hundred better ways to teach it than through learning a programming language.


Egg on my face if this was created in Scratch. 
(It's not)

That leaves two main areas that we could focus on when defining "coding to learn":
- Learning some math concepts, and
- Learning the process of design

Math Concepts
I'm sure there are several more, but from my fourth grade curriculum, these are the areas I've identified as areas of math where the content can really be understood substantially better through coding than from traditional teaching practices:

Plotting Coordinates on a Cartesian Plane

Determining the Properties (lengths and angles) of Regular Polygons

Constructing Regular Polygons

Understanding and Incorporating Variables

Understanding and Incorporating Random Numbers

I should probably go more in depth with each of the items listed above. I could tie them to Common Core Standards and show examples. I don't feel like doing that right now, so I'll save that for a later project. I kind of talked about some of these things here and here.

The Process of Design
The process of design begins with an idea (For example, "I want to shoot a potato from a pipe.") that is eventually made into a prototype. Through experimentation and debugging, and with feedback from your peers, you revise and redesign the prototype into a more complete and polished end result. 
Kids can learn and experience the same process if they decided to build a pillow fort or a water rocket  or a pillow fort that has a potato gun arsenal and a water rocket escape pod. 
Some ideas are just too ambitious

Still it's worth loooking at the process of design a little deeper. For one there is less overhead in programming (since everything is virtual). For another, no one will accidentally be shot by a potato, which is itself an essential skill. In fact, this needs nicely into...


Programming teaches working collaboratively, thinking creatively, and reasoning systematically so therefore everyone should learn to code.
Learning to design needs all of these points. Programming environments don't really support all of these very well though. I'm only going to talk about the "working collaboratively" aspect and what children actually want that to look like in the classroom.
Scratch 2.0 prides itself on integrating the developing environment with the sharing environment, and although that is nice, it doesn't really model the reality of the classroom. What kids want is to pick up their project and show it to their friends. What they want is to grab the code from their table partner and play with it. But the smallest device that the Scratch environment runs on is a laptop. Those are portable. But they're still extremely awkward to a 9 year old who has respect for a machine that is not his own but still wants to pick it up, or twirl it around so her classmates can see, or pass it along. 


And What If Scratch Worked Like Google Docs?

Where a programming environment really needs to be so that children in the same space can "work collaboratively" is on a tablet. But tablet programming environments aren't really programming environments (Kodable, Daisy the Dinosaur, Cargo bot) or they're way to advanced (Codea). 
Maybe Hopscotch is the closest thing. I haven't tried it out yet, but at first glance it seems fairly limited. 
If Scratch is Legos, Hopscotch is Duplo Blocks

It's curious that the Scratch developers have put such an emphasis on online sharing, but no priority on inside-the-classroom collaboration. A mobile app makes a lot of sense.
But allowing for online collaboration, not just sharing and borrowing, but collaboration, makes a lot of sense too. Since the environment is online, I would suspect that eventually a Scratch project could look similar to a Google Doc in the way that multiple people can edit a Google Doc at the same time.

There's more to say. There's always more. But I've run out of Chris Elliott references.


No comments:

Post a Comment

Related Posts Plugin for WordPress, Blogger...