Penmanship and programming education
I think a lot about programming education because I love learning, often help new folks at work learn, and occasionally teach. Broadly, programming is heralded as one of the few career paths with outlier employment and pay, so people try to make sure it’s accessible.
Steve Yegge’s article Programming’s Dirtiest Little Secret claims that touch typing is the unrecognized foundation of programming skill. Yegge’s argument is that the engaging, interesting activities of programming - critical thinking, planning, design, imagining systems - are only accessible once you’ve mastered the skill of typing.
Recently I’ve been thinking about syntax.
So far I’ve never seen anyone prepared for the pedantic pickiness of programming. Missing a ] or a ) makes hell break loose. Complicated programs are nested many levels deep - curly brackets, more brackets, angle brackets, quotes, curly brackets, and so on.
Other mediums are more forgiving because there’s a human on the other side, and our brains are incredibly good at compensating for incomplete information. icouldwritethissentencewithoutspacesorcapitalizationandyouwillstillgetit Programming is relatively unforgiving - JavaScript won’t guess that when you write functin you mean function.
I messed this up really badly one time. I taught a week-long class to high-schoolers and didn’t spend nearly enough time talking about punctuation and handwriting. When you’re learning programming, the symbols matter, and when your instructor says “bracket” instead of “curly bracket” or “square bracket”, they’re leaving out a critical detail. And jumping right into “programming” the thinking skill without discussing the writing skill is doing the craft a disservice.
For instance,
function b() { return () => { return [`${[].map(a => ({ a }))}`] } }
This is a grammatically correct but pointless function that I wrote for this blog post. It’s unusually dense, but I was able to write it in one pass without errors: the thought process was like:
function b() {
// now i'm in a function. i owe a "}"
function b() { return () => {
// now i'm in two functions. i owe two "}"s
function b() { return () => { return [
// now i'm in two functions and an array. i owe two "}"s and a "]"
function b() { return () => { return [`
// now i'm in two functions, an array,
// and a template string i owe two "}"s, a "]", and a "`"
function b() { return () => { return [`${
// now i'm in two functions, an array,
// a template string, and an interpolated expression.
// i owe two "}"s, a "]", a "`", and a `}`
function b() { return () => { return [`${[].map(
// now i'm in two functions, an array,
// a template string, an interpolated expression,
// and a function argument
// i owe two "}"s, a "]", a "`", a `}`, and a ")"
function b() { return () => { return [`${[].map(a => ({
// now i'm in two functions, an array,
// a template string, an interpolated expression,
// a function argument, and a arrow function returning an object
// i owe two "}"s, a "]", a "`", a `}`, a ")",
// a "}", and a ")"
What is this? It’s something like short-term memory plus context awareness. You’re filling up a “stack” of ideas and punctuation and then unfilling it: finding your way back.
I think I can recognize the moments when people run out of focus and mental space for this task, when their mental map becomes too complex and goes blurry.
I’m beginning to think that teaching this skill of context and punctuation
- essentially a familiarity with structure and syntax - at the same time as the skill of “reasoning about programs” or “making computers do things” - is a mistake. Writing valid code and writing code that does things are complementary activities but they aren’t the same thing, and trying to make something happen before you feel comfortable with the lingo is a recipe for disaster.
So maybe the next time I try to approach programming from scratch, I’ll try a different way. I think it’s time to give syntax and writing the time and respect it deserves.
