[HN Gopher] Programming and Writing
___________________________________________________________________
Programming and Writing
Author : blopeur
Score : 181 points
Date : 2021-05-14 09:56 UTC (13 hours ago)
(HTM) web link (antirez.com)
(TXT) w3m dump (antirez.com)
| chrisweekly wrote:
| Looking fwd to your novel's release, @antirez!
| say_it_as_it_is wrote:
| Will it be a single-threaded story with minimal cruft?
| antirez wrote:
| 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.
| block_dagger wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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."
| jonnycomputer wrote:
| 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__ wrote:
| 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.
| bambax wrote:
| 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.
| vidarh wrote:
| 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.
| majormajor wrote:
| I don't really agree. "Works" is a lower bound for code, but
| hardly the end all and be all. There's a whole world out there
| of "bad but works" code.
|
| And about as much arguing about what makes "good code" as there
| is about what books are good and bad.
| closed wrote:
| > 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 wrote:
| There are no bugs, only unrealized intentions.
| kingsuper20 wrote:
| 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.
| dkarl wrote:
| 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]
| pcmaffey wrote:
| 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
| jborichevskiy wrote:
| > 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-ki...
| masswerk wrote:
| 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 wrote:
| 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 wrote:
| 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.
| bitwize wrote:
| 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 wrote:
| Writers get laid sometimes too.
| andreygrehov wrote:
| 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 wrote:
| It is just one of the choices for more inclusive and less
| standard language.
| moshmosh wrote:
| 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 wrote:
| 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 wrote:
| The comment below the post saying a ~500 words "wall of text" is
| off-putting. :facepalm:
| stakkur wrote:
| 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.
| scandox wrote:
| 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 wrote:
| 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 wrote:
| Both are dealing with the "magic" of transformation. Programs
| transform data. Fiction transforms desire.
| [deleted]
| marsven_422 wrote:
| 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.
| faustlast wrote:
| > 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 wrote:
| 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 wrote:
| > 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).
| raitucarp wrote:
| 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.
| smitty1e wrote:
| > 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.
| magpi3 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| vidarh wrote:
| 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.
|
| And the best programming is often very creative.
| a4isms wrote:
| 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.
| robotresearcher wrote:
| > Writing for people to read is not "very logical and very
| precise." It's "very expressive,"
|
| There's a continuum between writing technical manuals and
| 'Ulysses', with airport-bookstand thrillers somewhere in
| between.
| nocturnal_pt wrote:
| 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.
| dhosek wrote:
| 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-b...
| diamondap wrote:
| 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/
|
| 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
|
| 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...
| neolefty wrote:
| 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 wrote:
| Have you read Weir's _Project Hail Mary_ yet? If so, did you
| like it as much as _The Martian_?
| glass_of_water wrote:
| I think the reason we find similarities between the two
| activities is that they are both, at their core, using language
| to affect an interpreter. In natural language, the purpose is to
| affect the state of the reader's mind. In computer language, the
| purpose is to affect the state of the machine.
|
| The two main differences are that natural language's effects on
| the interpreter are typically uncertain/probabilistic, whereas
| computer language's effects tend to be
| discrete/logicial/deterministic. Also, the brain is much more
| effective at resolving ambiguity in language than computers are,
| so computer language has to be specified in detail down to the
| language primitives (which are also ambiguous w.r.t. how they can
| be translated to machine code, but the limited scope of the
| primitive operations makes the disambiguation task tractable).
| hegelguy wrote:
| 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.
| vidarh wrote:
| 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.
| antirez wrote:
| 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.
| username90 wrote:
| > 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.
| jsight wrote:
| 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 wrote:
| 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?
| jsight wrote:
| 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.
| stephc_int13 wrote:
| "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 wrote:
| 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.
| Garlef wrote:
| 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 wrote:
| >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 wrote:
| 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 wrote:
| 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.
| Ozzie_osman wrote:
| 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 wrote:
| 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.
| scaraffe wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
___________________________________________________________________
(page generated 2021-05-14 23:01 UTC)