Posted on by & filed under learning, programming.

Over the holiday break, I re-read Andy Hunt’s Pragmatic Thinking and Learning on my phone. I had started it mainly to force myself to re-evaluate the iBooks reading experience, but quickly became immersed (again). The book makes an informed, but opinionated, introduction to brain architecture, learning theory, and neuroscience. The compelling central theme is that knowledge workers, programmers in particular, are hopelessly bad at using their minds.

As a parent of two young children, hopelessness is something I’m acutely familiar with. From the outset, a decidedly verbal father like myself is forced to communicate with his kid using a range of awkward and non-verbal techniques. It sucks. Even as they’ve grown older and grasped language, I’ve continued to be astonished by how ineffective words are at teaching key behaviors. “Go back to sleep” is easy for an expert adult to say, but nearly meaningless to a kid. Similarly, they need a different tool than language to distinguish between their “whiny voice” and a tolerable one.

Words fail us

Hunt argues that this blindness about the limitations of language is a particular weakness of programmers, who are tremendously attached to representing everything verbally. He recounts a story from the Inner Game of Tennis about teaching an older neophyte:

The next exercise was to listen to the sound of the ball hitting the racket. If you’ve never played, the ball makes a particularly sweet, clear sound when it hits just the right spot on the racket. This fact wasn’t made explicit; our student was merely told to listen.

Next, it was time to serve. First, she was to just hum a phrase while watching Gallwey serve in order to get the rhythm of the motion. No description of the movements; just watch and hum. Next, she tried the serve—humming the same tune and focusing on the rhythm, not the motions. After twenty minutes of this sort of thing, it was time to play. She made the first point of the game and played a very respectable, lengthy set of volleys.

It is easy to dismiss this focus on sound and movement as irrelevant to programming, but that’s the trap. What non-verbal tools do we ignore as we collaborate and teach?

Programmer pedagogy is terrible in general, so it’s obvious to start there. What would it look like if we showed, in the most literal sense, a learner good testing, how to search for a bug, or planning a requirements doc? This is a part of the draw of pair programming, but we rarely reference or emphasize any non-verbal elements.

Pictures in particular

As a programmer who never ever uses UML, I am often surprised how attached and excited my non-programmer colleagues get about a diagram of a software system or process. There’s a whole lot packed into one of these sketches even without the words:

A complicated diagram from a whiteboard (but without labels)

A diagram I actually drew on the whiteboard for colleagues, with the labels removed.

What would change about internal communication if we spent as much time drawing a new icon to represent a new project instead of arguing about the name?

A pictorial representation of the sounds over a telephone line that start a modem connection

A picture of the sounds required to start a modem connection, by Oona Räisänen.

Many HTTP APIs are too “chatty.” How would our API design change if we drew a picture of the desired interplay without ever writing a line of code?


There has to be more opportunity for non-verbal thinking than just images. Is there an opportunity in expressing the auditory layer of programming? The movements? It all sounds terribly New Age, but then I remember trying to talk to a six-week old kid.

Tags:

One Response to “Wordless programming”

  1. Sierra Tolter

    “It all sounds terribly New Age…”
    Gallwey “discovered” a phenomenon that had not yet been scientifically proven: mirror neurons. He also found clever ways to tap into aspects of the brain that are designed for effective, efficient learning, while dialing down the aspects of the brain that get in the way. At the time (early 70’s), he became associated a new-agey/mystical perspective and was often viewed as a charlatan despite his clear, objective, shocking results.
    Many years later, though, one of the greatest computer scientists of our time — Alan Kay — recognized that Gallwey was on to something crucial (and ignored the woo-woo discussions about it), and got me to take another look. And all these years later, more and more science is beginning to explain what he observed, and support his choices about how to use this to improve learning at a deep level. That Gallwey wrapped observable but unexplained (at the time) results in fluffy, spiritual language has prevented many from taking it seriously, and that’s also tragic given the poor state of education today. But I figure if Alan Kay says something is worth paying attention to, it IS. And each year since, yet another research project unearths an explanation for some of what Gallwey “discovered.”
    In some ways, this is similar to the “Drawing the Right Side of the Brain” book/courses: the “science” in the book is way off, yet the observable results are clear. It might have been much better to refer to it as “Drawing in a way that actually works better than you can imagine, for cognitive reasons not yet fuooy understood”, but that’s not as catchy :)