Programming As Story-Telling

I was recently talking with a non-programmer friend of mine about teaching our kids how to code. I told him about my long and winding road to loving programming. He told me that he just doesn’t get how anything so tedious as programming can hold anyone’s interest for more than 5 minutes. Visual design, on the other hand, he finds utterly fascinating.

I agreed that design is easier to convey as exciting, that graphic arts is designed to convey a message to people; while programming, by comparison, looks like a bunch of arcane spell casting designed to convey a message to computers.

Then I told him that programs, at their heart, are for people to read and not for computers. Computers understand basic instructions written in ones and zeros to make them happy; while my eyes glaze over when I see a bunch of ones and zeros (as long as they aren’t preceded by a dollar sign).

We write programs for people to read. At some point, a compiler will look at that code and shake its silicon head as it takes the carefully crafted code and interprets it into some kind of gobbledygook that only certain CPUs will understand. But for now, I write programs to do something that the client wants. The client doesn’t care which paradigms I follow, which architecture I use, or even which programming languages I use. As long as the computer does what the client wants, the client is happy. Yet, code does not come out of my brain in one take. Code, like story-telling, comes in multiple attempts and revisions, depending on the mood of my audience and myself.

Ah, who is my audience? At times, my audience is my client; at other times, my audience is myself or my fellow programmer. The difference between a program and code is that a program is written for a client to enjoy while code is written for the human programmer to enjoy and the compiler to interpret into a program.

The code itself is typically made up of words in English and symbols which are translated into English. So,

var Elvis = new singer();
Elvis->style("RockNRoll");

is interpreted as “Elvis is a singer of the RockNRoll style.” I, as the fellow programmer thinks, “Ah, this is interesting, what happens to Elvis?” I find out within this coded function that the Elvis variable goes through several transformations and influences several different variables. Wait, what’s this, the Elvis variable, when combined with the Priscilla variable, generates a LisaMarie variable? What’s the story behind this Priscilla variable? What happens to this LisaMarie variable? Yet, the client is completely unaware of the existence of the variables Elvis, Priscilla, and LisaMarie. The only thing the client is aware of from this internal interaction, is that the movie “Naked Gun” had some rock music in it.

So, coding is telling a story and programming is interpreting that story into another story. Just as Shakespeare wrote his plays for actors to read and interpret and those actors then compiled his stories into dramatizations for the audience to enjoy.

I once saw “Macbeth” in the late 80s presented as as Sandinistas vs. Contras in Nicaragua. Was this Shakespeare’s intent? No, yet his intent was interpreted by the actors and presented in a manner unlike how it would have been interpreted and presented nearly 400 years prior.

Dostoevsky winnowed all of literature down to one of two stories: a stranger comes to town or someone goes on a journey. In programming, all functions can be boiled down to information comes in or information goes out. In both literature and programming, sometimes it’s a combination of the two truths.

Sometimes, my object goes on a great journey. Sometimes, interesting things happen to it. It’s all in the way we tell the story.