That's how I felt this morning reading 'Coding is not the new literacy' by Chris Granger.
The power of code is in how it supports new kinds of thinking. It's in how it lets us represent, explore and communicate ideas. It's a means to such ends, not the end in itself.
The well-intentioned 'learn to code' movement frequently misses this point.
Reading and writing gave us external and distributable storage. Coding gives us external and distributable computation. It allows us to offload the thinking we have to do in order to execute some process. To achieve this, it seems like all we need is to show people how to give the computer instructions, but that's teaching people how to put words on the page. We need the equivalent of composition, the skill that allows us to think about how things are computed. This time, we're not recording our thoughts, but instead the models of the world that allow us to have thoughts in the first place.
The article pinpoints modeling as 'the new literacy'. Models let us play and explore. Such acts are an important form of creativity, and an important way of understanding complex things.
Interestingly, Granger points to Excel as the most ubiquitious tool for modeling:
Through Excel we can model any system that we can represent as numbers on a grid, which it turns out, is a lot of them. We have modeled everything from entire businesses to markets to family vacations. Millions of people are able to use spreadsheets to model aspects of their lives and it could be argued that, outside of the Internet, it's the single most important tool available to us on a computer. It gains this power by providing a simple and intuitive set of tools for shaping just one material: a grid of numbers. If we want to work with more than that, however, we have to code.
The beautiful thing about this is that millions of people, who would never considered themselves programmers, do indeed practice certain forms of (advanced) computation on a regular basis. There are many parallels in other forms of modeling and problem-solving, and yet the peculiar nature of code with its alien syntax is deeply off-putting.
Which is, of course, a huge opportunity for intervention.
He breaks down the process of modeling into these stages, which I think could be a useful framework for qualifying some of my ideas:
Specification: How to break down parts until you get to ideas and actions you understand.
Validation: How to test the model against the real world or against the expectations inside our heads.
Debugging: How to break down bugs in a model. A very important lesson is that an invalid model is not failure, it just shows that some part of the system behaves differently than what we modeled.
Exploration: How to then play with the model to better understand possible outcomes and to see how it could be used to predict or automate some system.
The context of this post is Granger's work on an unreleased product called Eve. A useful precursor is his post 'Towards a better programming' in which some deeper issues to do with our archaic programming languages are explored. Some clues to how Eve may work are given in this demo for a prototype product called Aurora:
It's hugely reassuring – and validating – to find other people asking many of the same questions as me.
I listened to a discussion of the subject in which an important idea – advocated by Piaget and Papert – was mentioned. To teach children (and I believe anyone) complex ideas you have to start with something familiar. We encounter this informally all the time: "It's like x but different because y."
It would seem that Granger wants to take the familiarity of Excel and let people move to something hugely more versatile and powerful. That seems like a strong approach.
I'm encouraged to use this notion as an anchor for my own ideas in building technical / procedural literacy. What are the familiar activities, with parallels to programmatic thinking, that might be a jumping off point?