Writing and Programming
I’ve been a software developer since 1998. I didn’t actually like computers until I started working at Amazon.com back in the days when they sold only books. I got a job in their customer service department after a brief stint of teaching in the Seattle public schools. At the time, Amazon’s customer support was delivered primarily through email. If you had a question, you’d write to orders@amazon.com, and one of the customer reps in Seattle would write back.
Everyone in customer service worked at a Unix terminal, using Emacs as a mail client, and a set of command line tools with names like orderstat and customerstat to track down problems.
Emacs is a text editor used by software developers to write code. It does not have layout or formatting features like a word processor, because you don’t need those features when you’re writing code. It does have lots of advanced features, like a built-in email client, web browser, web server, code evaluator, debugger, psychiatrist , and more. It’s difficult to learn, because all those thousands of features are hidden behind an interface that looks like this:
Put that in front of someone who’s never seen it before and tell them to get to work. They’ll have no idea where to begin.
The first week of training for customer service reps focused on how to use Emacs and the Unix command line. Learning Unix was an epiphany. The entire system was built around a few simple principles that applied consistently everywhere. If you ever got lost, you could go back to those principles and reason your way toward where you wanted to be.
Around this same time, I was having trouble getting my home computer to work with a new printer. I realized how much I depended on the computer for writing, email and other communication, and I wanted to know how it worked. So I bought a book on C programming and started making little programs.
Attempting to understand your computer by buying a learn-to-program book is incredibly naïve. It’s like attempting to understand the a foreign culture by reading one of its primary school grammar books. But I started to see in the C language the same principles that pervaded Unix. This was no coincidence. Unix was written in C, by the creators of C at Bell Labs in the early 1970s.
I became fascinated by programming, and for the next several years, I’d stay up until midnight and get up at 5:30 AM just to tinker and learn. By 1999, I was doing it professionally. It was the dot-com boom, and programmers were in such demand that even a self-taught developer with no real-world experience could get work.
While I spent most of my time coding, I never lost the love of writing. But programming was my living, and writing went to the back burner.
I recently read Vikram Chandra’s Geek Sublime . Chandra is another software developer and writer, and much of his book is about where the two practices converge and overlap. Some reviewers criticized the book for not wrapping everything up neatly, like a freshman compare-and-contrast essay. But the book is quite rich, and it has plenty to offer even without a neat conclusion. I’ll review it another day.
Like Chandra, I’ve found a number of similarities between writing code and writing prose, and the practice of one can help develop skill in the other. Both require immense concentration and extended periods of solitary, focused work. Both require you to keep track of a huge number of concepts, interactions, side-effects and timelines. You have to manage these in your head as you write, and you have to understand how a little change in one part of the work will require changes to some other distant part that you haven’t even looked at in three weeks.
In programming, the concepts are data structures, algorithms, requirements and business rules. The interactions are functions, methods and calls to external systems. Side effects occur when concepts or interactions change. You have to know how all the pieces fit together to anticipate the side effects of any change. Timelines in software generally relate to whether certain actions have occurred or conditions have been met. If the program has all the input it needs and can communicate with external systems, it can proceed. If not, it may need to ask the user for more information, or it may need to put some work aside and proceed with other tasks.
In writing, the concepts are character, setting, theme and tone (to name a few). The interactions are plot, confrontation and dialog (to name a few). All events and all interactions have side-effects, and you have to manage them in ways that make sense. For example, if character A gets into a fight with character B, these characters’ attitudes toward each other will be different after the fight. There may be more tension between them, or there may be less.
Timelines are also important. Imagine a story about adultery where the wife knows from the beginning that her husband is having an affair. Now imagine a story where she learns of the affair after it’s been going on for three years. They involve the same characters in the same setting, but they are two completely different stories.
When you’re writing a book or a large software program, you’re always making little changes to some part of the work and keeping mental notes about how these will require you to change other parts. You don’t write everything in order. You write the difficult and essential pieces when the inspiration hits, and you slog through the more tedious parts when you have the patience and the time.
Good software developers write their code specifically to be read by other developers, because any program that is actually useful will have a lifetime of several years. During that time, other developers will have to adapt it to new systems, fix bugs and add features. While code in general tells the computer what to do, well-written code describes to developers the purpose of the program and of each of its pieces.
Well-written code is not simply a set of instructions. It is a written communication from a developer in the past to a developer in the future that says in the clearest possible terms, “This is what’s going on here.”
A well-written story is essentially the same thing. You may be communicating things that are much more subtle and complex, such as emotional states, but the point of your words is to communicate to some reader you have never met “This is what’s going on here.”
Much of the mental work for both writing and programming happens away from the keyboard. One well-known developer calls it hammock-driven development, which is nicely summed up in this graphic . You do your thinking away from the computer, where your mind is free to wander and is not pressured to produce. You’re not staring at a little box that you need to fill with code or sentences. You’re outside the box, where you can try on ideas and cast them off at will.
There are two huge qualitative differences between writing software and writing prose (fiction or non): who you are working with, and who you are working for.
Professional developers typically write for companies. They work with managers to create a product whose value is measured in dollars. Sometimes the dollars come from selling the product, but more often they come from making essential processes more efficient and less error-prone.
Writers work for readers. They work with editors to create a product that shares meaning and experience through mental and emotional engagement.
Readers and editors understand that writing is a creative process; companies and managers do not. Creativity happens beneath the surface of activity, or often in the absence of activity. The reader and the editor imagine that the writer is composing or reminiscing as he stares off into space, while the manger thinks the programmer is slacking when he’s not at the keyboard typing.
It’s been this way for a long time. The Parable of the Two Programmers , written back in 1985, sums it up pretty well. It’s a short read, but if you decide to skip it, here’s the summary:
Two companies need to write the same program. At one company, a team goes right to work. At the other company, a developer spends many days away from his computer thinking about what the program needs to do. After much quiet, internal consideration and analysis, the lone programmer distills the problem to its essence, and writes a short, clear program that solves it.
At the other company, the team never takes the time to distill the problem. They write a large, complex, buggy program that mostly does what the company needs.
Then the managers review the work at both companies. The team that implemented the complex solution with unreadable code is told they did a good job in solving a problem that, from the looks of the code, was very complex. The lone developer at the other company is told that, judging from the looks of his short, clear, concise code, the problem he solved must have been quite simple. His manager says it should not have taken so long to solve such a simple problem, and lets him go.
What the managers don’t get is that the real work of writing code (and writing prose) is distillation. It is the act of taking something too big, too complex, and too messy to express in writing and boiling it down to something that is clear and accessible. The programmer reduces it to a set of instructions that he knows will flow through the machine’s central processor in such a way as to produce the results he wants. The writer reduces it to a set of words that he hopes will reproduce in the reader’s mind something close to what he has experienced or imagined in his own mind.
I have always thought that this was the whole point of Hemingway’s The Old Man and the Sea . The old man goes out in a little boat by himself and hooks a giant fish. After a mighty struggle, he hauls it in and ties it to the side of the boat. While he’s adrift at sea (where writers spend much of their time), he expends all his strength trying to fight off the sharks who pick all the meat off the fish’s carcass. He returns to the marina with only the great skeleton. But the image of that skeleton and the exhausted old man are enough to tell the other fishermen what has happened. They can infer the story and the struggle. Like good readers, they reconstruct the fuller reality from the limited representation. And the writer goes exhausted to his bed to recuperate, hoping it was all worth the struggle.
It’s not just writers who distill and compress the meaning of experience. All people do it. You do it whenever you tell a friend in five minutes about some meaningful life event that unfolded over a period of weeks or months. You give them the skeleton when you describe the key players and the sequence of events in a tone of sorrow or wonder or warm humor. And then you leave it to them to put the meat on the bones. Good friends and good readers can do that. Friends and readers who are dull, inexperienced, or unwilling to extend sympathy and understanding cannot.
In the corporate world, the parable of the two programmers has a perverse side effect: the less capable team that implemented the inferior solution gets rewarded, while the more capable developer is discarded. In the software world, this leads to huge, buggy programs that developers are afraid to touch. In the book world, it leads to big weighty tomes that critics praise and readers feel guilty about not being able to finish.
This happens less often with writing than with software, because unlike computer users who can’t see the messy code behind a program’s shiny facade, readers are looking right at the words. Most readers prefer understanding to confusion, so they’ll avoid the bad stuff. But many mistake obscurity and complexity for depth and intelligence, especially in academia. Many writers (and programmers) are too lazy or too rushed to do the really hard work of sorting out complex ideas, clarifying vague concepts and distilling pages of meandering prose into a few striking sentences.
None of this is new. In 1710, in his conclusion to A Tale of a Tub , Jonathan Swift wrote:
I conceive therefore, as to the business of being profound, that it is with writers as it is with wells—a person with good eyes may see to the bottom of the deepest, provided any water be there; and that often, when there is nothing in the world at the bottom, besides dryness and dirt, though it be but a yard and a half underground, it shall pass, however, for wondrous deep, upon no wiser a reason than because it is wondrous dark.