Writing Code vs. Writing Prose

Programming languages were developed because natural language isn’t adequate to communicate instructions to computers. Unlike natural language, programming languages have strong composability: you can take a line of code and start putting things into it or removing things from it to drastically change its meaning. Doing that with natural language is also possible, but not the extent that it is with a programming language. With code, operations can be stacked, complex behavior (which would take dozens of sentences to explain properly in natural language) can be represented with a couple of lines of code, and special notation/syntax is developed to aid readability.

Because code is so malleable, you can take a poorly-written codebase and improve it little by little, incrementally, until you’re left with something which is pretty decent. You can’t really do the same with prose. You can make slight adjustments, but you can’t convert a terrible book into a great one by revising it repeatedly. Sometimes the whole point of good prose is to have good flow and that flow is often ruined by heavy editing.

Code differs from natural language in that code is used to control a computer. Natural language is used to communicate to another human. Thinking in a language that’s been designed to control computers isn’t natural for the human brain, that’s why programmers use tight feedback loops and iterative improvement to get things right. Thinking in natural language is (hopefully) natural for humans, that’s why converting your stream of thought directly into words, without too much alteration, leads to beautiful prose. To communicate effectively you need a sense of flow and emotional sensitivity that you just can’t improve by increasing the number of iterations.

Another difference is that, with software, you have proxies for measuring how well you’re doing. For a functional requirement (like adding a new feature, e.g.), you usually have a clear indicator of success: the feature either works or it doesn’t. For a non-functional requirement, you have benchmarks you can run to test resource usage, latency, frames per second, or some other metrics that you might find relevant. Writers don’t have such proxies. There’s no definitive way of knowing if your writing will resonate with anyone out there.

As a writer, you take pride in your style and ability to challenge convention. And while programmers can develop taste and personal style, that’s not exactly a hard requirement for writing good code.

Just like there are different kinds of writing, there are also different kinds of programming. But, what often ends up happening is that organizations tend to want to unify these differences so they don’t rely on certain programmers if they ever decide to leave. During review, code is often analyzed and systemically checked against a set of conventions: a colleague can tell you exactly what you need to do improve your code with regards to what’s considered good code within that organization. On the other hand, an editor can give you pointers, but they won’t be able to write for you and, with the exception of straightforward mistakes, they won’t be able to provide definitive suggestions.

There are similarities, of course. One thing that code- and prose-writing have in common is that both activities can be used as a means of exploration, not just as means to an end. Writers often write to organize their ideas and perhaps generate new ideas in the process of writing, because the act of putting thoughts into words acts a useful test for assessing one’s understating of the topic at hand. Programmers often write throwaway code to test out certain assumptions before investing weeks of work with a specific approach.

I’ve been thinking about these differences lately because I’ve noticed that I have a tendency to treat my prose like code. When I write a blog article, I always think that I can improve it on the next sitting. I think of drafts as unfinished projects that can always be tweaked. But, what I’ve found is that if I come up with something that just isn’t good enough, no amount of tweaking will do the job. At that point, starting from scratch and rethinking the entire thing is usually the right thing to do.