9 ms·

Programming and Writing

217 points by blopeur 5y ago

block_dagger 5y ago
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.
austincheney 5y ago
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. 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. 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.
- mjw1007 5y ago
  On "refactoring" in novels: On many occasions I've heard an author say something like "I got half-way through the book and I found out that one of the characters didn't want to do the thing I'd planned for them, so I had to deal with the plot changing in this unexpected way." I've only once heard an author say "so I had to go back and rewrite the character until they were the sort of person that did want to do the thing I'd planned for them."
  - chipotle_coyote 5y ago
    While this is (probably obviously!) very subjective from author to author, I think "the character didn't want to do the thing I'd planned for them" is a good thing story-wise, because it means you really understand your character. The flip side of that, though, is "the character didn't want to do the thing" isn't necessarily a sign that the character shouldn't do the thing. In general, your protagonist is going to have to be pushed out of their comfort zone during a story, and they are not going to like it. Frodo did not start out The Lord of the Rings thinking "throwing this ring into a volcano in Mordor sounds like a lovely few weeks' vacation."
deleted 5y ago
[deleted]
marsven_422 5y ago
Another commonality is that writing and programming uses the same type of mental energy thus after eight ours of programming you will most likely not have energy for 2h of writing.
magpi3 5y ago
It'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's not the same thing.
- qsort 5y ago
  There is definitely some creativity involved in programming tasks, and meticulous calculus when writing fiction as well. Deciding how to structure your code is half logic and half aesthetics, the fact that we spend a large chunk of our time refactoring, i.e. switching around pieces of code so that the code does the same thing is a testament to this. More broadly, I feel like "X is like Y"-type articles are somewhat of a Rorschach test. Things we are experienced at are by definition things we spent a lot of time doing. It's inevitable one will try to self-reflect and draw parallels.
- karlerss 5y ago
  I strongly disagree. When building a software product for humans, the first question I ask is "how should it feel?". In the end, this is the only thing that matters. The "feel" summarizes all "technical" aspects too - correctness, reliability etc. While developing a product, I never stop asking.
- marcus_holmes 5y ago
  Getting a joint right when making furniture from wood requires a lot of logic and precision, probably more than coding in my experience. But this is the difference between "art" and "craft". The art is deciding what to build, how it should look and feel. This part is imprecise and emotional. It depends more on talent than practice, and is the bit that needs a muse or inspiration. The craft bit is building it. This part is logical, precise, and needs to be done competently so it doesn't obscure the "art" part (great art can be ruined by bad craft, but good craft with no art is just boring). This needs lots and lots of practice. This duality applies to writing, coding, sketching, music, movies, any creative practice.
diamondap 5y ago
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. I wrote a similar post when, after many years of software development, I finally got around to writing my first novel. https://adiamond.me/2015/01/writing-and-programming/ https://adiamond.me/2015/01/writing-and-programming/ 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. BTW, Vikram Chandra's Geek Sublime also does a good job investigating the ties between writing code and writing prose. https://www.goodreads.com/book/show/19353724-geek-sublime https://www.goodreads.com/book/show/19353724-geek-sublime 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's more on that here, if you're interested: https://medium.com/@dmitrypavluk/we-should-thank-sanskrit-for-the-21st-century-e771b6c12f14 https://medium.com/@dmitrypavluk/we-should-thank-sanskrit-fo...
neolefty 5y ago
Cool! Some of my favorite sci-fi writers are programmers or former programmers — Andy Weir, Charlie Stross, Dennis Taylor. Although that may have more to do with me (as a programmer) than with any relationship between fiction and software.
- criddell 5y ago
  Have you read Weir's Project Hail Mary yet? If so, did you like it as much as The Martian?
  - newsbinator 5y ago
    I liked Project Hail Mary more than The Martian, possibly because it's quite a bit more imaginative, and because the main character isn't a perfect person, so it's easier to relate.
chrisweekly 5y ago
Looking fwd to your novel's release, @antirez!
scandox 5y ago
This is all true, but it's a truth that omits the things that really matter. You can write a perfectly "functioning" 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 "magic" 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. This can be as true of a Science Fiction novel as of any other. It doesn't mean the work has to appear "elevated", but it is the heart of the thing even in a fairly generic work.
- antirez 5y ago
  I agree with that. For me this part is about doing something I never did while programming, but I did as an amateur actor for a couple of years. That is: what happens on the page needs to surprise you, like if events and words flow as you are only the tool, but happen independently of your will. It's a complex state to achieve, but I think that if you fail to do it, the reader can tell.
  - pcmaffey 5y ago
    Both are dealing with the “magic” of transformation. Programs transform data. Fiction transforms desire.
stephc_int13 5y ago
"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" Very true, but also not something you should focus on too early. You'll need a lot of experience for this initial design phase to be really fruitful.
- rkangel 5y ago
  My view is that iteration of the core design is equally important to the the iteration that's done on the rest of it. The difference is that each 'product' in a field is a new iteration on the core design. This is what makes experienced engineers so valuable over inexperienced ones - the experienced ones know the history and know the previous iterations so that they can make the 'right' next step.
bitwize 5y ago
Maciej Ceglowski's critique about pg's "Hackers and Painters" applies here: The biggest difference between programming and writing is that one of them can get you laid.
- hansvm 5y ago
  Writers get laid sometimes too.
Ozzie_osman 5y ago
I like this. Another phrase I've heard is that code is like poetry, but I think good code is more like an essay or book than like poetry. There's structure, clarity, etc. It can be a little verbose if that helps make it easier to understand.
- quasit1 5y ago
  I feel as if it depends a lot on the code. I sometimes read code for fun. Some code read like an essay, some like a book and other code read like a collection of poetry. So I feel as if all 3 can apply, sometimes some of them at the same time.
say_it_as_it_is 5y ago
Will it be a single-threaded story with minimal cruft?
- antirez 5y ago
  That's a good one :D Maybe there is an analogy btw: I don't like sentences that are written using picky adjectives and very long sequences when nothing happens. However the story is, unlike Redis, quite articulated.
hegelguy 5y ago
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 & non-linear at the level of composition. I'd toss this one under the category of 'wouldn't it be nice'. 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.
- jsight 5y ago
  Computer programs can often be structured in nearly infinite ways while accomplishing the same (or nearly the same) objective. Writing can often be organized and worded in nearly infinite ways while getting across the (or nearly the same) message. There are some pretty strong similarities. Writer's block and programmer's block correlate. EDIT: Sadly, writing has no compiler to tell me that I overlooked the word "block" after "programmer's".
  - jonnycomputer 5y ago
    Sure, the goal of writing a piece of software is to have a piece of software, and the goal of writing a novel is to have a novel. That's trivial, though. When I write a piece of software, I have more concrete goals that just write a piece of software. I'll usually have a goal (a TODO app), and maybe some ideas about which features. Sure, I might not know exactly how I'll get there, and along the way I might come up with the new ideas, but you don't start with the goal of writing a TODO app and end up with an application that processes DICOM images. With writing a novel, well, very often the writer has no idea where it will go. This varies--some authors spend a lot of time planning everything out, scene by scene, chapter by chapter. But a lot of authors discovery write. That's what I do.. When I write, I'm waiting, hoping, to surprise myself. I want to go---oh what the hell is that!? When programming, I go, Oh, I need to do that, to get this working. While writing, I'm constantly feeling my way through each word. I re-read it, outloud, tasting each word, and constantly asking myself: how does it make me feel?
scaraffe 5y ago
Another difference, that I have found, is that programming is immediately rewarding because it'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.
- jaredsohn 5y ago
  Agree that programming has that aspect. Just knowing that code does what you expected it to do at the technical level is great. But ultimately when you write code it was done for some purpose so a similar delayed / subjective feedback mechanism is still relevant (i.e. does it solve problems for users? Does it work with real data? Does it scale?)
- vidarh 5y ago
  It's one of the reasons I self-published my novel. Of course it may well be it's not good enough and that it would never in a thousand years get picked up by a publisher. But I was certainly not willing to spend months or years even finding out if a publisher wanted it, when I could get it into the hands of readers myself within a few months of finishing writing. [if you want to maximise the chance of "making it big" traditional publishers are more likely to be able to make that happen, but for my part it's a hobby first and foremost, so that wasn't really a consideration I cared about at the odds of that are extremely poor anyway]
- greenie_beans 5y ago
  Interesting, never thought of it like this. Personally I like the no-feeback aspect of writing because I have to find it in myself to keep on writing. Makes it much more rewarding and personal, private, not doing it for the social media likes/brain chemicals. The ultimate form of delayed gratification: never
dkarl 5y ago
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.
- deleted 5y ago
  [deleted]
- pcmaffey 5y ago
  To carry the metaphor, iteration is not just about refactoring and optimizing, it’s mostly about debugging. Finding what isn’t working and trying something new. I wrote about how I use my programming logic to “debug my art”.* The same can be applied to writing. *https://www.pcmaffey.com/debugging-your-art https://www.pcmaffey.com/debugging-your-art
  - StandardFuture 5y ago
    Great analogy! But it's probably all three: debugging (is it correct?), refactoring (readability), optimizing (succinctness). And likely in that order. Exactly the priority ordering as in programming also. Will keep this in mind!
- jborichevskiy 5y ago
  > Stephen King had this to say on the art of writing in his book On Writing: A Memoir of the Craft: “Kill your darlings, kill your darlings, even when it breaks your egocentric little scribbler's heart, kill your darlings." https://www.masterclass.com/articles/what-does-it-mean-to-kill-your-darlings#what-are-the-origins-of-the-phrase-kill-your-darlings https://www.masterclass.com/articles/what-does-it-mean-to-ki...
  - 5y ago
Garlef 5y ago
While I think there's some truth to this, the author has it backwards in some kind of way. Or rather: The author misses an important epistemologic nuance. > 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. What's implied here is the hope for a new experience. But this can never be achieved: A programmer can never experience the writing of a novel as a non-programmer would. Furthermore: Even the similarities can only be thought about from a programmers mind. 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. The non-programmer writer will never be a non-programmer-writer again. The author experiences writing as very similar to programming precisely because they are a programmer.
- jonnycomputer 5y ago
  >The author experiences writing as very similar to programming precisely because they are a programmer. Sure. But the veracity of the comparison doesn't depend on the prerequisites to make the comparison.
  - Garlef 5y ago
    How can there be a comparison without the prerequisites? The words don't carry any meaning without context. You could say "the veracity does not depend on the prerequisites" to mean "whoever enters the context will agree to the comparison".
    - jonnycomputer 5y ago
      Look, I have two objects in a locked room. They are in fact very similar objects. They have the same weight, same visual presentations, same physical composition, up to reasonable limits of measurement. In short they are very similar objects. Your approach says, the object is only similar iff someone has the key to the room and observes the two objects. Sure, the only way to tell that they are similar is to for someone or something to make the observation. But its quite something different to say that they are similar only because someone observed the two objects. Maybe that's true, but that's a pretty wild claim.
bambax 5y ago
There are many similitudes between writing novels and writing code, but the main difference is that it's much easier to write bad novels than bad code. Bad code doesn't work. There can be "beautiful" code that doesn't work, but it's pointless. And there are many instances of ugly, even abominable code, that does work, but... well, at least it works! It's very hard, and maybe impossible, to determine if a novel "works". It may work for some people and not others. It may not work today and work in a hundred years, or the opposite. We can never know. Least of all, the author herself.
- closed 5y ago
  > Bad code doesn't work. > It's very hard, and maybe impossible, to determine if a novel "works". I wonder if there is a an assumption here about what it means to "work" vs to be "bad". Psychologically, maybe it's helpful to view each person as their own interpreter, and there is more variation there compared to (e.g.) a specific python interpreter. But even in python I could write totally not-python code, and have the python interpreter run it (e.g. by writing a codec). And I could write beautiful code that throws an error, and have a person debug it for <some_purpose>, and in meeting that purpose it might be working. I think the challenge here is that "work" is being defined in a narrow, technical sense for code, but is recognized in a much broader, social/cognitive sense, for novels!
  - jonnycomputer 5y ago
    There are no bugs, only unrealized intentions.
- vidarh 5y ago
  There are startups trying to quantify what "works" for novels [1]. Of course they're just scraping the barest surface of what "works" means as of yet with attempts to analyse pacing and use of different word types and how characters are described etc. I've tested some while writing my own novel, and it was more "interesting" than useful at this point, but I might give it another shot with novel #2 to contrast and compare the two. It'll be interesting to see how those tools evolve, though. [1] authors.ai is one example.
raitucarp 5y ago
I mostly agree with @antirez'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. btw, Congratulations.. Looking forward to your sci-fi novel @antirez Anyway, I love how redis evolved, and its design from the beginning from @antirez. That's why I am eagerly to read his another craft.
jonnycomputer 5y ago
As a programmer and aspiring writer, the two activities don'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.... But when I'm writing prose, it does not feel 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.
- k__ 5y ago
  I write (technical) articles and develop software. Good devs can be bad writers and the other way around. But good code is as good writing. It's a planned endevour which takes a few iterations to get right. Most people who code bad and/or write bad are doing so because ther code and text are just streams of thoughts typed down as they had them. Sure, iteration can fix a bug here and there, but if their thoughts don't follow a red line, nobody can understand what they wanted to create.
- kian 5y ago
  I feel like programming in a point-free style is the closest to writing prose that coding gets for me. A composition of named functions in sequence is essentially a functional sentence. The ability to effortlessly re-arrange the product on the page is what gives it the flavor -- written imperatively and in detail, that flavor is either lost, or diluted homeopathically amongst the much more verbose format.
andreygrehov 5y ago
On writing. > 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. @antirez: why `she` and not `they`? I know you are not a native English speaker (so am I), but I believe that's not the case here and was likely written so intentionally.
- antirez 5y ago
  It is just one of the choices for more inclusive and less standard language.
- moshmosh 5y ago
  One solution people have come up with for the perceived unfairness of male pronouns doing double-duty as neuter pronouns in English is to sometimes use female ones instead. The down side of this is that it leaves us with three possible neuter pronoun sets, at least two of which are just about guaranteed to bother someone. Using exclusively male pronouns will obviously bother some people, now, else this wouldn't be an issue in the first place. Using female ones will bother some people (either for ideological reasons or, for those who grew up on "male is what you use for the general case", by tripping them up as they try to figure out who in particular is being referred to). "They" and such are safer but you still get the occasional (incorrect) pedant complaining about that usage.
  - andreygrehov 5y ago
    Thanks for the explanation. I'm not a gender pronouns pedant in any way, my question was asked purely from an educational perspective. My native language is Russian, which is generally a gendered (masculine/feminine/neuter) language. Nouns have gender. It mostly follows the spelling of the words - i.e. if a word ends with a certain vowel. Sometimes it doesn't work that way, mostly with loanwords. In other cases the historical form of the word did match a pattern, and was assigned a gender accordingly - and then changed (e.g. by re-loaning it in a more accurate spelling), and no longer fits. When that happens, people will use the more "appropriate" rather than the "right" gender in colloquial speech, and eventually it becomes the new standard, collecting the mismatch. A good example of this is the Russian word "coffee". When it was first loaned back in 18th century, it was "kofiy" - and in Russian, that is definitely masculine. Eventually it got re-loaned as "kofe", which would normally be neuter; but the masculine gender assignment stayed from past spelling. In the dictionaries, that is - in practice treating the word as neuter became one of the common incorrect colloquialisms, just because it doesn't "look" masculine. Language purists fought this for several decades, and eventually lost: it's still nominally masculine, but neuter is considered an "accepted variant" in modern dictionaries. So to a Russian speaker, say, New York and Texas are masculine, while California and Florida are feminine. So, when I read "she" in @antirez's article, I was immediately confused, like, did I miss a character introduced in the previous paragraph or ...who is _she_? In my writings, instead of saying "he", "she", "they", I try to call people by the exact meaning of what I'm writing about, eg engineer, manager, programmer, etc. No idea why it's not THE way to end all the pronouns dilemmas in English.
aledalgrande 5y ago
The comment below the post saying a ~500 words "wall of text" is off-putting. :facepalm:
nocturnal_pt 5y ago
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.
kingsuper20 5y ago
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.
masswerk 5y ago
I've always thought of programs as "functional prose". 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. (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?)
- WorldMaker 5y ago
  I tend to think of code much more like "poetry" than "prose". Programming languages provide required "meter", "rhyme", and other similar "format requirements" like poetry styles. Style guides and lint tools even further "refine" the "poetry style" agreed on by a development effort. I haven't found any particular use for this analogy for deep insights (there rarely were collectives focused on long form poetry in history, depending on what you think of oral storytelling traditions and/or if you agree with conspiracy theories that the output attributed to William Shakespeare was more of a collective effort than a lone auteur), but I still find it an interesting analogy.
- proc0 5y ago
  Yeah, I have referred to asking questions as 'mind queries', if they're technical in nature, since it's just trying to acquire a piece of knowledge.
dhosek 5y ago
I just recently was noting similarities between my strategies for programming and for writing: https://www.finl.xyz/2021/04/07/looking-at-rust-is-already-beneficial/ https://www.finl.xyz/2021/04/07/looking-at-rust-is-already-b...
faustlast 5y ago
> Sentences must be well written, but the overall structure and relationship between the parts is also crucial. 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 "The Devil to Pay in the Backlands" is confusing and hard to read.
- antirez 5y ago
  In this case for the sentence to "work" is that it's confusing, anything that creates the effect (explicitly wanted or not) works. Like the single sentence of a program participating to an obfuscation programming context must work in order to create confusion. I left the artistic part of the process out of the post because in the artistic process the similarities are very far, IMHO. I think I use a creative process while programming as well, but is not alike to the one used to write.
proc0 5y ago
> 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 This is a very subtle and interesting point. This notion of the 'primitive kernel' 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? It is tempting to think that highly abstracted code is overkill. However, abstracting code on the first introduction of a feature, allows for this "primitive kernel" to be as solid as possible, such that it doesn'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 *the longer you put off abstracting something (i.e. copying code instead) the more expensive the abstraction will be once you get to it.* So the first abstraction, nicely put in the quote above, "During the genesis of the system she should rewrite this primitive kernel again and again", 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. *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.* 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's a function of how many concrete cases there are to abstract, multiplied by environment's stability (once it's shipped, abstracting gets even more difficult and costly).
stakkur 5y ago
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't adhere to any consistent rules of construction/grammar/style. And: a 'successful' program is easy to spot; a 'successful' novel defies that, beyond the most superficial (and ultimately subjective) measures.
smitty1e 5y ago
> 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. The prose has to "execute" in the interpreter of the reader's imagination. Not much stack space there: go easy on the pronouns.
deleted 5y ago
[deleted]
withinboredom 5y ago
A colleague that once worked on the original AT&T billing system used to say: “The first time you write, you’re learning about the problem, the second time, the solution, and then finally, you’re continuously polishing it.” Or something like that. It was years ago.
TomDavey 5y ago
Here's a technique for revising and improving prose that has no analog in programming: reading the text aloud to yourself. 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. I'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. Voilà! A much better second draft of the message in a very efficient manner. And yes, I read this post aloud before I pressed "add comment." I hope it doesn't betray me.
- themacguffinman 5y ago
  Arguably writing tests is the analog of reading prose aloud. It forces you to think through cases as a user of your code and often helps catch bugs as a side effect of your thinking than the test result. Or perhaps a closer analog is the rubber duck where being forced to explain your problem leads to thinking more clearly about it and solving it.
yourabstraction 5y ago
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.
phlipski 5y ago
The similarity between the two probably helps explain the plethora of programming blogs versus the absolute desert that is the hardware/circuit based blogosphere....
tyrrrzhn 5y ago
Summary of the blog post: - Programming and writing are similar - In writing you have rules (natural language grammar), in coding you also have rules (formal language grammar) - 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. - If you don't write you're lazy. If you don't code you're lazy. Very similar. - 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's released, so you torture yourself to make sure it'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's fine because your progress is incremental
- polypodiopsi 5y ago
  I consider this sort of polemic, reductive summary utterly impolite. You left out the really important point: the suggestion that writing code could benefit from approaching it like one had only one shot at it, instead of patching smth. together that might or might not be improved upon incrememtally later on. This sort of summary you did there is not in good faith.

217 points by blopeur 5y ago

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.

austincheney 5y ago

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. 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. 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.

mjw1007 5y ago
On "refactoring" in novels: On many occasions I've heard an author say something like "I got half-way through the book and I found out that one of the characters didn't want to do the thing I'd planned for them, so I had to deal with the plot changing in this unexpected way." I've only once heard an author say "so I had to go back and rewrite the character until they were the sort of person that did want to do the thing I'd planned for them."
- chipotle_coyote 5y ago
  While this is (probably obviously!) very subjective from author to author, I think "the character didn't want to do the thing I'd planned for them" is a good thing story-wise, because it means you really understand your character. The flip side of that, though, is "the character didn't want to do the thing" isn't necessarily a sign that the character shouldn't do the thing. In general, your protagonist is going to have to be pushed out of their comfort zone during a story, and they are not going to like it. Frodo did not start out The Lord of the Rings thinking "throwing this ring into a volcano in Mordor sounds like a lovely few weeks' vacation."

deleted 5y ago

[deleted]

marsven_422 5y ago

Another commonality is that writing and programming uses the same type of mental energy thus after eight ours of programming you will most likely not have energy for 2h of writing.

magpi3 5y ago

It'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's not the same thing.

qsort 5y ago
There is definitely some creativity involved in programming tasks, and meticulous calculus when writing fiction as well. Deciding how to structure your code is half logic and half aesthetics, the fact that we spend a large chunk of our time refactoring, i.e. switching around pieces of code so that the code does the same thing is a testament to this. More broadly, I feel like "X is like Y"-type articles are somewhat of a Rorschach test. Things we are experienced at are by definition things we spent a lot of time doing. It's inevitable one will try to self-reflect and draw parallels.
karlerss 5y ago
I strongly disagree. When building a software product for humans, the first question I ask is "how should it feel?". In the end, this is the only thing that matters. The "feel" summarizes all "technical" aspects too - correctness, reliability etc. While developing a product, I never stop asking.
marcus_holmes 5y ago
Getting a joint right when making furniture from wood requires a lot of logic and precision, probably more than coding in my experience. But this is the difference between "art" and "craft". The art is deciding what to build, how it should look and feel. This part is imprecise and emotional. It depends more on talent than practice, and is the bit that needs a muse or inspiration. The craft bit is building it. This part is logical, precise, and needs to be done competently so it doesn't obscure the "art" part (great art can be ruined by bad craft, but good craft with no art is just boring). This needs lots and lots of practice. This duality applies to writing, coding, sketching, music, movies, any creative practice.

diamondap 5y ago

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. I wrote a similar post when, after many years of software development, I finally got around to writing my first novel. https://adiamond.me/2015/01/writing-and-programming/ https://adiamond.me/2015/01/writing-and-programming/ 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. BTW, Vikram Chandra's Geek Sublime also does a good job investigating the ties between writing code and writing prose. https://www.goodreads.com/book/show/19353724-geek-sublime https://www.goodreads.com/book/show/19353724-geek-sublime 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's more on that here, if you're interested: https://medium.com/@dmitrypavluk/we-should-thank-sanskrit-for-the-21st-century-e771b6c12f14 https://medium.com/@dmitrypavluk/we-should-thank-sanskrit-fo...

neolefty 5y ago

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

criddell 5y ago
Have you read Weir's Project Hail Mary yet? If so, did you like it as much as The Martian?
- newsbinator 5y ago
  I liked Project Hail Mary more than The Martian, possibly because it's quite a bit more imaginative, and because the main character isn't a perfect person, so it's easier to relate.

chrisweekly 5y ago

Looking fwd to your novel's release, @antirez!

scandox 5y ago

This is all true, but it's a truth that omits the things that really matter. You can write a perfectly "functioning" 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 "magic" 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. This can be as true of a Science Fiction novel as of any other. It doesn't mean the work has to appear "elevated", but it is the heart of the thing even in a fairly generic work.

antirez 5y ago
I agree with that. For me this part is about doing something I never did while programming, but I did as an amateur actor for a couple of years. That is: what happens on the page needs to surprise you, like if events and words flow as you are only the tool, but happen independently of your will. It's a complex state to achieve, but I think that if you fail to do it, the reader can tell.
- pcmaffey 5y ago
  Both are dealing with the “magic” of transformation. Programs transform data. Fiction transforms desire.

stephc_int13 5y ago

"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" Very true, but also not something you should focus on too early. You'll need a lot of experience for this initial design phase to be really fruitful.

rkangel 5y ago
My view is that iteration of the core design is equally important to the the iteration that's done on the rest of it. The difference is that each 'product' in a field is a new iteration on the core design. This is what makes experienced engineers so valuable over inexperienced ones - the experienced ones know the history and know the previous iterations so that they can make the 'right' next step.

bitwize 5y ago

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

hansvm 5y ago
Writers get laid sometimes too.

Ozzie_osman 5y ago

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

quasit1 5y ago
I feel as if it depends a lot on the code. I sometimes read code for fun. Some code read like an essay, some like a book and other code read like a collection of poetry. So I feel as if all 3 can apply, sometimes some of them at the same time.

say_it_as_it_is 5y ago

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

antirez 5y ago
That's a good one :D Maybe there is an analogy btw: I don't like sentences that are written using picky adjectives and very long sequences when nothing happens. However the story is, unlike Redis, quite articulated.

hegelguy 5y ago

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 & non-linear at the level of composition. I'd toss this one under the category of 'wouldn't it be nice'. 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.

jsight 5y ago
Computer programs can often be structured in nearly infinite ways while accomplishing the same (or nearly the same) objective. Writing can often be organized and worded in nearly infinite ways while getting across the (or nearly the same) message. There are some pretty strong similarities. Writer's block and programmer's block correlate. EDIT: Sadly, writing has no compiler to tell me that I overlooked the word "block" after "programmer's".
- jonnycomputer 5y ago
  Sure, the goal of writing a piece of software is to have a piece of software, and the goal of writing a novel is to have a novel. That's trivial, though. When I write a piece of software, I have more concrete goals that just write a piece of software. I'll usually have a goal (a TODO app), and maybe some ideas about which features. Sure, I might not know exactly how I'll get there, and along the way I might come up with the new ideas, but you don't start with the goal of writing a TODO app and end up with an application that processes DICOM images. With writing a novel, well, very often the writer has no idea where it will go. This varies--some authors spend a lot of time planning everything out, scene by scene, chapter by chapter. But a lot of authors discovery write. That's what I do.. When I write, I'm waiting, hoping, to surprise myself. I want to go---oh what the hell is that!? When programming, I go, Oh, I need to do that, to get this working. While writing, I'm constantly feeling my way through each word. I re-read it, outloud, tasting each word, and constantly asking myself: how does it make me feel?

scaraffe 5y ago

Another difference, that I have found, is that programming is immediately rewarding because it'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.

jaredsohn 5y ago
Agree that programming has that aspect. Just knowing that code does what you expected it to do at the technical level is great. But ultimately when you write code it was done for some purpose so a similar delayed / subjective feedback mechanism is still relevant (i.e. does it solve problems for users? Does it work with real data? Does it scale?)
vidarh 5y ago
It's one of the reasons I self-published my novel. Of course it may well be it's not good enough and that it would never in a thousand years get picked up by a publisher. But I was certainly not willing to spend months or years even finding out if a publisher wanted it, when I could get it into the hands of readers myself within a few months of finishing writing. [if you want to maximise the chance of "making it big" traditional publishers are more likely to be able to make that happen, but for my part it's a hobby first and foremost, so that wasn't really a consideration I cared about at the odds of that are extremely poor anyway]
greenie_beans 5y ago
Interesting, never thought of it like this. Personally I like the no-feeback aspect of writing because I have to find it in myself to keep on writing. Makes it much more rewarding and personal, private, not doing it for the social media likes/brain chemicals. The ultimate form of delayed gratification: never

dkarl 5y ago

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.

deleted 5y ago
[deleted]
pcmaffey 5y ago
To carry the metaphor, iteration is not just about refactoring and optimizing, it’s mostly about debugging. Finding what isn’t working and trying something new. I wrote about how I use my programming logic to “debug my art”.* The same can be applied to writing. *https://www.pcmaffey.com/debugging-your-art https://www.pcmaffey.com/debugging-your-art
- StandardFuture 5y ago
  Great analogy! But it's probably all three: debugging (is it correct?), refactoring (readability), optimizing (succinctness). And likely in that order. Exactly the priority ordering as in programming also. Will keep this in mind!
jborichevskiy 5y ago
> Stephen King had this to say on the art of writing in his book On Writing: A Memoir of the Craft: “Kill your darlings, kill your darlings, even when it breaks your egocentric little scribbler's heart, kill your darlings." https://www.masterclass.com/articles/what-does-it-mean-to-kill-your-darlings#what-are-the-origins-of-the-phrase-kill-your-darlings https://www.masterclass.com/articles/what-does-it-mean-to-ki...
- 5y ago

Garlef 5y ago

While I think there's some truth to this, the author has it backwards in some kind of way. Or rather: The author misses an important epistemologic nuance. > 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. What's implied here is the hope for a new experience. But this can never be achieved: A programmer can never experience the writing of a novel as a non-programmer would. Furthermore: Even the similarities can only be thought about from a programmers mind. 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. The non-programmer writer will never be a non-programmer-writer again. The author experiences writing as very similar to programming precisely because they are a programmer.

jonnycomputer 5y ago
>The author experiences writing as very similar to programming precisely because they are a programmer. Sure. But the veracity of the comparison doesn't depend on the prerequisites to make the comparison.
- Garlef 5y ago
  How can there be a comparison without the prerequisites? The words don't carry any meaning without context. You could say "the veracity does not depend on the prerequisites" to mean "whoever enters the context will agree to the comparison".
  - jonnycomputer 5y ago
    Look, I have two objects in a locked room. They are in fact very similar objects. They have the same weight, same visual presentations, same physical composition, up to reasonable limits of measurement. In short they are very similar objects. Your approach says, the object is only similar iff someone has the key to the room and observes the two objects. Sure, the only way to tell that they are similar is to for someone or something to make the observation. But its quite something different to say that they are similar only because someone observed the two objects. Maybe that's true, but that's a pretty wild claim.

bambax 5y ago

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

closed 5y ago
> Bad code doesn't work. > It's very hard, and maybe impossible, to determine if a novel "works". I wonder if there is a an assumption here about what it means to "work" vs to be "bad". Psychologically, maybe it's helpful to view each person as their own interpreter, and there is more variation there compared to (e.g.) a specific python interpreter. But even in python I could write totally not-python code, and have the python interpreter run it (e.g. by writing a codec). And I could write beautiful code that throws an error, and have a person debug it for <some_purpose>, and in meeting that purpose it might be working. I think the challenge here is that "work" is being defined in a narrow, technical sense for code, but is recognized in a much broader, social/cognitive sense, for novels!
- jonnycomputer 5y ago
  There are no bugs, only unrealized intentions.
vidarh 5y ago
There are startups trying to quantify what "works" for novels [1]. Of course they're just scraping the barest surface of what "works" means as of yet with attempts to analyse pacing and use of different word types and how characters are described etc. I've tested some while writing my own novel, and it was more "interesting" than useful at this point, but I might give it another shot with novel #2 to contrast and compare the two. It'll be interesting to see how those tools evolve, though. [1] authors.ai is one example.

raitucarp 5y ago

I mostly agree with @antirez'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. btw, Congratulations.. Looking forward to your sci-fi novel @antirez Anyway, I love how redis evolved, and its design from the beginning from @antirez. That's why I am eagerly to read his another craft.

jonnycomputer 5y ago

As a programmer and aspiring writer, the two activities don'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.... But when I'm writing prose, it does not feel 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.

k__ 5y ago
I write (technical) articles and develop software. Good devs can be bad writers and the other way around. But good code is as good writing. It's a planned endevour which takes a few iterations to get right. Most people who code bad and/or write bad are doing so because ther code and text are just streams of thoughts typed down as they had them. Sure, iteration can fix a bug here and there, but if their thoughts don't follow a red line, nobody can understand what they wanted to create.
kian 5y ago
I feel like programming in a point-free style is the closest to writing prose that coding gets for me. A composition of named functions in sequence is essentially a functional sentence. The ability to effortlessly re-arrange the product on the page is what gives it the flavor -- written imperatively and in detail, that flavor is either lost, or diluted homeopathically amongst the much more verbose format.

andreygrehov 5y ago

On writing. > 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. @antirez: why `she` and not `they`? I know you are not a native English speaker (so am I), but I believe that's not the case here and was likely written so intentionally.

antirez 5y ago
It is just one of the choices for more inclusive and less standard language.
moshmosh 5y ago
One solution people have come up with for the perceived unfairness of male pronouns doing double-duty as neuter pronouns in English is to sometimes use female ones instead. The down side of this is that it leaves us with three possible neuter pronoun sets, at least two of which are just about guaranteed to bother someone. Using exclusively male pronouns will obviously bother some people, now, else this wouldn't be an issue in the first place. Using female ones will bother some people (either for ideological reasons or, for those who grew up on "male is what you use for the general case", by tripping them up as they try to figure out who in particular is being referred to). "They" and such are safer but you still get the occasional (incorrect) pedant complaining about that usage.
- andreygrehov 5y ago
  Thanks for the explanation. I'm not a gender pronouns pedant in any way, my question was asked purely from an educational perspective. My native language is Russian, which is generally a gendered (masculine/feminine/neuter) language. Nouns have gender. It mostly follows the spelling of the words - i.e. if a word ends with a certain vowel. Sometimes it doesn't work that way, mostly with loanwords. In other cases the historical form of the word did match a pattern, and was assigned a gender accordingly - and then changed (e.g. by re-loaning it in a more accurate spelling), and no longer fits. When that happens, people will use the more "appropriate" rather than the "right" gender in colloquial speech, and eventually it becomes the new standard, collecting the mismatch. A good example of this is the Russian word "coffee". When it was first loaned back in 18th century, it was "kofiy" - and in Russian, that is definitely masculine. Eventually it got re-loaned as "kofe", which would normally be neuter; but the masculine gender assignment stayed from past spelling. In the dictionaries, that is - in practice treating the word as neuter became one of the common incorrect colloquialisms, just because it doesn't "look" masculine. Language purists fought this for several decades, and eventually lost: it's still nominally masculine, but neuter is considered an "accepted variant" in modern dictionaries. So to a Russian speaker, say, New York and Texas are masculine, while California and Florida are feminine. So, when I read "she" in @antirez's article, I was immediately confused, like, did I miss a character introduced in the previous paragraph or ...who is _she_? In my writings, instead of saying "he", "she", "they", I try to call people by the exact meaning of what I'm writing about, eg engineer, manager, programmer, etc. No idea why it's not THE way to end all the pronouns dilemmas in English.

aledalgrande 5y ago

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

nocturnal_pt 5y ago

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.

kingsuper20 5y ago

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.

masswerk 5y ago

I've always thought of programs as "functional prose". 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. (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?)

WorldMaker 5y ago
I tend to think of code much more like "poetry" than "prose". Programming languages provide required "meter", "rhyme", and other similar "format requirements" like poetry styles. Style guides and lint tools even further "refine" the "poetry style" agreed on by a development effort. I haven't found any particular use for this analogy for deep insights (there rarely were collectives focused on long form poetry in history, depending on what you think of oral storytelling traditions and/or if you agree with conspiracy theories that the output attributed to William Shakespeare was more of a collective effort than a lone auteur), but I still find it an interesting analogy.
proc0 5y ago
Yeah, I have referred to asking questions as 'mind queries', if they're technical in nature, since it's just trying to acquire a piece of knowledge.

dhosek 5y ago

I just recently was noting similarities between my strategies for programming and for writing: https://www.finl.xyz/2021/04/07/looking-at-rust-is-already-beneficial/ https://www.finl.xyz/2021/04/07/looking-at-rust-is-already-b...

faustlast 5y ago

> Sentences must be well written, but the overall structure and relationship between the parts is also crucial. 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 "The Devil to Pay in the Backlands" is confusing and hard to read.

antirez 5y ago
In this case for the sentence to "work" is that it's confusing, anything that creates the effect (explicitly wanted or not) works. Like the single sentence of a program participating to an obfuscation programming context must work in order to create confusion. I left the artistic part of the process out of the post because in the artistic process the similarities are very far, IMHO. I think I use a creative process while programming as well, but is not alike to the one used to write.

proc0 5y ago

> 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 This is a very subtle and interesting point. This notion of the 'primitive kernel' 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? It is tempting to think that highly abstracted code is overkill. However, abstracting code on the first introduction of a feature, allows for this "primitive kernel" to be as solid as possible, such that it doesn'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 *the longer you put off abstracting something (i.e. copying code instead) the more expensive the abstraction will be once you get to it.* So the first abstraction, nicely put in the quote above, "During the genesis of the system she should rewrite this primitive kernel again and again", 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. *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.* 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's a function of how many concrete cases there are to abstract, multiplied by environment's stability (once it's shipped, abstracting gets even more difficult and costly).

stakkur 5y ago

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't adhere to any consistent rules of construction/grammar/style. And: a 'successful' program is easy to spot; a 'successful' novel defies that, beyond the most superficial (and ultimately subjective) measures.

smitty1e 5y ago

> 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. The prose has to "execute" in the interpreter of the reader's imagination. Not much stack space there: go easy on the pronouns.

deleted 5y ago

[deleted]

withinboredom 5y ago

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

TomDavey 5y ago

Here's a technique for revising and improving prose that has no analog in programming: reading the text aloud to yourself. 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. I'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. Voilà! A much better second draft of the message in a very efficient manner. And yes, I read this post aloud before I pressed "add comment." I hope it doesn't betray me.

themacguffinman 5y ago
Arguably writing tests is the analog of reading prose aloud. It forces you to think through cases as a user of your code and often helps catch bugs as a side effect of your thinking than the test result. Or perhaps a closer analog is the rubber duck where being forced to explain your problem leads to thinking more clearly about it and solving it.

yourabstraction 5y ago

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.

phlipski 5y ago

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

tyrrrzhn 5y ago

Summary of the blog post: - Programming and writing are similar - In writing you have rules (natural language grammar), in coding you also have rules (formal language grammar) - 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. - If you don't write you're lazy. If you don't code you're lazy. Very similar. - 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's released, so you torture yourself to make sure it'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's fine because your progress is incremental

polypodiopsi 5y ago
I consider this sort of polemic, reductive summary utterly impolite. You left out the really important point: the suggestion that writing code could benefit from approaching it like one had only one shot at it, instead of patching smth. together that might or might not be improved upon incrememtally later on. This sort of summary you did there is not in good faith.