The Phonics of Computing Education

In 2005, Merrick Furst (then, our associate dean for undergraduate education) said to me, “I think of your Media Computation and contextualized computing as a kind of ‘whole language‘ approach to computing education.  What are the phonics?  What’s the computer science equivalent of the scales and etudes that musicians practice with to get the basics down?”  At the time, I replied that getting students to understand why they’re learning to program, the relevance of what we were teaching them, was the most important factor. I still think that. But I’ve been pondering the phonics question for the last four years.

I was reminded of that question when listening to the NPR report on the end of PBS’ ‘Reading Rainbow.’ The beginning of the report chalked the demise up to a lack of funds, but as it went on, the report really sounded like a change of heart at PBS–driven by research findings.

“Reading Rainbow taught kids why to read,” [John] Grant [of WNED Buffalo] says. “You know, the love of reading — [the show] encouraged kids to pick up a book and to read.”

Linda Simensky, vice president for children’s programming at PBS, says that when Reading Rainbow was developed in the early 1980s, it was an era when the question was: “How do we get kids to read books?”

Since then, she explains, research has shown that teaching the mechanics of reading should be the network’s priority.

“Teaching the mechanics” — that’s what the “phonics” of computing education is about.  Context tells us why.  The mechanics tell us how.

We do a lousy job of teaching the mechanics of programming in computing classes. Our traditional tools of teaching programming are lecture and student practice with the interpreter or compiler.

• Pair-programming is just a twist on the student practice that doesn’t make the mechanics easier.
• Think about the perennial problem in Java of learning where to put the semi-colons.  How do we help with that?  We lecture on where to put semi-colons — yeah, we know how effective that is.  We show example code — better than just lecturing, but since our assignments are rarely modification of code, students are mostly dealing with semi-colons on a blank sheet.  Then, we throw students to the Java compiler, whose error messages in response to a missing or misplaced semi-colon are awful.
• Visual languages like Scratch or Alice reduce the mechanics.  For CS students, they just postpone the inevitable. I don’t know of any evidence that the mechanics are easier in the textual language after facing the visual languages.

If the research on reading applies to computer science, then we ought to be doing much more to convey to students the mechanics of programming.  What kinds of mechanics are important to teach?  I’ve thought of three, and I’d really appreciate hearing your suggestions on others:

• The syntax of the programming language. I understand (somewhat) while error messages in the full compiler can’t be made much better.  But surely we can build tools/tutorials/drills/etudes where students could practice the nitty-gritty details of language syntax with better feedback than compiler error messages.  I feel guilty every time my Python students get the indentation wrong in their programs, because the error message is about quotation or indentation errors “somewhere around line X.” Surely I could build something to help them learn indentation short of tossing them in front of a speeding interpreter?
• How to read code.  Everyone who comes to lecture gets to see and hear how the lecturer reads code.  All 30% of them.  There is a skill to knowing what to attend to in a program.  Everyone knows to simply skip “public static void” in the main method of a Java class — everyone except the novice who doesn’t know which words are important and which can be safely ignored.
• How to tinker with code.  Given a piece of code that you’re trying to understand, you know where to put print statements and what constants are worth tweaking to see the impact.  How does a novice know that?  We know that changing “i” to “j” as the index to the loop isn’t all that useful. How did we learn that? How do we teach that?

These activities are in the class of things that we experts never think about.  They’re the “obvious” things that we simply ignore.  Exactly! That’s what the “phonics”/mechanics are.  How do we teach them?  As experts, we know to simply ignore those matters and do them without thinking.  As novices, they are yet another distraction, and cognitive load theory suggests that those “distractions” add up.  In the end, we only have 7+/-2 chunks — that’s a human limit, and all those distractions are chunks that quickly add up to an impediment to getting at the learning we care about.

These “phonics”/mechanics are important, not just for the novice, but for the expert who is trying to bring herself up to speed on the latest technology.  The practicing programmer who wants to learn Ruby or Scala doesn’t need to know why to program in these languages — she already has that.  She wants to know how.  She wants the mechanics of the language.  Research on how to teach “phonics”/mechanics of a new language would go a long way towards bringing her up to speed on the new technology.  (I’m choosing “she” in these examples explicitly because I’ve been thinking for a year now about the implications of Caroline Simard’s report for the Anita Borg Institute on the needs of mid-level technical women in IT.)

Teaching the “phonics”/mechanics of computing education is on my mind a lot these days.  I’m thinking that it may be our most significant point of leverage in improving computing education.  New curricula may not get adopted.  The phonics of computing education crosses all curricula. Getting the phonics right helps both the novice and the practicing programmer learn new skills.  Done right, phonics can be taught self-paced, even via distance learning, to act as a supplement to existing instruction.  I still think that the context is our most important change to improve computing education, but teaching the phonics/mechanics well may be the most universal improvement we can make, the one that can help everyone regardless of curriculum.