I’ve a few friends that are writing novels. I spent a few months banging on what I call a “bad fanfiction” following a bit of advice I read from some professional book on writing fiction. Since it’s not mine (I don’t own the IP, yeah, I’m still a tech guy) I won’t publish it, but it was (and still is, from time to time) really amazing. I have 260,000 words into it, for instance.
And most of them, all but about 250 I think, are junk. So, 259,750 words are garbage. That’s the math.
Those who have read my blog know that I’m a software developer more than a writer. But I discovered that there are many facets that are the same and oddly, some skills that work well in both.
How Developers and Authors are Similar
I’m using the term developer loosely, because “software development” starts with a someone having a problem and ends with a deployed system that (ideally!) solves that problem.
When working with requirements elicitation the mode of operation is learner and not master. No matter how well I know a domain, when I sit down with a client to understand what they need I must understand I know nothing yet.
That’s even more true for writing fiction. It doesn’t matter what you know. Even physics doesn’t matter if you’re writing fantasy! Instead, within the world of your book, you have to discover everything. And it’s fun — unbelievably fun.
Once you have your initial requirements, you attempt to assemble what you’ve learned into a coherent whole — an understanding of the problem. This is when there’s tons of UML diagrams, UX mockups, spreadsheets or scripts, and depending on the scale of the project, perhaps even a prototype. All of this is to avoid premature coding, which is incredibly expensive.
In fiction, this is where the notes become the “worldbuilding” and may become a bible. Video games have the same aspect here. If your story needs a culture where there’s a rigid hierarchy (think, ant colony with workers, soldiers, and a queen) then you define the hierarchy. Since fiction requires conflict, you decide what would be a problem (a soldier who rejects guarding the colony and takes up egg care for instance).
For creative writing, there are two common approaches: plotters and pantsers. Plotters work from plans and outlines. Panters work by “the seat of their pants” and just sit at the keyboard and let their muses run.
Oddly, software has these also.
For plotters, at some point, the software project has enough understanding of the problem to define the roadmap and architecture. Sometimes, those are very vague and there will be months or years of iterations. Sometimes, it’s a two week gig and three iterations will get to ship. Think “novel” vs. “short story.”
The other software approach used to be called hacking before idiot non-technical people made that a dirty word. This is software pantsing. The developer sits down, opens the editor, and just starts. There will be a lot of cut/paste (never copy/paste) and continual refactoring.
Pantsing vs. plotting is a debate I’m not going to get into. It’s almost as bad as the debate vi vs. emacs. What’s interesting is that both approaches work and lead to successful novels — and both work and lead to successful software.
But both have other interesting effects.
Pantsers (in writing and software) rapidly get a version — and then spend an enormous amount of time re-doing (revising or refactoring). I alluded earlier to this, but it’s not clear that it can often be more than two or three times the amount that is eventually shipped. This means a pantser in software can be recognized because they’re always “nearly done.” But if you ask them how they know, they can’t give you any basis other than feelings.
Plotters (in writing and software) have their roadmaps and architecture. They systematically work a plan. They will (on average) take longer than they expect, but they can say “I’m done with the first section. The second section has a problem with pacing and I’ll need to add a subplot to split the needs.” And the developers can say “Our ETL is done. We’ve got acceptance on the UX for the first phase and we’re working on a concurrency bug under load.”
Regardless of plotting vs. pantsing eventually a draft (a version) is ready. And the moment of anguish — it is sent out. Beta!
Nothing shows you your errors like feedback. I can’t honestly say if being told your writing doesn’t work is more or less painful than being told your software doesn’t work. I’ve experienced both. I hate when things don’t work. And so, more iterations of fixing it.
With luck, a writer’s work is picked up and published (or self published and readers read it). I’ve no idea what the success rates are for writers from “I’m starting a book” until “It’s on the shelf.” I suspect it’s MUCH harder to become a published author than to ship software, though.
On the other hand, the CHAOS report shows that less than 29% of software was successful in 2015. The author who’s work isn’t published wasted time. Those non-successful projects hemorrhaged billions of dollars.
So, it’s hard to do both. I’d say that’s very similar.
How Does Development Help Authors?
For full disclosure: I was pantsing my bad fanfic. The reason I was pantsing it is because I had no direction and was using each section to practice the mechanics of a creative writing skill.
For instance, I had a prolog. I didn’t need one, but I wanted to see the effect of “character with a POV that is different from the main character to set the stage.” I also knew prologs should be short, so I rewrote that thing lots — I’d have to pull git (yes, I use git and Scrivener) to count how many times.
But, I am accustomed to coding something, having it work, but not be “good enough.” So re-writing it. Sometimes, “good enough” is. Sometimes, it’s not. When code looks funny, it’s broken. And rewriting often leads to rethinking, which has routinely allowed me to gain insight into the software that improves the representation of what I’m attempting to solve.
Likewise, I decided to try an action sequence with “fast cuts” where multiple POV characters were constantly involved in a single chapter — very short scenes. I did the destruction of a city. I even named the chapter Judgment Day. Yep, it’s obvious why I’m not ever going to publish. Talk about getting sued by artists I admire!
I couldn’t do it. I couldn’t get all the pieces to align right.
I was … surprised. I mean, sure, I’m not a screen writer. Nor a great director. But, come on! It’s just words!
On the other hand, I realized that it’s not actually different from multi-threaded code. So I broke out Enterprise Architect and setup a swim-lane based concurrent activity diagram.
Suddenly, it was easy! Pantsing couldn’t cut it, but drop into formal UML and let’s face it, there’s a reason that UML rocks. Of course, most authors don’t happen to have UML tools, so they do it the hard way with lots of textual notes, and I guess lines.
I found that state diagrams fully captured the intended and unintended social systems. Violate the diagram to generate conflict. Unlike a computer program, characters CAN break the rules …
Fundamentally, a novel is the event log of an entity passing through a system. The notion of point of view (POV) character is what’s being logged. Each plot is a thread. Scenes are consistent with computations. Each scene has inputs, processes, and outputs. Ideally, most of the scenes make things worse for the POV character. Being a character in a story is really awful!
And I found that writing and coding were both fun. Granted, they both worked the same part of the brain. When I had something to code, my creative writing stopped.
How Does Creative Writing Help Developers?
Something I read about from all the books on learning to write creatively was that “characters would take over.” I thought this was rather peculiar, since technically characters exist only in the author’s brain and we’re not actually infested with alien body-snatchers.
But then, I experienced it. And it was astonishing. I sent a minor character into a scene to gain permission for a young girl to attend her friend’s first time acting as a page in a court. The character got clever, and without me having planned it, caused a total political nightmare and got his queen’s niece squired to a foreign court. Oops! But, it sure threw everything I’d expected out the window.
I didn’t consciously plan out that scene to be a major plot point. It was, actually, an attempt to smoothly change POV characters. But, what it did to my story … wow. Suddenly, three kingdoms were in conflict, and a minor character became a major character.
And that was one of the better bits of text (among the 250 good words). It flowed out, it “poured sweet and clear” as Old Blue Eyes said in the song “A Very Good Year.”
Of course, I don’t know how to cause my characters to take over (I suspect, if I figured out a way to do it on demand I’d make more money than Bill Gates or Elon Musk). But, it’s happened more than once.
After that, when I was writing a bit of Python, I realized I was in fact seeing the same thing. Because technical writing doesn’t have POV characters, there’s no sense of the characters taking over. But there’s absolutely the calm flow leading to an insight from which code flows that’s both elegant and beautiful.
I can’t cause that to happen in coding either. Same issue. But, having made the connection, I realize that I work in quiet rooms with no background music, no headphones, and with lots of screens showing me (always visible, not flipping between windows!) all of my context … precisely because it lets me enter flow and that increases the odds that I’ll do better work. I’m using flow in the sense that it’s used in Peopleware by DeMarco and Lister.
This is a crucial lesson for people who run software projects: you want people to spend time together to collaborate, but you also want people to have peaceful quiet to do the thinking based on what they learned collaborating. When my partner and I setup our office (when we had one) we made it a point to have private suites and a conference room. That way, we could close doors and work, and we could meet without bugging anyone else. It helped.
My home office is the same thing. I have multiple 4K displays, write-on Cintiq displays, and a projector for the wall driven by an Apple TV that I can cast the whiteboard to. This is my personal office … but I need the projector so that when I pace (on my treadmill facing the wall) I can have context that I’m thinking about.
When I used to work at client sites it was always cubes and headphones. And interruptions. That’s not a good model for creatively writing nor creatively coding.
What About Writer’s Block?
I have friends who can do everything except generate prose on their keyboard. Even one-line emails like “Sounds great! Catch you at lunch!” are a challenge. I have friends who “get stuck” in their novels and … time just passes.
For software development, the problem is actually radically different than for prose writing. For development, a blocker is generally an objective problem. For instance, a bug will slam a developer to a halt until it’s found. Or re-writing something because it uses too much time, memory, or storage. Those may be frustrating, but we know we’ll figure out the issue and be back on track.
In prose, there’s rarely an objective issue. The pace is too fast, or too slow. The characters don’t seem to have any “zing.” The writing is dull.
I am killed by pace. I read approximately 30,000 words of fiction an hour, and I read over meals and in the evenings. I often read all weekend. I read lots…routinely, six or ten novels/week worth. I read fanfic because publishers don’t put out enough content. I go through published novels as they come out. I re-read all 15 of Asimov’s Foundation novels (yes, 15) over a weekend a couple of weeks back.
I know good writing. When I think the pace if wrong, it’s wrong. I recognize bad writing, and mine is bad. Better than it was, but … bad.
Now, perhaps using the best writers in history as a basis for evaluation is foolish — but what’s the alternative?
So, at times, my bad fanfic stops because I re-read it and I’m not sure how the masters do it. I re-read professional writing and it practically pulls the reader in. I can’t do that. Yet.
And in that sense, my progress halts. It seems like writer’s block. Because unlike software, I can’t visualize what it ought to be. I only know it’s not what it should be.
Imagine trying to “fix” a Python application where the user’s feedback is “I don’t like the feel of it.” What should I change?
But for a fiction writer, that is precisely their world. And honestly, I’m not surprised that at times progress in fiction halts.
At times, we developers have it easy. The compiler may be brutally honest, but at least it’s objective!
I’m glad I spent so much time and words writing that bad fanfic. Sure, it won’t get published. But, what actually happens with fanfic that is good?
Naomi Novik created an exceptional series about a dragon named Temeraire from the fandom of an excellent historical fiction series.
The novel and movie Fifty Shades of Grey started off as a fanfic from the Twilight novels.
Mine isn’t good. I really love Novik’s works (she’s one of my “buy every new release without reading the back cover first” authors). But that’s OK. I have no doubt that I’ll enjoy the bad fanfic for a long time. And I know that exercising that level of subjective challenge will make my objective development challenges easier.
I think it’s telling that many good authors are from IT too … I’m not the only one who cross-polinates!
Keep the Light!