“Premature optimization is the root of all evil.”
—Donald Knuth, pioneering computer scientist
This quote popped up as I was searching for a new piece of software for this website. It reminded me of something else I’d read recently:
“… in class I always insist on this blocking out of the story, which I call a treatment. The students all hate it. They always want to begin right away with ‘It was a spring evening, and under ice cold skies the crowds were hurrying homeward along Third Avenue where the neon signs in the bars were beginning to be reflected in the exhausted eyes of office workers.’ This sort of thing makes me tear my hair out, because I know it is ten to one that the story should not begin on Third Avenue at all…”
–Frank O’Connor, A Frank O’Connor Reader
Computer programs are complicated things to make. Short stories—good ones, anyway—are complicated things to make. Both are intricate constructions of interacting parts, algorithms and code in the first case, themes and words in the second. The quotes from Knuth and O’Connor struck me because they address the same critical aspects of the making of complicated things: what to do first, what to save for last, and what to do in the middle. Both imply the exercise of creativity at the strategic level (algorithms, themes) and the tactical level (beautifully written code elements, beautiful sentences).
Knuth argued that programmers sometimes spent too much time early on in a project honing parts of the code that in the long run were only called infrequently—I suppose in the worst cases not called at all! The time spent optimizing was therefore wasted because it was spent on the wrong parts of the project. The implication is that some decisions cannot be made in the early stages of a project because there is insufficient information available.
O’Connor claimed—only half facetiously—that absolutely the only way to properly write a short story was to start out by stating what happens in the story in just a few sentences, ideally no more than four. He called this a “theme.” In the theme, such specificities as the gender, age, and occupation of the characters, the place where the story is set, etc. are left to be decided later on in the writing process. O’Connor sought to reduce the events of the story to almost a kind of storytelling algorithm. In examples such as this one from A Frank O’Connor Reader, he even used X and Y instead of names or gender pronouns:
“X marries Y abroad, After Y’s death, X returns home to Y’s parents, but does not tell them Y is dead.”
Only when he was satisfied that his theme had a robust structure with maximum universality did O’Connor begin to elaborate the story, first with a rough “treatment,” and then with revision after revision. Only at the end of the process was it “the time for fine writing“—the time for optimization, in other words.
As a one-time student of fiction writing, this rings true. I cannot say how many times I started out describing the equivalent of the lights at dusk on Third Avenue, only to be sucked into a formless abyss called No Story Here. I’m sure there are writers who can start out with the “fine writing” and follow its thread through to a complete story, but I was not one of them.
Similarly, I have all too often started out with the programming equivalent of describing the scene on Third Avenue. I have usually—not always—been saved from complete failure by an intimate knowledge of the domain the software addresses: book printing, typically. But while software built in this manner may work, it is always a dog’s breakfast: much slower than it should be and almost impossible to extend or maintain for anyone but the original coder. The beauty of computers is that, unlike readers, they don’t care: they will run ugly code as many millions of times as you wish without a sigh.
Thousands of hours of experience and the strong desire not to spend the rest of my life maintaining my own bad code have improved my programming skills, aided immensely by the use of software frameworks built by others. I have moved up the learning curve, in other words. Experience is clearly key to mastering complex skill sets, especially if you don’t have a particularly organized mind.
In many ways, both programming and fiction writing are equally unforgiving. If your code is bad enough, it will not work at all or will be so buggy people will refuse to use it. (Voluntarily at least: sometimes we are forced to!) Similarly, if your fiction is bad enough people will not read it. (Voluntarily at least: sometimes students are forced to!) At the other end of the quality spectrum, a piece of fiction can be good enough on enough levels that its quality is accessible to millions: the ability to write fiction is not a prerequisite for reading fiction. With software, as described in Vikram Chandra’s wonderful Geek Sublime, the intrinsic beauty is accessible only to those with enough esoteric knowledge to grasp it: programming skill is a prerequisite for appreciating software. Here the analogy between software and fiction falls apart altogether: fiction processes within a human mind, a living thing, enriched by change; software processes within a computer, an inanimate unemotional object, for which a significant change to its structure means total failure. Further, just as a computer doesn’t care about ugly code, it also cannot recognize beautiful code.
There are many kinds of complicated projects besides writing stories and coding software: publishing books, making movies, starting a business, living a life. In each case, if you haven’t done it before, you have to work through the hardest part of the learning curve. What if there were a Beginner’s Guide to Creating Complicated Things that laid out the general rules for figuring out what to do first, what to do in the middle, and what to do last? Would it be worth using? Or would giving up the struggle through the hard part of the learning curve be giving up the best part?