I just completed a demo1 for software that me and my team have been working on for nearly a year. It isn’t quite done yet—we still have a few months of work left, but it feels good to get to the point where you have something to show. Indeed, it’s not that different from getting a story out into the world.
When it comes to writing (when I can even manage to write these days) I am “pantser” as opposed to a plotter. That is, I don’t plan out my stories in detail. I have an idea of where the story is going, and I figure out how to get there as I write. Sometimes, I end up somewhere else entirely.
With software, I am the complete opposite. Over the decades I’ve worked on increasingly more complex software and I’ve found that my brain doesn’t have the capacity to build it without plotting it out first. I hadn’t really considered it much until now, but I suppose that designing software is a lot like outlining a story. You start with the high level goals and requirements; you identify the tools you can use to meet those requirements; and then you figure out how everything will fit together to make a cohesive and self-consistent thing.
The day-to-day work is writing code, small fragments, akin to scenes in a story or novel. Often you write something that gets the job done but isn’t particularly elegant, so you rewrite it and rewrite until it purrs. The world fades around me when I get into this mode, my focus is completely on the task at hand, and an 8- or 9-hour day can fly by in what seems like the blink of an eye. This happens when writing, too, but I can’t consistently write for 8- or 9-hours the way I can work on code.
I often had the impression (from comments I’ve heard in various places and times) that non-writers think that writing is easy. I find it difficult, and I’m fairly worn out if I manage to writer for more than 2 hours. Writing code is equally difficult, but I come away from these long stretches in what I call a “code-coma.” It’s hard to re-engage with the world around me, and I have to ease back in.
When I have something on the page that works, I’ll review it, often out of context of the rest of the piece (often because “the rest of the piece” doesn’t exist yet). I’ll find typos here and there, little misspellings, or autocorrects that don’t work. Same thing when writing code. Punctuation is just as important and I can stare at a small piece of code for an hour wondering why isn’t working, only to realize I was missing a semi-colon somewhere.
Sometimes, you get pretty far along in a story only to realize that you’ve uncovered a major hole in the plot. This happens with software, too, but it happens less frequently for me these days because I “outline” the software and try to eliminate plot holes in the design before we actually start building the thing. Still, other things may trigger major changes forcing rework.
When I think a story is ready (always after the second draft, never after the first) I’ll send it out for critique by fellow writers. It’s no different with code. We sit down for code reviews where it becomes our job to ask each other (and ourselves) tough questions about the choices we made. These are both incredibly useful and incredibly disheartening. Code is always improved in these reviews, but I find it disheartening that I couldn’t think of some of the elegant ways my colleagues suggested for improvement in the first place.
(In the movie business, I think the information that comes out code reviews would be akin to “notes.”)
The draft of a story that goes to the editor might be considered a beta (or a golden master) in the software world. It is almost good enough for the world, but subject matter experts (editors, copy editors, publicity people) will look at it and offer some final polishing suggestions.
Finally, the book or story is out in the world! Hurray! And of course, the first slew of reader comments, and reviews start coming in. They are all pointing out the typo on page 5. How did anyone miss that?
It’s really no different than the day the software you’ve been working on for a year or two goes live. You’ve run millions of unit tests. You’ve demo it, you’ve made it as easy to use as possible. And 2 hours after it goes out, someone finds a bug that should have been caught 6 months ago.
I think the biggest difference between creating software and creating stories is that with a story, more often than not, you have something to hold in your hands, the product of your long hours of labor. It might be a printed manuscript. It might be a copy of the magazine the story appeared in. It might be a book. It always gratifying, on those rare occasions when it’s happened to me, when someone hands me one of these things and asks for an autograph.
With software, there’s nothing to hold, nothing you can grasp in your hands that represent all the blood, sweat and tears that went into its creation. It’s probably for the best. In thirty years of making software, no one, not a single person, has ever asked me for an autograph. If they did, I’d be a loss: there’s nothing on which to sign my name.
- Which explains why this post is coming out at nearly 7pm instead of much earlier in the day ↩
RSS - Posts