Programming and Writing

An underappreciated aspect of programming that is taught well and consistently in the context of writing is the need for iteration. Never publish something without rereading it first. Anything longer than an email, you should have a break between writing a first draft and taking a second look at it. Murder your darlings: learn to recognize things that you're proud of for the wrong reasons, things that other people won't appreciate, and throw them in the trash. The harder something is to write, the worse your first draft is likely to be, and the less likely you are to immediately recognize it when you finish.

As a programmer and aspiring writer, the two activities don&#x27;t really feel the same to me at all. I understand that there are many similarities. Building a piece of software and writing a novel are complex projects that span long periods of time, requires iteration, attention to detail, and cognizance of structure at varying scales, planning, etc....<p>But when I&#x27;m writing prose, it does not <i>feel</i> anything like writing code. I enjoy a beautiful line of written code, and can sit back and admire it for a while, before I get on with the business of hating it a week or three later, but it is nothing like the experience of feeling the taste of words on the tongue, of reaching into my own garbage sack of mental vomit to pull out gems to glimmer in the sun.

The two practices have quite a bit in common, including the need to break down a very large, hard-to-grasp problem (a novel or an application) into a set of smaller easier-to-solve problems (objects, functions, chapters) that fit together in a coherent whole.<p>I wrote a similar post when, after many years of software development, I finally got around to writing my first novel. <a href="https:&#x2F;&#x2F;adiamond.me&#x2F;2015&#x2F;01&#x2F;writing-and-programming&#x2F;" rel="nofollow">https:&#x2F;&#x2F;adiamond.me&#x2F;2015&#x2F;01&#x2F;writing-and-programming&#x2F;</a><p>The author is right in saying the key is really to show up and put in the work. That can be really hard for a lot of people, but programmers are already accustomed to it.<p>BTW, Vikram Chandra&#x27;s Geek Sublime also does a good job investigating the ties between writing code and writing prose. <a href="https:&#x2F;&#x2F;www.goodreads.com&#x2F;book&#x2F;show&#x2F;19353724-geek-sublime" rel="nofollow">https:&#x2F;&#x2F;www.goodreads.com&#x2F;book&#x2F;show&#x2F;19353724-geek-sublime</a><p>Chandra goes way back, pointing out that the generative grammar we use today to describe valid programming language constructs was first created 2500 years ago in India by a guy named Panini who fully and precisely described the structure of the entire Sanskrit language. There&#x27;s more on that here, if you&#x27;re interested: <a href="https:&#x2F;&#x2F;medium.com&#x2F;@dmitrypavluk&#x2F;we-should-thank-sanskrit-for-the-21st-century-e771b6c12f14" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@dmitrypavluk&#x2F;we-should-thank-sanskrit-fo...</a>

This is all true, but it&#x27;s a truth that omits the things that really matter. You can write a perfectly &quot;functioning&quot; novel that is dead upon the table. This is because a good novel has something beyond both its form and its content, an epi-phenomenon so to speak, which we can call &quot;magic&quot; or which we might say is the sum of the observations and feelings it gathers together from the total life experience of an individual and what they have managed to free from the deepest parts of their mind.<p>This can be as true of a Science Fiction novel as of any other. It doesn&#x27;t mean the work has to appear &quot;elevated&quot;, but it is the heart of the thing even in a fairly generic work.

As someone who has done both extensively, I humbly disagree. Writing involves thinking in a much less instrumental way, in my experience. In programming, there is often a clear pre-defined task, and the only question concerns the proper means of achieving that task. Writing, on the other hand, necessarily compels something much more dynamic &amp; non-linear at the level of composition.<p>I&#x27;d toss this one under the category of &#x27;wouldn&#x27;t it be nice&#x27;. It would be nice if writing and programming were similar. It would be nice to have a bridge from the sciences to arts and letters. But if such a bridge could be merely posited, well, this positing would already be common parlance.

Another difference, that I have found, is that programming is immediately rewarding because it&#x27;s verifiable. On the other hand, writing is without a feedback mechanism or a very delayed feedback or even subjective feedback, which can be painful and demotivating.

While I think there&#x27;s some truth to this, the author has it backwards in some kind of way. Or rather: The author misses an important epistemologic nuance.<p>&gt; One year ago I paused my programming life and started writing a novel, with the illusion that my new activity was deeply different than the previous one.<p>What&#x27;s implied here is the hope for a new experience.<p>But this can never be achieved: A programmer can never experience the writing of a novel as a non-programmer would.<p>Furthermore: Even the similarities can only be thought about from a programmers mind.<p>Imagine two writers discussing writing. One is a non-programmer, the other one is a programmer. Even if, after some exlpaining, the non-programmer and the programmer agree on the similarities, this can only happen because the non-programmer changed. They needed to learn some programming just to understand the similarities experienced by the programmer.<p>The non-programmer writer will never be a non-programmer-writer again.<p>The author experiences writing as very similar to programming precisely because they are a programmer.

There are many similitudes between writing novels and writing code, but the main difference is that it&#x27;s much easier to write bad novels than bad code.<p>Bad code doesn&#x27;t work.<p>There can be &quot;beautiful&quot; code that doesn&#x27;t work, but it&#x27;s pointless. And there are many instances of ugly, even abominable code, that does work, but... well, at least it works!<p>It&#x27;s very hard, and maybe impossible, to determine if a novel &quot;works&quot;. It may work for some people and not others. It may not work today and work in a hundred years, or the opposite.<p>We can never know. Least of all, the author herself.

I like this. Another phrase I&#x27;ve heard is that code is like poetry, but I think good code is more like an essay or book than like poetry. There&#x27;s structure, clarity, etc. It can be a little verbose if that helps make it easier to understand.

Summary of the blog post:<p>- Programming and writing are similar<p>- In writing you have rules (natural language grammar), in coding you also have rules (formal language grammar)<p>- In writing you build big things from small things. Small things must be nice. Big things must also be nice. Small things must align with big things. Like coding.<p>- If you don&#x27;t write you&#x27;re lazy. If you don&#x27;t code you&#x27;re lazy. Very similar.<p>- BUT actually writing and programming are completely different because in one you work for years on a single piece which cannot be changed after it&#x27;s released, so you torture yourself to make sure it&#x27;s as perfect as it can be without going insane -- and if you give up at any point along the journey then all of your efforts are basically wasted, WHILE in programming you have objective criteria by which you can judge if something is good enough, release working but imperfect parts of the final product along the way, modify things as you see fit at any point, and even if you decide to stop along the way -- it&#x27;s fine because your progress is incremental

The greatest commonality between writing and programming is that in those statements something happens where that something is a series of actions in furtherance of a common goal, a plot. Achieving such often requires refactoring and simplification. The work evolves towards a clarity that is polished only in hindsight and not immediately clear from the cover or readme.md file.<p>It is pretty easy to see how poor or grand some instance of software is if you look at it like a single complete product, like a novel.<p>As to the difference the article mentions revisions of a work. Games are most similar to novels in this regard. Popular game titles don’t evolve but instead release sequels. They may occasionally release patches or contain Easter eggs which is similar to published community support projects like workbooks and commentary from a works original author.

It&#x27;s an interesting perspective, but from what little creative work I have done I would say the big difference is programming is very logical, very precise, and creative work is very expressive, and very, very imprecise. Creative work really requires you to listen to how you feel about the final product, how it sounds, how it is experienced, while programming is really about being organized and correct. I suppose there is some overlap, after all programmers need to think about user experiences as well, but that&#x27;s not the same thing.

Maciej Ceglowski&#x27;s critique about pg&#x27;s &quot;Hackers and Painters&quot; applies here: The biggest difference between programming and writing is that one of them can get you laid.

I mostly agree with @antirez&#x27;s hypothesis points, because I am also writing novel these days, I think on my journey I need to make strict structure, perhaps if any, something like writing software that has feature to make functional novel writing works because in programming I am fan of FP, not imperative nor OOP.<p>btw, Congratulations.. Looking forward to your sci-fi novel @antirez<p>Anyway, I love how redis evolved, and its design from the beginning from @antirez. That&#x27;s why I am eagerly to read his another craft.

I&#x27;ve always thought of programs as &quot;functional prose&quot;. The notion of software engineering may have hidden this somewhat in the past few years, but the two domains have very much in common. Including various strategies to tackle them.<p>(From which follows somewhat implicitely: Whenever you set up a process for shared project development, also ask yourself, would this work for a shared writing effort?)

Having done both, in my experience the two have almost nothing in common, especially in process. Some of the most famous novels have no real structure at all, solve no problem, and don&#x27;t adhere to any consistent rules of construction&#x2F;grammar&#x2F;style.<p>And: a &#x27;successful&#x27; program is easy to spot; a &#x27;successful&#x27; novel defies that, beyond the most superficial (and ultimately subjective) measures.

Here&#x27;s a technique for revising and improving prose that has no analog in programming: reading the text aloud to yourself.<p>This is the best way to fix a first draft, of short texts at least, without having to wait for it to cool off first. Often an email must be sent quickly, with no time to set the message aside. So always before I hit Send, I invest a minute to pronounce the text aloud, or at least under my breath while moving my lips.<p>I&#x27;m often amazed at the obvious typos I catch this way. As well, my oral fluency -- which appears to come from a whole different place than my written voice -- can often improve entire sentences with better word choices or figures of speech that emerge from my mouth spontaneously as I speak the text back.<p>Voilà! A much better second draft of the message in a very efficient manner.<p>And yes, I read this post aloud before I pressed &quot;add comment.&quot; I hope it doesn&#x27;t betray me.

I remember Brandon Sanderson also outlined that these jobs are similar, and explicitly mentioned that usually it is difficult to do them at the same time. Both programming and writing activate the same thought routines and therefore do not feel like one of them helps you rest from the other.

Will it be a single-threaded story with minimal cruft?

A colleague that once worked on the original AT&amp;T billing system used to say:<p>“The first time you write, you’re learning about the problem, the second time, the solution, and then finally, you’re continuously polishing it.”<p>Or something like that. It was years ago.

&gt; Code is not prose written in a natural language, yet it has a set of fixed rules (a grammar), certain forms that most programmers will understand as natural and others that, while formally correct, will sound hard to grasp.<p>The prose has to &quot;execute&quot; in the interpreter of the reader&#x27;s imagination. Not much stack space there: go easy on the pronouns.

Looking fwd to your novel&#x27;s release, @antirez!

&quot;My hypothesis is that this initial design will greatly inform what will happen later: growing organically something that has a good initial structure will result in a better system, even after years of distance from the original creation&quot;<p>Very true, but also not something you should focus on too early.<p>You&#x27;ll need a lot of experience for this initial design phase to be really fruitful.

I see both as incantations that are run in wildly different execution environments, and thus there should be lots of overlap during the creation process. Code is a magic spell that executes in a mostly deterministic digital system. While writing is a magic spell that executes in a very non deterministic biological system.

&gt; Sentences must be well written, but the overall structure and relationship between the parts is also crucial.<p>He does not consider that writing is an art form, a means of creative expression, not just to get you idea across. For instance, one of the greatest novels &quot;The Devil to Pay in the Backlands&quot; is confusing and hard to read.

I just recently was noting similarities between my strategies for programming and for writing: <a href="https:&#x2F;&#x2F;www.finl.xyz&#x2F;2021&#x2F;04&#x2F;07&#x2F;looking-at-rust-is-already-beneficial&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.finl.xyz&#x2F;2021&#x2F;04&#x2F;07&#x2F;looking-at-rust-is-already-b...</a>

The comment below the post saying a ~500 words &quot;wall of text&quot; is off-putting. :facepalm:

I’m embarking on the same journey and this piece increases my confidence that the novel(s) I’ve been planning through my 20 year programming career will actually come to fruition. It’s scary at times because I haven’t written fiction since high school.

Cool! Some of my favorite sci-fi writers are programmers or former programmers — Andy Weir, Charlie Stross, Dennis Taylor.<p>Although that may have more to do with me (as a programmer) than with any relationship between fiction and software.

The similarity between the two probably helps explain the plethora of programming blogs versus the absolute desert that is the hardware&#x2F;circuit based blogosphere....

It always seemed to me that a better analogy to programming, at least programming for money (is there any other kind?), is writing for and producing a magazine.

On writing.<p>&gt; I believe programming, in this regard, can learn something from writing: when writing the first core of a new system, when the original creator is still alone, isolated, able to do anything, she should pretend that this first core is her only bullet.<p>@antirez: why `she` and not `they`? I know you are not a native English speaker (so am I), but I believe that&#x27;s not the case here and was likely written so intentionally.

&gt; I believe programming, in this regard, can learn something from writing: when writing the first core of a new system, when the original creator is still alone, isolated, able to do anything, she should pretend that this first core is her only bullet. During the genesis of the system she should rewrite this primitive kernel again and again<p>This is a very subtle and interesting point. This notion of the &#x27;primitive kernel&#x27; that is hard to change, is the problem of how much abstraction to invest in, at the beginning of a feature or project. It seems to always be a balance between doing what is needed for the immediate specifications, and doing what is needed for future reusability and extensibility of that same piece of code. In other words, how much should this piece of software be abstracted for future reusability?<p>It is tempting to think that highly abstracted code is overkill. However, abstracting code on the first introduction of a feature, allows for this &quot;primitive kernel&quot; to be as solid as possible, such that it doesn&#x27;t need to change often. There is an illusion of doing too much work by considering all the use cases before needing them, but what I think really happens is that<p>*the longer you put off abstracting something (i.e. copying code instead) the more expensive the abstraction will be once you get to it.*<p>So the first abstraction, nicely put in the quote above, &quot;During the genesis of the system she should rewrite this primitive kernel again and again&quot;, illustrates why it should be done right the first time around. It is cheaper to do so on the first try when nobody is using the abstraction. Compare this to a later time, a time when the kernel is already being used by lots of other components, now you have to take those use cases with their exceptions into account, making the process of abstracting more complicated and risky.<p>*NOT abstracting as much as possible, is setting the software up for an inevitable increase in complexity, and therefore cost in effort to reduce it.*<p>Summarizing: abstracting code on the first pass is avoiding the increase in cost of that same abstraction if you wait until there are multiple concrete cases of it. I suspect it&#x27;s a function of how many concrete cases there are to abstract, multiplied by environment&#x27;s stability (once it&#x27;s shipped, abstracting gets even more difficult and costly).