Coding is communicating

I’m catching up on some long-neglected reading today, and while catching up with the latest Communications of the ACM, found this great column on “Literate Coding”.  The question posed is whether or not it matters if you make spelling/grammar mistakes when writing your code.  The column’s author broadens the perspective and considers things like incoherent/incomplete comments as well.

The author argues that coding is communication, but more interestingly, he lays out an argument as for whom exactly we programmers are coding (emphasis is mine):

Clear code is actually more aligned with clear writing than most people are willing to admit. Many programmers seem to have gone into their field to avoid subjects such as English or anything that would require communicating with other people rather than machines. That is unfortunate, because code is a form of human communication.

Although a computer will execute your program, it will not execute it in the exact form in which you wrote it, and it definitely does not care that your variables are misspelled or that your comments do not make it clear who did what to whom in the code that follows them. Code is not just for computers; it is for other people as well. If the next person who reads your code—in your case your professor, but after school it will be your workmates—cannot make heads or tails of it because you failed to write in a clear manner, then that is sloppy work on your part and deserves poor marks.

(As an aside, one of the more interesting “a-ha” moments in my Computer Architecture class happens when we talk about what compilers and processors do to code before executing it.  Students are shocked that processors don’t execute code exactly as written, and in fact take many liberties with reordering instructions and even—horrors!—“unrolling” those loops they’ve carefully and lovingly constructed.  Students tend to think, in a sense, that code is handed down on high from programmer to processor.  Disabusing them of this notion is fun!)

I’ve had some interesting conversations in the past with the head of our writing program and a former dean about whether coding should be considered writing.  As the author points out here, in a sense it is.  As computer scientists, it’s easy to forget that code is our primary tool of communication with other computer scientists as well as with the computer.  So things like structure, variable naming, and yes, comments, can either aid or hinder that communication.  (Viewing code as communication may also better explain some of the holy wars developer teams wage over bracket placement and indentations—such norms are the coders’ dialects, and dealing with a dialect different from your own can be jarring!)

I’m teaching our version of CS1 and CS2 this winter, and I plan on sharing this article with both classes.  I’m curious as to what kind of discussion it will engender, and whether the discussion will be fundamentally different in CS1 vs. CS2.

All I needed to know about, well, everything, I learned in CS?

There’s a very interesting opinion piece in today’s Chronicle of Higher Education titled “Decoding the Value of Computer Science”.  It’s actually a very complimentary article about how studying computer science has helped the author be a more effective thinker, and how the critical thinking and logic skills have spilled over into each of his subsequent careers (none of which have had anything to do with computer science).

I took a keen interest in this article because, of course, this is the message that I try to give my students:  studying CS is one of the smartest things you can do while at Carleton, because it prepares you generally to be a good problem-solver.  I’m actually thinking of linking to it on my course Moodle pages next term and having my students read it.

Here are a couple of my favorite quotes from the article:

Before long I wanted to understand where those games came from and how, exactly, they worked. So I took to programming, first in Basic and then Pascal. Coding taught me the shape of logic, the value of brevity, and the attention to detail that debugging requires. I learned that a beautiful program with a single misplaced semicolon is like a sports car with one piston out of line. Both are dead machines, functionally indistinguishable from junk. I learned that you are good enough to build things that do what they are supposed to do, or you are not.

I like the sentiment of “debugging” as “attention to detail” and not “dreadful task”.  Also, the author is spot-on with his description of how he got hooked—I find that students take my Intro course because they’re curious about how this technology thing works, whether that “thing” is games or Facebook or just a desire to think of the computer as something other than a black box.

Here’s one way in which that played out for him in the future, as a writer:

My editors rarely said a word about words, in the sense of how to phrase an idea. The real work was in structure, in constructing an unbroken chain of logic, evidence, and emotion that would bring readers to precisely where I wanted them to be. I learned to minimize the number of operating variables (people). I also learned that while some talented writers can get away with recursive scene-setting, it is usually best to start at the beginning and finish at the end. I discovered that skilled writers, like programmers, embed subtle pieces of documentation in their prose to remind readers where they are and where they are going to be.  Writing, in other words, is just coding by a different name. It’s like constructing a program that runs in the universal human operating system of narrative, because, as Joan Didion once said, we tell ourselves stories in order to live.

I’ve had discussions in the past with people who teach writing as to whether coding is writing—this piece seems to argue that it is.

The author also laments the current state of CS education, the fact that the number of students studying CS at the high school and college levels is dropping, and the possible repercussions:

Computer science exposed two generations of young people to the rigors of logic and rhetoric…. Those students learned to speak to the machines with which the future of humanity will be increasingly intertwined. They discovered the virtue of understanding the instructions that lie at the heart of things, of realizing the danger of misplaced semicolons, of learning to labor until what you have built is good enough to do what it is supposed to do.

Luckily, here at Carleton the number of students studying CS is and continues to be strong—but I do worry about the field in general and what the lack of majors (and of people studying CS in any form, whether as a minor [other places] or as a general graduation requirement or just for fun) means for the future of innovation (as the author mentions earlier in the article).  Should we be requiring students to take CS?  😉