Learning to code is learning digital literacy

One of my least fulfilling reporting experiences involved a meeting between Ukrainian community leaders and local school district officials. There had been a brawl at a middle school and the Ukrainians, being the minority in that area, suspected their kids were racially targeted.

Anyway, the difficulty was that they didn’t speak English very well and many others at the meeting – the district officials and me, included – didn’t speak Ukrainian. So we had translators. The meeting had taken some time to plan and parents were nervous about their children’s safety, so everyone hoped for some kind of resolution. But after the meeting kicked off with long speeches by both sides – made doubly long by having to listen to the sterile translation that came afterwards, it seemed obvious that even a meaningful, impassioned debate was futile, nevermind reaching a satisfying resolution. The district officials told me afterwards, of course, that this was a good use of time, while the Ukrainian community members didn’t think anything came out of it.

When you think about it in theory, having a translator seems like a “good enough” solution. But when you’re sitting there, even though you and your other side share the same thought processes and general human understanding (independent of spoken language), a translator cannot:

  • Connect statements to the body language and emotion nuance of the original speaker
  • Mediate the kind of free-flowing give-and-take that is necessary for fulfilling debates
  • Make up for the time delay between the original statement and spoken translation

And of course, there’s the problem of knowing if the translation is even correct, as we know from Suntory Time:

This is a roundabout way to argue for the need for digital literacy, i.e. the Learn to Code movement. Code.org launched with big fanfare this week, featuring just about, well, everyone – Bill Gates, Bill Clinton, will.i.am(?), and everyone’s favorite “computer geek trapped in an NBA player’s body,” Chris Bosh – telling us why we all needed to program.

And of course there’s the backlash: why does everyone need to program? Jeff Atwood wrote a well-read essay about it last year (“Please Don’t Learn to Code”), Coders Lexicon posted an essay last night:

The fact is, the whole world should not learn to code anymore than all of us should learn to be a space shuttle engine designer or a lawyer. While I understand the need for more people to get interested in computer science and to fill our ranks with people who can meet the skills of the 21st century, going out there and telling everyone that coding is as easy as putting a bit of syntax down into an IDE and hitting compile is not the way. We need passionate people who are creative and want to learn to DESIGN software in addition to coding.

There are a couple problems with this argument. The first is making programming sound as time-intensive and domain-specific as space shuttle engineering or law. The second is making programming sound like an all-for-nothing proposition: don’t get into programming unless you can do it really well, or else your program will kill people.

(Not that that hasn’t happened…but the more relevant statement would be: don’t code people-killing programs unless you know what you’re doing.)

What would schools be like if we warned children to not learn how to read or write because ideas in books and newspapers have frequently made people’s lives miserable? Or, how about, don’t learn math, or the metric system, because even Lockheed Martin and NASA engineers can screw up and lose a $125 million Mars satellite?

The reason to learn how code works is to have a direct involvement in the technology and data we rely on. Just as we learn to read and write at a basic level so that our time isn’t spent waiting for someone – who may be much better and specialized at it – to read the news or road signs or write love letters for us.

In the newspaper world, it’s assumed that every reporter knows how to write. That’s not even remotely close to reality. In the golden, fat days, a reporter could expect three to four layers of editors to go through his/her work before it got printed (today, readers just have to deal with a lot more typos and errors). But even then, you couldn’t get by as being a fantastic reporter and storyteller who was also illiterate. Think about it: you don’t need to know how to read or write to go around asking questions or dictating what you remember hearing of a blockbuster scoop. But imagine the editors who get to spend their day transcribing and retelling you what they’re actually putting down on paper.

More importantly, think about what you, the illiterate reporter loses out on. You don’t get hands-on involvement on how the facts and quotes are arranged, because you have to wait for it to be done (and then read back to you) before you have a say. And there’s a lot that you just don’t know that you don’t know. Like how a headline, by its size, color, and length, can change everything about how a reader perceives your story. Or how a story that’s in print has a much different, detached effect than what you’ve experienced with the spoken word (similarly, writing copy for broadcast is its own separate art compared to newspaper writing).

But you don’t know that because you know that there’s a story, of some sort, is on the paper and people seem to be reading it so what’s the big deal?

This is the gap of understanding for anyone who isn’t digitally literate. It’s not about knowing how to build a website or assemble your own computer. It’s not even that you need to know a lot, just as you don’t have to be able to recite the entire works of Shakespeare to justify traditional literacy. With digital literacy, it’s about knowing enough to know what’s possible with computers, data, and technology, to control more of how it affects you. Or, as Donald Rumsfeld puts it, having fewer unknown unknowns.

How much is “knowing enough”? There’s a lot that’s been written about it in better places, Code.org probably isn’t a bad place to start. Besides learning to program, which is not the only thing to do or even the ultimate end goal, the two practical steps I can suggest are:

Also this week, Jeremy Ashkenas announced the first release of Literate CoffeeScript, a format that combines CoffeeScript with the easy-to-read-and-turn-to-HTML Markdown syntax. If you’re an experienced coder, this seems like nothing more than block-extended comments that are found in any language.

However, in practice, the power is in the details. I know that I avoid documenting code – even though we spend far more time re-reading code than actually writing it – because I just have never committed to some kind of system of making code comments easy to read (should I use asterisks to emphasize something? Or all caps? Or double space things?). With Markdown, you have the power of HTML to document your code. And more importantly, it’s intuitive and easy, which makes you more likely to write comments in the first place.

Check out Ashkenas’s demonstration: his own blog is powered by a “quick-and-dirty” blogging engine he wrote in Literate CoffeeScript. This is what the generated code and documentation look like on Github.

On a related note: if you’re a programmer who doesn’t understand why non-programmers need to be digitally literate: imagine having to write code in another language. Not programming language, but human language, such as in Chinese characters, without actually knowing that language. Sure, you could conceive an amazing program. But writing it yourself, with the help of an interpreter who types out what you say? Sounds even more laborious and mind-numbing than the worst programming project imaginable.

I'm a programmer journalist, currently teaching computational journalism at Stanford University. I'm trying to do my new blogging at blog.danwin.com.