Computer programming & writing fiction: Iterative processes

Repetition (elPadawan, CC BY-SA 2.0)

Repetition (elPadawan, CC BY-SA 2.0)

Previously I’ve noted the similarities between computer programming and writing fiction, saying both attracted their own practitioners. I then explained why I view computer programming, as well as computer programs, as forms of art.

How else is writing fiction like computer programming? Practicing the two, one common aspect I’ve gleaned is their repetitive natures. Both are iterative processes.

I cannot in good faith declare any fiction I’ve written “done” until I’ve read the final draft from start to finish eight or more times. (Usually the number is higher.) With each read, sentences are moved or removed, paragraphs rearranged, punctuation revised, word choices are evaluated, and so on. Shaping prose is one of the most important skills a writer can cultivate. (Journalists do this in their sleep. Minutes after the final out, San Francisco Chronicle baseball writer Susan Slusser files a game summary that is polished, informative, and to the point.)

In fiction, editing is usually described as fine-tuning a manuscript, but more often it’s about being bold—knowing when to strike a paragraph, a page, or even a chapter, all in the service of a better story.

As any computer programmer can tell you, this is a familiar process. Programmers probably spend more time at the keyboard revising existing code than writing new code. Small program edits—similar to line edits or word choice—are common enough, but when more major surgery is performed, programmers will often use a special word: refactoring. Refactoring is restructuring existing code without changing its external behavior. (It’s usually done to make the code easier to read and maintain, not to add a new feature or fix a bug.)

That’s the crux: Without changing existing behavior. It’s funny, in writing fiction, if you make a lot of bold changes, it’s considered a success if the story seems “new” or “better” to a reader. In writing code, success is if you make a bold refactoring and the program operates exactly as it worked before.

The Ouroboros

I enjoy reading how other authors developed their fiction. Authors selected for Best American Short Stories (and other volumes in the Best American series) are given the opportunity to write a capsule for the books’ back matter. They often discuss inspiration for the story, and how external factors shaped its outcome. Writers’ correspondence is another goldmine for learning creative processes. (In particular I recommend Raymond Chandler’s Selected Letters, which is a master class in writing, style, and technique.)

Often when an author discusses how they developed a story, I’ve noted they can’t pin down the exact moment of inspiration. There might be some flash where the creative process launches, but so many times writers confess how stories come from a nagging itch to write on a subject or develop some character trait. Long-forgotten inspiration will come roaring back to life for some reason. Writers some times talk about stories as though they “demanded” to be written.

Programmers have similar stories, although the inspiration may not be as abstract as, say, a line of dialogue or a character detail. Usually it’s a need driving the creation of new software, needs like “I wish there was a web site for me to connect to all my friends” (social networking) or “I wish I had a typewriter where it was easy to correct mistakes, and it would even check my spelling for me” (word processor).

Many times I’ve read of authors returning to old work and fighting (or succumbing to) the urge to edit it. The edits may only be a comma here, a semicolon there. They may be larger edits , striking paragraphs or scenes in the pursuit of a tighter tale. Programmers deal with this urge too, always looking to tighten up code and make it more efficient or elegant.

I’ve quoted this elsewhere, but it’s worth repeating:

…software development is an iterative and incremental process. Each stage of the process is revisited repeatedly during the development, and each visit refines the end product of that stage. In general, the process has no beginning and no end. [Italics mine.]

That was written by Bjarne Stroustrup, the inventor of the C++ programming language. Everything in this quote pertains to writing fiction as much as it pertains to writing code.

When I edit stories, I visit and revisit the story as part of the editing process, to smooth and refine the language, to ensure the story flows smoothly. Programming has a similar process, a continual revisiting and revision of the code to remove flab and tighten up its execution.

That’s what Stroustrup meant when he said the process has no beginning and no end. Stories and computer programs are never finished. They can always be made a bit better.

Sometimes alteration worsens the final product. When coding, I often talk serious changes as “surgery.” While it might be necessary, it’s possible to hurt the program while improving it. Touching code in one place can break code in another place. This is why sometimes you’ll download an update to an app and it seems slower or simply broken, even though the developer swears they’ve made improvements.

Likewise, fussing over a novel or a story can hurt it too. In the original editions of The Martian Chronicles, the chapters were dated like a diary, starting from 1999 and ending in 2026. Today, revised editions use dates from 2030 to 2057. A small change, undoubtedly made to preserve the story being told “in the future,” but it stole away some of the book’s charm. In my youth, 1999 was a magical date, a momentous odometer signaling a shift to the bold 21st century. 2030 is just another number.

A common adage among software developers is “Don’t fix what’s not broken.” The same can be said for fiction.


Paul Joseph. (CC BY 2.0)

Paul Joseph. (CC BY 2.0)

Programmer Ben Sandovsky observes:

Treat yourself [the programmer] as a writer and approach each commit as a chapter in a book. Writers don’t publish first drafts. Michael Crichton said, “Great books aren’t written– they’re rewritten.”

Sandovsky is exhorting computer programmers not to make hasty changes to a computer program, but to edit and revise those changes before officially adding them to the program.

Late in the editing process, I’ll often read my stories aloud to make sure they flow well. I’ve never read my code aloud—computer languages aren’t like human languages, for the most part—but I’ve certainly eyeballed my code closely, going over it line-by-line, before committing it.

I often use the word distill for both pursuits—to purify, condense, and strengthen through repetitive processes. Writers and coders don’t simply edit their work, they distill it down to its essence.

Lazy writing makes for boring reading. Lazy programming makes for buggy software. In general the process has no beginning and no end. The art is knowing when to let go and release your hard work to the world.

Computer programming & writing fiction: Is coding art?

Girl with an 8-bit EarringIn my last post comparing writing programming and writing fiction, I concluded both were similar because of their relationship with their practitioners. “Art is a kind of recruiting poster for itself,” I wrote. “An art attracts its own artists.”

Wait—is computer programming art? It’s accepted to call fiction art, but can computer programming really be considered

the conscious use of the imagination in the production of objects intended to be contemplated or appreciated as beautiful, as in the arrangement of forms, sounds, or words. (The Free Dictionary)

Think of what programming a computer really boils down to: Ordering and organizing a series of mathematical instructions followed precisely by the machine. The computer is allowed no imagination in its interpretation of those instructions (if it possessed an imagination, which it doesn’t, at least not today). If there’s an art in computer programming, it stands in the purview of the programmer, not the machine. That’s how it should be. The art of painting is not in the tubes or cans of paint, but in the painter.

But is the arrangement of those computer instructions somehow “beautiful”?

It’s important to discern a difference between a computer program being art and the act of programming as an artistic form. Let’s start with the latter.

I believe programming is an art form, at least by modern notions of the term. Writing fiction and writing code requires continuous subjective decision-making during the entire process (a “conscious use of the imagination”). A personal fervor is vital for quality results. When a writer lacks that fervor, it shows in the end result, both for fiction and computer programs.

Programming is not a rote process of memorization and recall. There is no “correct” way to write a computer program but, like writing a novel or a short story, there are many wrong ways.

Bill Atkinson, creator of the original MacPaint, painted in MacPaint. (Daniel Rehn, CC BY 2.0)

Bill Atkinson, creator of the original MacPaint, painted in MacPaint. (Daniel Rehn, CC BY 2.0)

Coding requires taste, aesthetics, and an eye for detail. Programmers develop deeply personal philosophies. Some coders prefer verbosity (like Henry James in his later years) while others prefer economy (like Hemingway or Cain’s early work).

There’s a scene in August Wilson’s Fences that is one of the most distilled scenes I’ve ever read: The father and son debate buying a TV to watch the World Series. On the surface a mundane domestic moment, the scene is actually Fences in-miniature. The beauty of this scene mirrors brilliant software design, where each piece of the program is intimately connected to the entire application.

Years ago, I could always tell when I was working with a programmer who started coding on the Macintosh versus a programmer weaned on Microsoft Windows—the two companies have distinct programming styles and philosophies. Programmers who learned to code on those operating systems carried those styles and philosophies with them to other platforms and projects.

A computer program can be functional, operating, and seemingly free of bugs, and a programmer may still read the code and say it doesn’t “look” right. (The trendy term for this is “code smell.”) What’s more, two programmers may say a program doesn’t “look” right for entirely different reasons. This reminds me a great deal of the world of poetry, where poets may agree a poem is poorly executed and then squabble over the reasons why. (There are similar disagreements in the world of fiction, but I find them to be less…doctrinaire.)

Writing and programming both involve elements of discovery and improvisation. Even though I’m writing a series of blog posts advocating outlining stories before writing them, I don’t believe an outline can—or should—contain every detail present in the final story. An outline should not be so rigid as to prohibit discovery during the writing process.

For a long time, there was a big push to eliminate discovery and improvisation in the world of software development, as “discovery” and “improvisation” seem undesirable in a field of proper engineering. (In the 1960s, IBM famously discovered that the number of bugs a programmer produced was proportional to the amount of code he or she wrote. Their solution: limit the lines of code a programmer could write per day, a logic straight from the pages of Catch-22.) Newer software philosophies, notably Extreme Programming and Agile development practices, have flipped that thinking and embraced discovery and improvisation as healthy and necessary.

Suspicion of programming as an art form probably springs from a general lack of understanding of how programs are written. Programmers share an arcane terminology among themselves. They build and manipulate mysterious machines that have come to play a powerful, sometimes menacing, role in our lives.

<cite>Ex Machina</cite>, a 2015 film about a computer programmer who falls in love with an artificially intelligent android.

Ex Machina, a 2015 film about a computer programmer who falls in love with an artificially intelligent android.

That suspicion probably also arises from stereotypes. Programmers don’t look like artists. In popular culture, programmers are portrayed as geeks more comfortable around machines than humans. Sometimes coders in film or TV even fall in romantic love with their own programs. (Never mind that this trope originated in antiquity and regards an artist and not a bricklayer or farmer or soldier.)

Another reason people question programming as an art is that computer programs “do” things. There’s an academic suspicion of pure art having any sort of utility, probably due to fears of commodification and commercialization. We don’t think of Vermeer’s Girl with a Pearl Earring as “doing” anything other than hanging on a wall in some drafty museum, but it must be doing something to cause people to stand in line for hours to view it. It’s funny, this idea that pure art doesn’t “do” anything when it so plainly does. If art didn’t do anything, why would we care about it?

And this rolls back to the distinction I made earlier: Is computer software itself art? I’ll challenge the question with a question in return. We regard skyscrapers and bridges and automobiles and colanders as kinds of art. We laud architects, automotive designers, and commercial illustrators as artists. Why treat computer programs and their creators differently?

Next: Iterative processes

Colander, c. 1600 - 1650, Museum Boijmans Van Beuningen

Colander, c. 1600 – 1650, Museum Boijmans Van Beuningen

Computer programming & writing fiction: Art as a recruiting poster

IBM SelectricHow is computer programming like writing fiction? Is writing code anything like writing stories?

When I was young, perhaps seven or eight, I banged out my first short story on a second-hand IBM Selectric typewriter my mother brought home from her office. Powered on, the Selectric vibrated the whole desk and emanated a low mechanical hum, some unseen engine in the contraption idling. I still recall the smell of the ink in the typewriter ribbon and the satisfying, officious schock as the typeball jumped from its perch and tapped lettering onto the crisp onion paper I’d fed into the roller.

The story I wrote was a retelling of Richard Connell’s “The Most Dangerous Game” transplanted to a science-fiction setting. (In fact, I think I creatively titled it “The Most Dangerous Game in Space”.) My determination to spend hours coping with that unforgiving contraption went beyond an affinity for the classic short story. As an avid young reader, I’d come to wonder if I could pen my own fiction. My aspirations weren’t so bold as to imagine being published, only to see if I could write my own, but later that dream crept in too.

The Most Dangerous GameAround the same time (this would’ve been 1979), I cajoled my parents into buying a home computer. Silicon Valley was marketing home computers as personal productivity assistants, devices to balance one’s checkbook, manage a home mortgage, track stocks, and so on. Home computers were also being pitched as tools to give students an edge in school. I couldn’t care less about schoolwork—and I’ll be damned if that computer ever balanced my parents’ checkbook—but with a home computer I could play video games, my only real motive for wanting one.

Innumerable hours playing videos games led me to try to write my own. It was a natural progression, just as reading I, Robot set me to thinking of my own robot stories.

I never did write a video game, at least not one that anyone would want to play, but software development did become my career path, one I’m still following over 35 years later.

Likewise, although I didn’t finish that short story, writing fiction remains an important passion in my life, even more important than programming.

Walking these paths, I’m sometimes asked if writing software and writing stories are the same. Or, at least, if they bear any similarities. And my answer is, yes, there are commonalities between the two.

I’ll explore more parallels in the future, but already I’ve alluded to one thing they have in common. I’ve never met a good writer who wasn’t first an avid reader, and I’ve never met a good programmer who wasn’t first an avid computer hobbyist.

Art is a kind of recruiting poster for itself. An art attracts its own artists.

Next: Is coding art?