Teaching Kids To Code Part 2: Coding As A Tool For Creating

Author's note: This post is largely made up of pieces put together from Audrey Watter's blog post, "Top Ed-Tech Trends of 2012: Learning To Code" found on her hackededucation blog. I wanted to take the information she compiled and fit it into my specific context and experience teaching kids from around the world how to code.

I've been teaching my kids to code (using Scratch) for the past several years. I've used Scratch as both a tool to problem solve and a tool to create. And it has had more of an impact than any other tool I've used so far to explore these two avenues of learning. Still, the sudden push that everyone should learn to learn to code that I heard in some EdTech circles was a little irritating. I couldn't quite put my finger on it until I watched this fantastic presentation by Bret Victor:



To summarize:
So much of creation is discovering, and you can't discover anything if you can't see what you are doing. That's a problem with coding.
- There is a disconnect between writing code and a final project. Changes aren't immediate because you have to run the project again each time you make a change to the code. What should happen is that there's no "compile and run." A change in the code immediately changes the final project.
- Code should be predicting your actions as you write just like when you are writing a text message; as we type, it should give us a list of what it thinks we want.

Just as important to the creative process is being to try ideas as you think of them.
- Code shouldn't be mysterious. Putting my cursor over the code should highlight exactly what is being affected in the project. Putting my cursor over a section of the project should highlight the code that is controlling that section.
- If you have a process of time in your code, and you want to see changes immediately, you have to map time and space.

The software engineers at Khan Academy saw the above presentation, and came up with this:


To summarize:
The web based Khan Academy programming environment allows variable changes that be made in real time: A change in a variable immediately affects the project.

And then Mitch Resnick saw this and wrote a thorough essay that stated:

• Programming is a way of thinking, not a rote skill. Learning about "for" loops is not learning to program, any more than learning about pencils is learning to draw.
• People understand what they can see. If a programmer cannot see what a program is doing, she can't understand it.

He goes on to say that:
Thus, the goals of a programming system should be:

• to support and encourage powerful ways of thinking
• to enable programmers to see and understand the execution of their programs

A live-coding Processing environment addresses neither of these goals. JavaScript and Processing are poorly-designed languages that support weak ways of thinking, and ignore decades of learning about learning. And live coding, as a standalone feature, is worthless.

The content of his essay delves deep into how we should address those goals. Here's the outline:

The environment should allow the learner to:

• read the vocabulary -- what do these words mean?
• follow the flow -- what happens when?
• see the state -- what is the computer thinking?
• create by reacting -- start somewhere, then sculpt
• create by abstracting -- start concrete, then generalize

The language should provide:

• identity and metaphor -- how can I relate the computer's world to my own?
• decomposition -- how do I break down my thoughts into mind-sized pieces?
• recomposition -- how do I glue pieces together?
• readability -- what do these words mean?

The whole essay is excellent, and I hope someone, somewhere is trying to implement his recommendations. 

The interesting thing here though is that both Bret Victor and Khan Academy are wanting to make programming more accessible. A big difference seems is Simon Senek's Golden Circle:

Khan Academy seems to be approaching coding from the outside to the inside of this circle. They are starting with the "What" and their tutorials show "How" but the "Why" is missing.

"People don't buy what you do. They buy why you do it."

But listen to Bret Victor. He starts with "why." Then he shows us "how." It's a decidedly different approach. It also aligns to my vision of what programming should be, which is probably why I'm highlighting his work.

But we're not there yet with any programming language. We may not be there for a long time if software engineers keep focusing on the "what" and the "how" of their products. And Khan Academy is further from the goal than Scratch 2.0 is. Scratch doesn't focus on the "why" either, and certainly doesn't address several of Bret Victor's concerns. But its language is more intuitive than JavaScript, and its environment does a few other things that promote both the preservation of ideas and the expansion of them. So this is where I'll end today and where I'll begin in my next post in the series.