What computer science taught me about writing
May 7th, 2007 by screenwriterguy
There came a day during college when a friend offered me some very logical advice. He pointed out that I was getting C’s in my engineering classes, but A’s in my film classes. Film seemed to make me happy, but engineering did not. Perhaps, he suggested, I should rethink my focus. Not smart enough to listen to him, I got the engineering degree, the whole time getting bad grades, the whole time not all that enthusiastic about engineering.
Given a second chance, would I do it all differently? It’s hard to say, but probably not entirely. There have been many occasions in my life when I’ve been glad that I think like an engineer. Engineering, to me, is about problem-solving by looking at all the components of a situation, then deciding where to place priority. Do we want this car to be fast, efficient, safe, or inexpensive? In what categories will we compromise a bit in order to gain in other categories? It’s a way of thinking that applies to the entertainment industry, too. Do I want this screenplay to be inexpensive to shoot, to appeal to 18- to 35-year-old males, or to attract a big star? Which of those considerations must I give up in order to get the others?
I’m also glad for my engineering studies because ultimately my computer programming classes taught me a valuable skill when it comes to screenwriting.
The key is a programming technique called decomposition. When a programmer creates software, the first step is to break the problem that the software will solve into small pieces. One identifies overarching categories into which one can break the task apart. If writing a game, the top-level categories might be “Receive Input from Joystick,” “Process Gameplay,” and “Output Graphics to Monitor.” From there, each group gets split further, i.e., “Output Graphics to Monitor” breaks into “Draw Background,” “Draw Current State of Ninja,” “Draw Current State of Throwing Stars.” Then each of those gets a further breakdown. “Draw Current State of Ninja” might decompose into functions that “Draw Legs,” “Draw Torso,” “Draw Arms,” and “Draw Head.” In the end, you wind up with an upside-down tree of functions, and the nodes at the end of each branch is a relatively simple task to code. It’s more complicated than I’m making it sound, of course, but the point is to break the overall chore into a many small, manageable pieces.
The concept applies neatly to writing. A feature screenplay is also a daunting task, but if I break it down into bite-size writing assignments, I can more productively use the hour between errands to get some worthwhile writing done.
Creating 120 pages is hard. Creating 1 page, 120 times… that’s much more doable.
I’ve always used decomposition when structuring stories, to some extent. Top-level are the three acts and each of those breaks into several sequences. Sequences, by definition, are groupings of related scenes, so the next step is simple enough: just break the sequence apart into each of the locations where something happens, and you have a list of scenes.

In the past, this would be my outline phase, and I would pick off scene after scene until I have a screenplay. Efficient enough.
The lesson I learned last week was that decomposition can and should go even further. Sitting down to create scenes from scratch sometimes goes well for me, and sometimes I block, stuck thinking about how I want to execute everything in the scene. In short, it’s still too big a bite to easily chew.
I turned a draft into my writer’s group last week that was only half-way complete. It was about fifty pages of screenplay and about ten pages of interstitial prose to make it possible for another person to understand the story from beginning to end. It was sharing my work with others at a stage far earlier than I’ve ever done that unleashed the discovery. Normally I get down to the scene level and assume that’s enough. I know what’s going to happen, so there’s no need to write down the details. But now I had to explain each scene, and so I began listing the MOMENTS that would string together to compose each scene.

Broken down to this level, I found that sometimes I could paraphrase what characters would say, and other times I just inserted a snippet of dialogue. Next would come a sentence or two of what needed to happen in the next moment, maybe a reminder of some plot point I needed to emphasize, or some mood I wanted the character to experience, then more dialogue. In other words, the pages were writing themselves.
One problem for me has always been the temptation to go back to pages that have already been written and do rewrites. Rewriting is more enjoyable for me than creating from scratch, and it still sorta feels like being productive. The problem is that you might spend an evening wordsmithing, then comb over the same pages the next night, and the next, and later you have no more pages than you did days ago. By putting every scene in the same document, I could go over everything from beginning to end. I could rewrite existing pages as I came to them, and then I could flesh out scenes that hadn’t been written yet into moments. It was a good compromise.
I will use this process on anything I write in the future, as I think it ups my output and helps keep. I’m glad to have discovered it. All because I was too dumb to stop being an engineer.
Posted in My Writing, Story Structure |