by Pete Considine

In Honor of National Grammar Day

Photo credit: MIT

…or The Joy and Pain of Code as Language

When I’m not coding, reading about coding, or solving coding problems, I’m a managing editor for a business technology-related educator in the Pacific Northwest. As such, I spend at least eight hours a day in that place where art and science crash headlong into each other, playing word doctor to the resulting casualties. Believe me, there are many. Fortunately, it seems I’m one of those who can cross the right brain/left brain divide without too much effort (though I confess to greatly preferring the right brain functions), so I’m comfortable hanging out in the middle space between them.

That also means that I spend at least eight hours a day thinking about language. Language and clarity. Clarity and efficiency. Efficiency and effectiveness. Effectiveness and … you get the point.

All this thinking has led me to conceive of the word “language” very broadly. For example, several years working in educational publishing taught me the linguistic qualities of mathematics — the grammar of how problems are written, the specific vocabulary used, and how many mathematical properties can actually be interpreted as simply finding synonyms for different “words.”

Getting to the point …

Some time ago, in an online forum for self-taught coders, someone asked a question about why learning the basics (which we can generally take to be HTML, CSS, and JavaScript) is so difficult; or rather, why it’s so difficult for some, but not for others. I replied that we’re basically trying to learn three foreign languages all at the same time. Not only that, but three foreign languages that use similar, but not quite the same, vocabularies. I thought it would be far stranger if it wasn’t as difficult as it is.

So what difference does that make? We already knew that we were learning languages, right? I mean, it’s right there in the name — programming languages. For the coders who don’t struggle, it doesn’t make much difference, if any at all. But for those who feel like they’re “never going to get it,” that their brains “just aren’t wired that way,” and that they’re “not cut out for coding,” it could make all the difference in the world. So the rest of this article is written for them.

Photo by Matylda Czarnecka.

Learning to Speak All Over Again

Let’s start with a simple question — when was the last time you learned a new language? For many Americans, that was grade school, when they took a few years of Spanish, or German, or what have you. For some people, though, that would have been about the same time they learned to walk. No joke. If you weren’t forced to learn a foreign language at some point since then, the last time you learned a foreign language — before you started coding — was when you learned your native tongue.

Think about that for a minute. Most people say their first word at between 10 and 15 months. They don’t get a firm grasp on spelling and grammar until between 8 and 10 years old. Those that truly master the language usually only do so after several years of college.

You expect to master JavaScript in four months. As well as HTML5 and CSS3.

[Insert skeptical expression here]

So yeah, what you’re trying to do is hard.

(A Side Argument for the Love of Language)

I hate to be one of those guys, because I think it’s somewhat out of step with the self-taught coder ethos, but why is also very important. Why are you learning to code? Not too many people learn to speak so they can get a job. In fact, everyone starts out learning to speak because they need to communicate something and have found that language is much more effective than crying at the top of their lungs until someone figures it out.

In the same way, I often suspect that the people who struggle most with learning to code are the ones that don’t have anything they want to communicate. Their reason for learning the language is much more pragmatic. There’s nothing wrong with pragmatism. I think the world needs more of that, actually. It’s just harder to learn things if there isn’t a passion or some sort of more intrinsic motivation for the learning. That’s why I did really well at calculus, but not very well at basic algebra — I was way more enthusiastic about calculus. I didn’t need to be forced to learn its grammar and vocabulary and punctuation. I wanted to know how to answer the questions that only calculus could answer.

One Last Thing About Tools

Photo by Terry Madeley.

As I’ve been learning, I’ve seen bazillions of questions about frameworks and libraries and text editors and just about everything related to coding that isn’t actual code. It’s the same thing I saw with photography when I was moderating an online critique group— beginners who feel too insecure to participate in conversations about the substance of a thing instead choosing to talk about tools and rules. I totally get it. The problem is that it can often be a distraction from the real matter at hand, because just like the real test of a camera is the photograph that results from the photographer using it, the real test of a framework or library or text editor is the code that the coder produces with it.

As I’ve been learning, I’ve been trying out some of the different frameworks, libraries, and tools out there. With environments like Codepen and Cloud9, it’s effortless to road test something new. The ones that I’ve taken to the most are the ones that simplify the grammar of coding rather than the ones that tend to the book itself.

I’ve come to think that one of the things that makes coding so hard is that some languages like HTML are about 75% grammar and punctuation and only 25% meaningful vocabulary. For example, here’s a line of HTML from one of my Freecodecamp projects:

<button type=”button” class=”Adjust add”>
<i class=”fa fa-fw fa-arrow-circle-up”></i></button>

And here’s the same line written in Jade:


Naturally, I love the Jade version. It’s clear, concise, efficient, and effective. It makes the word doctor in me smile at its simplicity.

Things like NPM, on the other hand, drive me crazy. They’re basically just like having an editorial assistant whose only job is running around collecting your dictionaries every time you sit down to write something — even when you don’t actually need them. Sure he’s useful, but he’s a total distraction when he gets all amped up on Red Bull and starts breaking things.

There are times when the editorial assistant comes with the job and you can’t fire him because he’s the president’s nephew. So be it. You work with him as best you can and try not to shove him out a 12th-story window. But you sure as hell don’t go hiring your own if you don’t have to.

Of course, these are all the opinions of a maybe-intermediate level, self-taught code monkey whose interest in coding is much more passion project than ambitious career path, so take everything I’ve said with a healthy dose of “does that fit with my experience?”

As the Buddha said, “Rely not on theory, but on experience.”

(This essay began as a discussion in the Newbie Coder Warehouse Facebook group. If you’re a self-teaching coder, it’s an excellent resource.)