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.
> 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."
> “Don’t get discouraged because there’s a lot of mechanical work to writing. There is, and you can’t get out of it. I rewrote A Farewell to Arms at least fifty times. You’ve got to work it over. The first draft of anything is shit. When you first start to write you get all the kick and the reader gets none, but after you learn to work it’s your object to convey everything to the reader so that he remembers it not as a story he had read but something that happened to himself. That’s the true test of writing.” – Ernest Hemingway
> “The main thing is to know what to leave out. The way you tell whether you’re going good is by what you can throw away.” – Ernest Hemingway
To make anything production quality you have to go many iterations from sketching (prototype), to inking (design/setup) and then many, many passes on the post production iterations. Unfortunately our project management hasn't learned it is a creative art yet. You can't just throw another writer in to make it faster always. Game development is more programming/creative mix and it is clear in that industry, it is easier to argue for delays for polish and game mechanic tuning, others it is almost a perception hit just to delay for a better product with more iterations.
Hemingway also had a great tip for any creative or programming or self driven career like writing, leave something you know unfinished that you can start in the morning. So sometimes if you have a solution and implement part of it, prepare to test it or even put a compile error right where you left off, you build and start up the next day at that point.
> “The most important thing I’ve learned about writing is never write too much at a time… Never pump yourself dry. Leave a little for the next day. The main thing is to know when to stop. Don’t wait till you’ve written yourself out. When you’re still going good and you come to an interesting place and you know what’s going to happen next, that’s the time to stop. Then leave it alone and don’t think about it; let your subconscious mind do the work.
The next morning, when you’ve had a good sleep and you’re feeling fresh, rewrite what you wrote the day before. When you come to the interesting place and you know what is going to happen next, go on from there and stop at another high point of interest. That way, when you get through, your stuff is full of interesting places and when you write a novel you never get stuck and you make it interesting as you go along.” – Ernest Hemingway
This next quote about quality/product/content/experience is great, and it can parallel making a good game, or an app that makes someone's life more fun, or a tool that helps someone achieve something. Make your product a friend like a book if you can, you'll probably have to do it yourself as project management systems of today won't allow it.
>“All good books are alike in that they are truer than if they had really happened and after you are finished reading one you will feel that all that happened to you and afterwards it all belongs to you; the good and the bad, the ecstasy, the remorse and sorrow, the people and the places and how the weather was.” – Ernest Hemingway
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.
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!
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.
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.
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.
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.
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.
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-fo...
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.
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.
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.
Writers tend to report very different ways of working. Some plan out everything and write a huge synopsis, others sit down and write start to finish. Some iterate somewhere in between.
For my part I plan out the high level plot, and a list of scenes. At most a 2-3 pages synopsis.
Then I write start to finish. No exceptions: Scene by scene, paragraph by paragraph, without going back.
Interestingly seeing as you suggest writing is more dynamic and non-linear, that method of writing a novel - which I've used twice so far, and in-progress with the third - is a lot less dynamic and non-linear than the way I write code.
I rarely plan out at anything but the very highest levels when I write code. I sketch out components and fill in pieces of code as I need them, and stub out other things, and then I test, and then fill in some more.
I can't write that way. I find if I try to produce any kind of in-depth synopsis I just end up changing most things when writing the full scenes anyway. I need to know the details of what went before to fill in the scene I'm currently working on, so I can't work effectively on it until I've written the previous ones out fully.
Some people do write by jumping back and forth, so I'm not suggesting you're wrong for you, but that's just not how it works for me. When I revise my draft I similarly go through them beginning to end. When I get it back from the editor, I gather up the notes, decides what to listen to and what to ignore, and go through my draft linearly, beginning to end.
I used the same process. I wrote the novel from the start to the end, never reading back during the first draft if not for recalling certain details that affected the latter part of the story. Before starting I had just a subject of a couple of pages and a few main characters descriptions. All the rest happened while writing. But while the first draft is so much a matter of inspiration and letting things happen in front of your eyes, what comes next is a lot more similar to improving a large software system. Reading again and again, finding weak spots, improving, reiterating this process.
> In programming, there is often a clear pre-defined task
How is this different from writing stuff? Most of the time you have some pre-defined thing you want to communicate. If you mean writing novels and not just writing memos or articles then the equivalent is coding games which is just as creative if not more than writing novels.
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?
That's fair and I guess highlights that I wasn't thinking about exploratory writing or even fiction. It is definitely very different if you aren't starting the writing process with an end in mind.
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.
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]
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?)
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
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.
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.
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.
> 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!
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.
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.
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.
- 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
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.
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.
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."
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."
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.
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.
And yet, we say that “programs are written for people to read.”
Writing for people to read is not “very logical and very precise.” It’s “very expressive,” and sometimes, although the part the compiler reads is correct, the thing the human infers from the program is imprecise and expressive.
Working with code teaches that code is experienced, too. We read a thing, go hunting for its downstream dependencies, learn other things… Coding is an experience as much as walking through a building is an experience.
Architects of buildings work with precise engineering, but they also craft experiences for humans. I am cautious about drawing parallels between code architecture and physical architecture, but the parallel between the work a code architect performs—creating a precise thing for the compiler and simultaneously creating an imprecise experience for the programmer—and the work a physical architect performs is much more sound.
My thesis, therefore, is that programming is the art of doing a precise thing for one audience—the machine—and a creative, imprecise thing for another audience—the human who experiences the code.
Hey, late reply. I agree with your general point, and would add that the highest logical/precise human-readable text is more likely to be specs, e.g. RFCs, ISOs.
A Technical Manual would need more attention to the human experience than a spec, IMO.
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.
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.
A lot of creative work is precise too. The number of writers who e.g. use spreadsheets or similar to keep track of scenes, characters and arcs is fairly substantial.
While the specific final words are less precise, there's a lot of rules to adhere to in order to write well as well.
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.
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.
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?)
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.
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.
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.
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.
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.
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.
> 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.
"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.
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.
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.
> 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.
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.
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.
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.
The similarity between the two probably helps explain the plethora of programming blogs versus the absolute desert that is the hardware/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.
> 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.
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.
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.
> 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).
