The Surprising Similarities Between Writing and Coding

Every day, for hours at a time, I sit at my computer and tapdance my fingers across the keyboard. Sometimes I type words for emails or articles. Sometimes I type a weird pseudo-language full of brackets and dots and semi-colons, telling the computer what to do.

When we write prose, there is plenty of whimsical advice. Think about your ideal reader, they say. Imagine them reading your words and write to them directly. Don’t use (pointless) adjectives. Passives should be avoided. Never use a five-dollar word when a fifty-cent one will do. But whatever we write, some people will enjoy it and some will not. We have no platonic reader who will get each reference and love every turn of phrase. When we write code, on the other hand, we do have an ideal “reader”: the computer. A reader that is simultaneously more forgiving and less forgiving than a human. Computers don’t care about style or clarity. They won’t try to start bad-faith arguments with you on Twitter. But they really, really care about typos.

There is plenty of whimsical advice about coding too. Use meaningful names. Don’t reinvent the wheel. Coding advice tends to contain more acronyms. YAGNI — “you aren’t going to need it.” DRY — “don’t repeat yourself”. SOC — “Separation of concerns”. They sound like verbs: dry your code out, soc it on the nose. Some advice is more overtly violent. “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live,” John Woods wrote.

Rewriting is refactoring

Writing, they say, is rewriting. Coding has its own version: refactoring. Refactoring is rewriting code to do the same thing in a clearer or more maintainable way. For me, coding is a constant flipflop. Hacking something together through trial and error, constructing shamefully inelegant commands until, finally, it does what I want. Then stopping to tidy it up. I’m constantly reshaping what I wrote to make it presentable to the outside world. Writing words isn’t much different.

I think of Oscar Wilde’s famous quip: “I was working on the proof of one of my poems all morning and took out a comma. In the afternoon — I put it back again.” I spent yesterday working on one of my objects and added in a method. In the evening, I took it out again.

Code is working words. That is not to say words in prose don’t work, but it’s different from the way code words do. Code consists of instructions. When people say “I name this ship,” or “I sentence you to three years in prison” these are performative utterances. The speakers are enacting those concepts as they say them: by saying “I name this ship”, they name it. They are coding with speech. When we write code we write digital performative utterances. Most prose writing is not as functional. Generally, we impart information, not directives.

Omit Needless Functions

Writers of prose are charmed by their words. “Kill your darlings,” they say, in recognition of how difficult it is to delete words you have sweated over. In code, when I can remove a function I delight in hitting the delete key. Every statement is one line I wish I could eliminate. My perfect computer program would be one line: doThing(). But then I mentally refactor that. Perhaps it should be: do(thing) or thing.do().

How strange that prose words, once written, are darlings we weep over as we delete, but code words are goblins that leave us smiling as we backspace them into oblivion. “The best code is no code at all,” Jeff Atwood says. “Code is our enemy,” Rich Skrenta writes. Perhaps these are code versions of William Strunk’s famous advice: “omit needless words”.

Each type of typing has its patron saint. For writing, it is William Strunk, the imperious author of the Elements of Style who would lean over his desk and bellow his advice: “Omit needless words! Omit needless words! Omit needless words!” He had, they said, omitted so many words he now repeated everything three times to make up the time. For coding, the equivalent is the avuncular Uncle Bob, author of Clean Code: “The first rule of functions is that they should be small,” he writes. “The second rule of functions is that they should be smaller than that.” The first rule of sentences is that they should be short.

There are these odd little inversions between writing and coding. My code is white text on black, my prose is black text on white. When I have finished my code, I release it. Like a dove. When I have finished my writing, I publish it. From the Latin, to make public. The two verbs feel the wrong way round to me. Code is something I make public, writing is something I let fly away.

Then there are the economic differences. Eight-week coding bootcamps result in six-figure salaries. Four-year creative arts degrees result in unpaid internships and the occasional £3 from literary journals.

Write as if your reader is a violent psychopath

I was wrong above when I said we write code for one specific reader, the computer. For our code to be of any use, it must run on dozens, thousands, millions of computers. Some will run out of storage, have low RAM, or slow processors. Some might be unplugged in the middle of running our application. Code is perhaps more similar to writing after all (Although, it feels impolite to consider how those computer limitations parallel those of our human readers.)

The coding tips we read are not for computers. We don’t write short functions and simple commands to help the compiler. We write them to aid subsequent humans reading our code. It is not the computer that is a violent, chainsaw-owning psychopath who knows where we live, it is the person who maintains the code after you. As I said above (DRY not achieved) code is working words. It runs over and over again. Think of your favorite application — Chrome or Twitter or Fortnite. Your computer will run the code powering that application thousands of times. Software developers will read and edit and release updates to that code. When you think of your favorite book, you may have read it half a dozen times. Certainly not millions of times. And even if the author has released an updated edition, they don’t send a new copy to your house every other Tuesday containing “bug fixes and enhancements”.

Still, I wonder how much advice can be lifted from one discipline to another. Use simple functions rather than obscure language features equates to use simple words. Keep it Simple, Stupid could apply to either. “Don’t repeat yourself” is, if anything, more applicable to writing than coding. Avoid nested sub-clauses: avoid nested conditionals. There is no Stack Overflow for writing, but if there were writers would be copying and pasting from it, and others would be saying not to. Thank god we don’t have adjectives for code. The equivalent is unnecessarily verbose comments.

Perhaps there are tips we haven’t uncovered because they lurk in the wrong domain and haven’t made the crossover.

I love writing and coding tips. They are one of my (many) internet junk foods. Tips like these, I think, are compelling because reading them feels like work, but comes with none of the effort. They are the ultimate procrastination, complete with inbuilt plausible deniability: I’m sharpening my axe, we can say as we browse another list of 10 tips to supercharge our writing.

These tips are metaphors. They are applicable to all human endeavors, not just the one to which they claim to apply: “Practice makes perfect”, “ask for help when you need it”, “if you get stuck, take a walk”, “be consistent”, “never stop learning”, “don’t take a shortcut to save yourself a few minutes”, and “have patience, and love what you do.” It’s impossible to say whether I got these from a list of writing tips or coding tips, or even tips for an entirely different discipline. Ultimately, the reason they work for both is that they’re not really tips for coding or tips for writing. They’re tips for life.