On Decision Making

When I began writing, my sole objective was to create the kind of story I wanted to read. That meant a world with depth, history, airships, and some light fantasy elements. It meant relatable characters born my own life experience. It meant an adventure story with cruel realities and misguided expectations. I wanted it to be fun to write and fun to read. I managed to convince Josh to help me with this and for some reason he included me on what *he* wanted to write. It took some discourse over many drinks, but it quickly became *our* book.

Though the product is wildly different from our initial 2012 outline, I regret nothing when it comes to the development. Josh and I have endlessly debated and tweaked the narrative based on our own ideas for what *our* story should be. Though I find we’ve easily discovered compromise within the broad strokes, we often haggle over nomenclature and each make unreasonable demands on what should not – nay, cannot – be altered. Some debates are kicked down the road time and again, the resulting line item looming in perpetuity inside the NextJam file. Only when the shame becomes unbearable, and self-imposed deadlines lie within sight, that we force ourselves to blunder into a resolution. I hope our tens of eventual readers never come to know how much time has been spent unearthing cogent names of irrelevant landscapes.

Sometimes the topic of marketability comes up. Who is our audience? Are we marginalizing X? Are we forgetting to include Y? Who will this even appeal to? Most of these questions still hang in their air unanswered. We stare at each other in silence before shrugging to continue writing the story we want to write. It is inevitable someone will stumble upon our work and wish it was something else. We cannot either cater to, nor please them all.

At the outset I wanted to shop our book to the traditional publishers. It’s respectable, I argued. The grand institute of validation. Josh had his reservations, but gave a silent nod of reluctant assent and entertained my ambitions. And so we dipped our toe into query letter writing. The idea of distilling your work to under 200 words, without spoiling key plot points, is a task unto itself. Josh did the brunt of the work, with me chirping unhelpful, distracting critique. The fruits of that labor can be found here and all praise should be heaped upon my co-author’s dark altar of broken PSUs and hoarded coax cables. The querying field is littered with mines, intended to whittle sparse wheat from the frequent chaff put before agents and publishers. Feedback we received from the query letter writing community provided us with some key advice that pushed us towards making some important decisions trending towards self publishing.

1. Our book is too long. For first time writers, a 300k word book is unlikely to be considered by a literary agent, much less a publishing house. Getting someone to read your query letter is a chore in itself. Having an agent digest two unknown’s lengthy manuscript might be a near impossibility.
2. We would split our book. Book 1, as it was intended, was outlined and constructed as three distinct acts from the get-go. Each act still comes in around 100k words, a healthy book by itself. The editing to smooth the transitions has been comparatively minimal, thanks mostly in part to our initial construction for narrative arcs.
3. Marketability. Because we are splitting the book into smaller pieces, we can price our work more competitively. This might just be my instinct, but buying an unknown author’s $9-10, 300k word book is a risky proposition, particularly with the minimal-marketing self published approach. But three books averaged out at $3 apiece might entice readers to actually take a chance on the first volume. Once we have established a body of work, using Volume I as a loss leader into the greater series might work in our benefit.
4. There are existing champions of self publishing. While success stories like Hugh Howey and Andy Weir are encouraging, we by no means accept it as the norm. But the available data is trending in the favor of self publishing.
5. Edit. Perhaps this is low-hanging fruit, but before we shit our first book onto your Kindle, the work needs editing. And then more editing. It needs to be honed, sharpened and reforged again. If we fuck up here, we’re perpetuating the stereotype that self publishing is for amateurs.

And so we take our time. Josh and I have been working on this project for over four years now, and while we do not have a definitive date to foist this upon the cold, unfeeling world, it *will* make its way out there. We’ll stumble and make some mistakes. But we’ll already be working on the next installment, so our fervent, insatiable eight readers will not have to wait long for Volume 2.

Process Imagineering, Part 4: Task Manager

Ok. So. Status meetings. Planning. And communication.

If I didn’t know any better, I’d say I was teaching a shitty project management seminar at the community college. Or living my recurring nightmare, where everyone just talks in management buzzwords.


I work as a computer programmer in a pretty classic office environment. Cubicle walls. Motivational posters. The dull hum of the A/C unit directly overhead. Awkward coffee pot etiquette. But the work is interesting, and I feel capable and accomplished in doing it.

This year, I went in for a ‘lead’ position among programmers and somehow got it. The new position, while putting the ever-prestigious ‘Lead’ in front of my title, doesn’t really having me leading anyone or anything. I mean, I can inform decisions, and make recommendations, but I can’t really tell anyone what to do. Which, to me, is pretty perfect.

I like what I do, and I can’t really see myself being any happier if I ever get promoted to a management position. Management seems like one of the most boring things in the world, filled with budgets, due dates, and endless meetings. You are responsible, for better or worse, for your decisions and those underneath you. All that, and you don’t even get to swing wrenches anymore. Which is what turns me off the most.

I’ve heard similar from other programmers (a preference to stay technical), but not as many as you would think. Not all programmers are die-hard code monkeys, looking to sling/fling code all the live-long day. A good number of programmers are only programmers as a stepping stone to greater career aspirations. They have some talent in the technical realm, but they don’t enjoy it. They have a love for the sea, but maybe they don’t want to spend the whole time swimming in it. The details can be uninteresting, and probably those looking up the ladder would rather deal with the more abstract and larger-in-scope aspects of technology. The system architecture. Design. Requirements gathering. Whatever.

That, or they more enjoy telling other people to do those things.

I don’t really ever want to be a manager. But I can appreciate what they do. And not just in a “I’m glad you’re doing it, and not me” sort of way. Managers, to me, have two very difficult jobs, answering two very impossible questions:

  • What should be done?
  • Who should do what?

Being a successful manager is finding good answers to those questions. Answers that save money, time, and keep as many people happy as possible. I say they are impossible questions to answer because there is never a right answer. Or at least not “right” within the narrow band of perfection I have become accustomed to in my career dealing with flawless automatons and strict determinism. Nobody will be perfectly happy with a choice you make for them, even if was a better one.

So. Why go on about all this? You thought this was a blog about writing, wherein we discuss the subtle art of putting ideas to paper and maybe talking about what it’s like to co-author a book. Not some weirdly entitled rambling about that one time an office worker got promoted.

Well. If you’re writing with someone else, and you’ve outlined all your things and you’re about to start writing, there are two, very important, and very impossible questions you will be faced with:

  • What should be done?
  • Who should do what?

You may notice that these two questions are the same as those above. Which sort of implies that co-authoring a book is as much about writing as it is about managing the writers.

You will, at some point, reach a point in your project, where you will have a list of things to do. That list will probably look like your table of contents, or even your scene listing depending how deep you went with outlining. You might look to your co-author and shrug, haphazardly suggesting, “Halfsies?” You might even go so far as Mike and I did and just choose to go down the chapter list, interleaving Mike-chapters and Josh-chapters in an AB-AB rhyming scheme.

If you’re at that point, and you have the opportunity to be reading this, stop for a moment. Pause. Consider that an AB-AB rhyming scheme isn’t all that spectacular. And consider that it is rare that things in life are as easy as they seem. Rare, tending towards never. Consider that you have a management problem. You will have to find a way to manage each of your time and resources in a way that gets things done and hopefully keeps everybody happy.

Otherwise the project fails.

If you reached the same conclusion, please, benefit from our hard-fought list of things we discovered as we tried to manage writing a book together.

Not all chapters are created equal

Not by a long shot. The first chapter? The one that’s supposed to grip the audience? The audience you haven’t met? And agents you don’t know? And their assistants, sorting through their slush pile after lunch when they are tired and sleepy and want to go home? The part of the book that will probably be given away for free on the Amazon book preview in an effort to show the world what caliber of literary artists you are and ultimately determine whether they hit ‘buy’ or just keep scrolling?

Yeah, that’s not going to be the same amount of work as the filler chapter where the main character has a good time going fishing.

First chapter. Last chapter. Action chapters, where you’ll scrutinize every action for whether it is too Jackie Chan, or not enough. Heavy dialog chapters, where the characters have to deliver tons of exposition while sounding like real, relatable people that readers will identify with. Chapters that switch point-of-view, or use a different tense, or storytelling mechanism.

They will all have wildly varying difficulty. You can certainly try to guess if a chapter will be a challenge, particularly if you’ve never written something like it. Just know that your guesses will probably be wrong.

Not all chapters hold equal interest to the writers

There. I said it. Sometimes, I just don’t care about the worldbuilding chapters. Of every thing I ask, “Why is this relevant? Why should I care? And why should the readers care?” And I have to realize that I am not every person. Not everybody buys a coffee table book about the history of word processing. Or buys Craisins by the four pound bag. Not everybody enjoys reading about the same things, and more importantly, not everybody enjoys writing about the same things.

When Mike and I divvied up our chapters, we didn’t always consider what we wanted to write about. For instance, I like my worldbuilding in the background, barely present, dripping into your heart through a pinhole until you realize you’ve been steeped in it. But for the chapters that need it, no, demand it, I find it difficult. The geopolitics of a place I’ve never been only interest me slightly more than the geopolitics of a place I’ve always lived. However, a chapter needs a throwaway sentence about a fictional magic system? I’m on it. That’s where I live. There’s where I feel strong.

Be sure to consider what your interests and strengths are when assigning chapters. Otherwise, you get Josh yadda-yadda’ing through some important world history, and Mike yadda-yadda‘ing the critical principals of flight to your pulp airship fantasy.

Not every chapter is one chapter

There. I said that, too. Though, not exactly as cathartic as the last. Basically: you might be writing a chapter, and suddenly realize it’s not just one chapter. In that case, you have some stuff to figure out. And likely, you’ll need to talk to your writing partner to hash out a bunch of stuff.

We had a pretty classic case of this with Volume 2 of Skysail. We had a chapter that we just called ‘Travel’. The original notes just said, “Traveling,” or something equally vague. We intended it to be our first foray into the actual traveling aspect of our world. After all, you can’t just be on an airship and not satisfy a little wanderlust. However, we quickly figured out that we couldn’t just have a ‘travel’ chapter, cutting from place to place. It didn’t fit with the tone and pacing we had set so far, and we still had a ton of story to tell.

That single chapter turned into five. And introduced complex action scenes, mysteries, dialog, and all sorts of things we didn’t intend. And, at the outset, they were all assigned to me.

We divvied them up later. But the point is that these things have a habit of ballooning unexpectedly. So expect it.

Not all chapters can be written right now

In fact, I don’t know how we really started on any of our chapters, other than just blindly mashing keys and hoping it turns out for the best. Every chapter we wrote has some degree of dependency to it, whether it is plot reference, character reference, forward and backwards consistency, or even just flow between one chapter and the next.

The problem is there is no root to all those dependencies. No one single place you can start from to say, “Hey. Everything starts here. So let’s get this part down first.” Your first chapter will depend somehow on the contents of the last chapter. And your last chapter will depend on the contents of the first.

The point here is to acknowledge this dependency and then try to move past it. Find chapters that, even if they have dependency, seem to have less of a dependency than others.

If you have to whiteboard it all out, do so, drawing lines between your table of contents entries.

pacman-illus-150dpi(Above: the original Pacman Source code, with lines drawn to show conditional and looping jumps that occur during execution. From Ben Fry).

Best case scenario: you find natural breaks to your story that you can use to split up the work. Worst case: you identify all of the things you both need to agree on before you get much further.

Two people can’t do the task of one person in half the time

In fact, there’s nothing that says it won’t take at least at much time as one person, if not more.

There’s been tons of study on the topic, but most of the phenomenon I’ve experienced firsthand in my programming career. Many hands are supposed to make light work, sure, but that’s, like, when you’re moving somebody’s couch. It’s not the same thing when you’re trying to design software, or, for that matter, writing a novel.

Novels have dependency (described above). Many hands make light work, but only if those hands can be directly applied at the same time. Some tasks can’t be done at the same time. Two people can’t work on the same chapter, same as two programmers can’t (easily) work on the same bits of code. They can work around it, or come to agreement on a common element in order to work separately, but generally they are serial tasks. Tasks that cannot be executed in parallel.

It gets worse. With every added worker, there is added inefficiency. There is increased need for communication, and increased likelihood of having to stop one person’s task to address another’s. There is friction, wherein two workers disagree on something, and therefore, cannot proceed without coming to some conclusion. There is the slipping of gears, where something catches, or breaks down, or misses a tooth when transferring work between systems.

We’ve suffered all of these in our project. Where some novelists can crank out a publishable piece in a year, it’s taken two guys four years.

Many hands don’t make light work. Many hands make a lot of work. But in the end, we are creating something that neither of us could create alone, so the ends justify the means.

10552612_titus-burgess-slams-homophobic-moving-company_t1dbfa238There is an idea in computer science called reduction. The Wikipedia article states it better, but essentially the idea is that if two problems can be solved using the same solution, then those two problems cannot be more ‘complex’ than the other. Reduction is fun, because if you can mathematically prove that a problem can be ‘reduced’ to another, then you have mathematically proven that a problem has a certain complexity without actually having to figure out its complexity. Computer scientists get off on that.

But I don’t really consider myself a proper computer scientist. I have a degree in the field, but I can’t really say that I’ve directly used all that many of the theoretical concepts they taught us. We learned about the nature of complexity, and what about is computable. Both of which are great to have at ready when someone asks you why something is ‘impossible’ and you can pretentiously inform them that it is ‘yet unsolved by computer science.’ But I’ve never sought to ‘reduce’ anything since I graduated. I’ll probably never contribute to the field other than evangelizing to rudderless college students that you will never want for work if you can program a computer.

So. I’m a bad computer scientists. Which is why my hijacking of the idea of ‘reduction’ isn’t the best. There is no algorithm that applies to project management that can then be re-used to solve something in novelwriting. I have no real way to show that they are both of the same complexity.

But I can say that both are complex. Both problems involve humans. Squishy, weird mammals that taught themselves agriculture and how to type. And that wrangling those strange creatures to do work is a difficult, nigh impossible task.

Some time after I had gotten the promotion, my dad asked me if I would ever want to be a manager. I told him what I told you, dear reader: “Not really.”

He nodded, then told me he used to feel the same. But then when he got into the position, he found that he sort of enjoyed it. He could dictate how technical he wanted to be, how close to swinging a wrench. But more importantly, he had the agency to make the right choice where somebody else would just fuck it all up.

Managing people and managing a book aren’t exactly the same things. But they share some of the same complexity, and the same problems. And, to some degree, they share the same idea of responsibility and ownership. We might be writing the worst airship fantasy book out there. And it might be a little bit narcissistic to say, but if somebody other than Mike and I were writing it, they might just make it worse.

There’s some satisfaction in that.


Process Imagineering, Part 3: Transport Layer

Giterary outright steals most of its good ideas. Maybe all of them. But that’s sort of what building software is all about. You see something, and you say, “Hey, that’s neat, but it doesn’t do X.” And you either live with it until something better comes along, or you hack something together yourself.


An idea that I stole from the coding world is TODOs. A TODO is a special comment in code that indicates to a later programmer that something remains “to be done” in the code, but works as-is for now. For instance, see here in the Giterary codebase:

// TODO: Label manipulation to allow for
// matching highlights.

    label:  value,
    value:  value,
    weight: weight

regex.lastIndex = 0;

(Code here)

The TODO in the comments above gives the programmer something to come back and search for when looking to making improvements. That, or to fix something that had to be left behind for higher priority issues. You use the word TODO rather than TO DO or TO BE DONE because there is no word ‘TODO‘ in the English language, and it’s unlikely that it will appear naturally. This means that it’s easy to search for the string ‘TODO‘ in your source code.

We use the same convention for our novel writing. We use TODOs pretty extensively. Often, there will be something that either:

  • We need to research more thoroughly, or…
  • We don’t have time to do said research, or…
  • We have to rely on the other person to answer a question or get feedback.

You don’t want to forget to come back to the section, but you also don’t want to waste the precious little time you have. There are only 45 minutes you have before the yoga moms get out and start hogging the cafe WiFi while their miserable children run amok. So, rather than losing your place and your flow, you just put a ‘TODO‘ into the text and promise to yourself to revisit them periodically.


At time of writing, we have about two hundred TODOs left to resolve and document. This is down from the nearly four hundred we had before. Here are a few choice examples of our TODOs, littered among the chapters and marginalia of our repository:

  • TODO: Lighthouse (because we like to have the notion of a lighthouse at every sea or sky port)
  • Religion - TODO Polytheism (because we are bad at naming things)
  • BE —400 Kingdom of Cail founded by the TODO family. (again, bad at naming things)
  • TODO: Consider a chapter break here (because we write marathon chapters and need to split)

As we get closer to publishing, we are also treating the presence or absence of TODOs in a document for whether something is worthy of publishing. If something still has a TODO, it requires some degree of modification before sending it to an editor. However, if the TODO is something more like, “Remember to include this later when you write this part,” we actually call this a ‘Callback’ or CB. TODOs and CBs in Giterary are exactly the same. We just treat them each a little differently in our workflow.

So, TODOs are messages embedded in our writing. Messages to remind us of something. Messages to keep us anchored where otherwise we might forget something. Messages to each other. And messages to ourselves from the distant past.

They’ve got their problems, though. A few we’ve come across:

  • We’ll forget what the TODO is about.
  • We’ll disagree with the TODO after enough time has passed.
  • More work is spent talking about resolving the TODO than is actually spent resolving the TODO.

Take for instance something from earlier this spring (Spring 2016). I added a TODO as a hidden comment to the end of this paragraph at the end of Volume 1.

The second attacker hit the deck running and skidded to a halt in front of Vasili. The boy found himself frozen in terror, his eyes locked with tinted goggles. The man’s mouth split into a savage grin full of yellow teeth and he raised his sword. Driven by instinctive reflex, Vasili found a surge of energy and kicked at a plank. The piece of wood skidded across the deck and took the goggled man by surprise, catching his toe and making him stumble. Before Vasili could regain his own footing and make a run for it, Hash was there, his sword spinning in the light. Like in the tavern, there was not much of a sword fight, only a single off-balanced parry and then the quiet man’s blade was cutting through the attacker’s stomach. JAR: TODO We should talk to choreograph this out. As is, I'm a little confused.

I hit commit and walked away. I find that if I go and do something else while I’m thinking through a problem I can focus better. I was busy preparing for the ritual of my yearly car wash. I don’t know what Mike was doing. But I got a text pretty quickly after.

Mike:   I'm curious what you find confusing about the Second Attacker in Consequences.

‘Consequences’ is the original name of one of our chapters. They have all since been split and renamed, but we still refer to them by the original names.

Josh:   How does he kick the plank such that it trips a guy? Particular a guy who just came down a rope and landed with a sword in hand.

I worry a lot about details. This was one where I thought an unfinished piece of wood wouldn’t slide very well, even on a polished deck (and the Break’s deck is not polished). A kicked ball would have a time getting across the deck. Friction would be a problem.

Mike:   Maybe stumbles is a better word. Even if he jumps it, it buys Vasili five seconds of life for Hash to rescue him.

I agree with Mike. My TODO just reflected that the recent edit didn’t work as intended.

Josh:   Thinking that the wood is heavy, and would just slide across the deck with plenty of time for 2nd to lift a toe and stop it. Maybe that's it? It's just a distraction?

Mike:   Also, he's wearing goggles, which might limit his vision.

I try to clarify, my hands wet with soap, water, and chamois, challenging the degree of water proofing that was done on my phone.

Josh:   I'm just not seeing Vasili Jackie-Chan-ing a plank. I'm seeing him do something odd and confusing the attacker.

Mike defends his edits.

Mike:   I just don't think it's necessary to describe anything further. He does something and it's effective long enough to save his life.

        Maybe he throws his axe, perpendicular to the guy, as if one would say “catch!” And toss an implement to a friend.

My neighbors keep looking at me as I start to spray down my car, then stop, text, realize the car is already drying, and then start spraying again.

Josh:   Nah. Vasili is scared shitless, how would he come up with that?

And then the juice, the description and inspiration behind what Mike intended with his edits.

Mike:   He's scared, but it's that part of the brain that just reacts. Not calculated, otherwise he might take a swing.

        Same with the kick of the plank. it's like you just react with what you are given.

        When I scared my friend Pat with my tshirt over my face and a butter knife, he uttered some guttural gasp and gave me a rabbit-punch to the chest

        I guess as a contention to that point, Vasili has done nothing in this fight, and by giving him a redeeming quality other than chopping at the lines, our readers might empathize with him a modicum more.

        So I don't think it's a Jackie Chan plank elevation kick to the gut, but a “fucking shit I'm going to lash out with whatever I have”

        And this 2x4 skitters over the deck and the guy slips on it, or jumps it, and is distracted long enough.

Josh:   Can we never decided book stuff over text? We're talking about the same thing.

        Plank is distraction.

Mike:   Can we exclusively talk about book stuff over text? I want Vasili to cartwheel-grab this guy by the neck and fling him overboard Xenia style.

        Then drop into a cautious crouch.

Josh:   I quit.

Don’t let this be you.

I include the above conversation to show how not to communicate. If something is confusing, I guarantee that text messages will compound the issue.

Find some way to provide consistent communication, as well as choose a medium that lets you review past decisions. Email chains, Slack instances, or something like Giterary that will track TODOs go a very long way, as they have features that allow your messages to become documentation. SMS messages, and messaging schemes like it, do not. They are intended for quick, throwaway communication that has no expectation for long term storage, search, or retrieval. Phones die, and text conversations get archived and deleted.

As an author, it is your job to communicate ideas clearly and unambiguously to your readers. As authors, plural, you are doing the exact same thing, but in addition you are communicating directly to your co-author. Your communications between each other are just as much documentation as your notes and sketches. Having a system like the TODOs certainly helps, but being mindful about the nature of your communications is just as important. As Mike can attest, I’ve now quit the book a half dozen times, facetiously or otherwise.

Finally, if you do end up using TODOs in your work, please heed my advice: make sure that your notes surrounding your TODOs are clear. It might be next week that you fix that TODO. Or it might be four years later. But nothing keeps you up at night wondering what you meant by TODO: “Come on, son".

In this way, the workflows of novelwriting and computer programming are much the same. You have large collections of text documents that must be continuously updated and maintained. You might not have the immediate time, energy, or interest to solve all of the problems that you come across during your writing/coding sessions. But you will over a long enough period of time. The problem is the writer/programmer forgetting something.

Each word of a novel is part of a machine with a few hundred thousand moving parts. And you, as the writer or the programmer, are the flawed, squishy pulp with a small short term memory and a faulty long term memory. You can’t possibly remember each piece, each intention. Or even if you do, you may no longer have a handle on whatever emotional truth you were trying to convey. I can say for certain that we didn’t remember all of our TODOs when we came back to them. Some we had to give up on, and be content to assume that it must not have been that big of a deal to begin with.

In doing some research for the book, I read about super long-lived trees. I found that, depending on the size and age of a trunk, the innermost parts of a tree trunk are actually dead, having succumbed to age or decay. The wood material remains, providing structure to the tree, but the living part is only a thin layer towards the outer edge of the trunk, growing bark and more tree rings as the seasons march on.

To some degree, writers and our projects are just the same. The author is the thin part, just beneath the bark, that grows it outward.

Here is the latest version of the paragraph (with modifications underlined):

The second attacker hit the deck running and skidded to a halt in front of Vasili. The boy found himself frozen in terror, his eyes locked with tinted goggles. The man raised his sword, readying to attack the boy. Driven by instinctive reflex, Vasili found a surge of energy and kicked at the end of a plank. A distant pain came from his toes. The heavy board slid across the deck towards the man, slowing to a disappointing stop as it nudged the heavy boot. The man looked down for a moment, perplexed, then his mouth split into a savage grin full of yellow teeth. A blade spun in the light. To Vasili‘s relief, the momentary distraction gave Hash what he needed. Like in the tavern in Schultzwald, there was not much of a sword fight. A single off-balanced parry and then the quiet man’s blade was cutting through the attacker’s stomach.

No telling if all this effort makes an improvement, but eh. On we go.


Process Imagineering, Part 2: Plans, Plumbing, and Porcelain

Okay. Great. So we hold status meetings for our writing stuff. Same as everyone else who works in an office. Gee, thanks Josh. Truly, this is revolutionary stuff.


We will certainly take the co-authoring world by storm.

My point in talking through our jam sessions (status meetings) was mostly to introduce the idea of continuously clearing snags for the other person. But there are other reasons. Chief among them: to plan work. That is, come up with the stuff you plan to work on. That way, when each of you go off and attend to your own devices, you’ll both have a clear idea of what you’re supposed to be working on.


We probably had, oh, I don’t know… a year? We started outlining mid-2012, but didn’t start principal writing until late 2013. I’ll say there was at least a year of jam sessions where all we talked about was the book’s thesis, the characters, elements of the worldbuilding, and what the hell we would call certain things. Again, if you’re a solo author, all of the decisions are up to you. If you are not, you have to be clear with your intent otherwise you end up going in the wrong direction, or worse, you end up duplicating some amount of work.

Some authors are what they call ‘pantsers’, by which they mean that they ‘fly by the seat of their pants’ when writing a book. I find this wholly alien and bizarre, but that’s just who I am. And while a perfectly reasonable way to crank out a book, it would be completely untenable when two authors are in the mix. If you have two pantsers, you will write two completely different books.

That should be the end goal of the repeated jam sessions: to ensure that you are not writing two different books.

Those first years of jam sessions were spent working our way through the following:

  1. Thesis. Establishing the core questions and concepts that the story should ask/convey. Sort of like a mission statement, but less lame. Find a thesis, or set of theses, that you both agree on, or else you will be writing different books. Do not proceed unless you have a set of theses you both agree on. You will revisit these repeatedly.
  2. Character. Establish the characters that will support your thesis. Get as detailed as you need so that both people feel comfortable writing in their voice. This might involve writing some prototypical scenes to see if a character trait works. Iterate until you have a cast of characters you both feel give you the tools you need. Do not proceed until you have those characters.
  3. Outline. Establish the story outline. Start broad, then get detailed. We had a numbered list of things that we wanted to happen in a book. Things that had to happen. We broke that list down by chapter, and had a list of things that would happen in each chapter. The outline forced us to choose when and where they happened. Both authors should know what each chapter should be about and what thematic and emotional tones should be present. Stuff can always change, but having an outline you can both look at and agree upon is very important. Do not proceed until you have a chapter outline.

There are lots of resources out there on how to approach thesis, character, or outline. And better than I can relate here. More what I am after is getting them down, and agreed upon, so there is no confusion about the core elements to your story.

Once you have both agreed, you’ll have to start in on planning the actual chapter contents (environments, dialog, scenes). It’s not enough to just agree on a thesis and go. You will have to collaborate on the chapter content as well. I found that the best way to convey planned/intended chapter content was to hash out either:

  1. Storyboard. Establish storyboards. It’s relatively easy to write an outline. It’s harder to actually block out locations, dialogue, character movement, and scene progression, keeping all of the variables in your head and making them logically consistent.

    Write out moment by moment storyboards as if you were going to film the thing. That way, both of you can have the same image in your head of what is supposed to happen.

    You can choose to storyboard first, or you can choose to write your dialog first.

  2. Dialog. For me (Josh), cranking out dialog is the best way to lock down what you want from a scene. I try to write dialog with the intent that if you took everything away (narrative, exposition, thought bubbles, etc.) that the dialog would tell the same story. It’s hard to write good dialog. But it’s easy to see bad dialog. Finding things for the characters to discuss, making their conversations believable, and their intentions relatable is core to making someone care about what you write. Everything else is window dressing.

There’s nothing that says you can’t storyboard and write dialog at the same time. The visual elements and character environments tend to inform the dialog, and the dialog informs how characters emote and interact with their environment. Forcing your dialog into a visual storyboard also helps so that you don’t just have talking heads reading their lines back and forth. Characters should never (read: rarely) just be talking.

So, at this point, you are probably regretting getting this far in reading this. I’m telling you what you already know. Like your disappointment in the first paragraph, my pushing of the food around on the writing process dinner plate hasn’t been all that informative. Why have an entire article about planning when you could easily summarize it as “Have a plan, and if not, make one?”

Well. For me, it’s the difference between plumbing and porcelain.


Please. Don’t go. Let me explain. I’ve got something for this.

Mike and I use a number of tools, but at the very core we use Git. Git is a piece of software that is a version control system (VCS). Its lot in life is to track a directory of files, keep past versions, and let us see differences between old and new.

This sounds pretty simple. But among the popular VCS products, Git is pretty complicated and obtuse. It is famous for having hundreds of obscure commands that, while very helpful and powerful in some situations, usually require some degree of Googling to find what you want. Eventually, you get used to the pain. Or you just write more software to make it easier.

There are so many commands that they divide them into two categories: plumbing commands, and porcelain commands. They use the different terms to describe the lower-level, background functions of Git (the plumbing) versus the more human-friendly, human-readable interfaces for Git (the porcelain). The programmers of Git, in their infinite wisdom and wry sense of humor, decided that the best analog for describing the difference between these types of functions was the concept of waterworks in your house. Because toilet humor.

The idea is this: you generally don’t deal with your plumbing every day (unless you need to make modifications or fix something). But you will definitely use your fixtures (your sink, your bath, your probably porcelain toilet) often.

Git plumbing functions are intended to have well-formed interfaces whose format will (hopefully) never change. Output is reported such that another computer program can interact with the interface and get what it needs with little fuss. This makes plumbing functions ideal for consumption by and interaction with other software, given that they are easy to program against and have some guarantee that the interface will not break in future versions.

Git porcelain functions have no such guarantee. Their interfaces are intended for consumption by humans. Fickle, capricious humans, that speak of love and beauty and want computers to know what they want without having to describe what they mean.

So. What does the concept of plumbing and porcelain have to do with planning and the writing process?

Well. The planning process is the plumbing. The writing is the porcelain.

Planning is making sure everything is mapped, and that the right pipes are going to the right places. Your theses need to be present in every chapter, and your characters and their scenes need to be able to convey them. You want a pipe and a drain in every room that needs water, the right valves, and both of you agreeing on where the sink is.

On the other hand, the writing is where all of those pipes meet fixtures, and ideas meet readers. Where your porcelain meets the… hands? Because they’re porcelain knobs… Nevermind. The writing-porcelain is sentence structure, the word choice, the meter, rhythm, and balance. It is the handle you twist to get the hot or cold you want. It is the interface that makes sure all of those things are put together such that a human will read it, understand it, and want to read more. And as you grow as writers, you will eventually say to yourself, “Man. I don’t know why we chose dark gray for the toilet. And why is the tank 6 feet off the ground?” The porcelain is relatively easy to change, and will probably be swapped more than the plumbing it connects to (provided you’ve got good plumbing).

The plumbing and the porcelain of your writing must inform the other. When it comes to good storytelling, neither should exist in a vacuum. But there is a pretty strict order of operations. Plumbing comes first. Because you should absolutely be done with the plumbing before you start putting in any toilets.

You might say, “You started in 2012, but you didn’t start writing until, like, late 2013? What gives? Just write. Figure it all out later.”

It’s because it doesn’t how matter how nice a toilet, nobody should sit on it unless it will flush.

Process Imagineering, Part 1: Holy Jam

When you tell people that you’re writing a book there are a handful of responses that usually come up.

First, and by far the most common, is the “Oh. Neat.” Their tone is somewhere between vague, non-commital interest, and the frantic Oh my God realization that they’ve opened themselves up a conversation they never wanted to have.

Second are the skeptics. “Oh. Really?” they ask. They are the ones that look at you like a stranger, wondering at what point they mistook you for a normal, well-adjusted person. Their eyes go blank for a moment as they trace their path to the present in an “it was there, right in front of me all along” montage. The flights of fancy. The introverted, narcissistic behaviors. All of the times Josh corrected you on pronunciation in front of everyone. Their eyes snap back, ready to head you off at the pass before you try to recruit them for beta reading.

Third are the curious. Those that have a bunch of questions. They might initially start as the first or second cases, but they find themselves resigned to their fate. They want the satisfaction of finishing a conversation, or the accomplishment of getting through one with me. They realize I just want to talk about the thing I am interested in for a few minutes. In this case, the best way out of the hole is to keep digging. Ask a question, nod understandingly, then walk away. Everyone gets what they want and nobody gets hurt.

How long have you been working on it? We’ve been working on it for four years. What’s it about? Scifi fantansy. How long is it? We wrote way too much. Wait. You said we. Who is we? Oh, me and my co-author.

This is where the decision tree for people starts to break down, the branches cracking off and the trunk listing badly. The world made sense in that Josh would be the weird, quirky author type. He does all that stuff with computers so that sort of makes sense that he’d be into all those orcs and elves and dwarves and shit.

But the equation changes when there are two people in the mix. There is only really one branch left on the decision tree, one question: How the hell does that work?

The insect machine thing deep within me starts spooling a lengthy, unsolicited lecture on the importance of tools, backups, traceability, and accountability. It never really lands, and I usually just sound crazier than when I started.

When I’ve heard Mike answer this question, he just answers, “Slowly. Very slowly.”

I should take notes. Those asking the question aren’t curious on what we use to do it. They are curious how, at a very basic level, do you sit down and both arrive at the same creative vision.

Well. Here it is. The one time I attempt to answer a question in a straightforward manner, and maybe even answer the question that was asked. This is your moment, Josh.

This post will start a series that will detail all the weird things we do, and hopefully answer the question of how this all works.

The Holy Jam

When an author sits down to hash out a chapter, crank out a scene, or wrench on some dialogue, there is some pretty crazy stuff going on. My background in computer science has no way to adequately quantify it. For someone to start with absolutely nothing and end up with a string of symbols that represent natural language that describes a story that other people would want to read is mystifying. It is one of the many things that we will struggle to mathematically or computationally model for a long, long time.

That said, the human brain does this kind of shit all day. We can contextually identify objects from a continuously moving field of vision. Or maintain locomotion using muscles that we had to learn how to use from scratch. All while processing billions of sensory inputs. And the most difficult part of it all is having ‘Fight Song’ stuck in your head one more fucking time.

So, the question is: what happens when you have two authors? We don’t have wiring for telepathy or mind-melds. Mike and I, though we share a lot of the same interests, are not exactly of the same mindset. We are, in fact, pretty different writers, both in method and style. So how do we come up with something we both agree on?

Well. You get together and jam. Jam session, that is. Like musicians do. Except a lot quieter. So far we haven’t been banished to a garage. Except for that one time we had to stain Mike’s doors.

A writer-ly ‘jam session’ probably isn’t the best name for it, but it’s the best fit we have. The purpose of a musician’s jam session is well understood. It is to rehearse. To practice. To figure out problems before they happen during a performance. Or just to get better at playing with people. Or just to drink and have fun.

The purpose of a writing jam session is a little muddier. The jam session isn’t a write-in. It isn’t a team writing exercise (also, those never work, regardless of whether you’re drinking). It isn’t where you sit and read each other’s work (unless there have been quick edits since you looked last). You should both be caught up, and either be in agreement with the other person’s work or have items you want to figure out.

The jam is to free each other from whatever is stopping you. It’s an… unjam session.

(I’ll just see myself out.)

Here is what one of our jam sessions look like:

  1. One of us sends out a jam subpoena. This is in text form, or just a straight up Google calendar invite. We try to use a pun in the name of the invite. Jamboree. Jambalaya. Log Jammin’. You get it.The time is always the same: 8pm, when Mike’s kids get to bed.
  2. One of us heads to the other’s house. We both bring a computer. We bring up the file called ‘NextJam’, and enter multi-editing mode so we can see each other’s edits. Both people can type, but you try to take turns so someone isn’t just typing the whole time while the other person yammers.
  3. You follow the items as dictated by the NextJam. The NextJam is the listing of the stuff you added to the NextJam since the last jam session. It starts with a section called ‘Discussion Items’, which is just a bunch of random shit that’s on your mind. New video games. Something you saw on reddit. Sometimes it is book related. Most times not. Allow yourself some time to have an adult conversation about adult things. Some people have been talking with four-year-olds all day and just need to interact with someone who isn’t hustling them for snacks.
  4. Once the discussion items are complete, you will completely ignore the items under ‘Bookkeeping’. These are things like the links to the last jam session, or reviewing the work list, or the TODO list, or the Document Status review list. Nobody has time for that. Skip past where Josh wants to talk about renaming the Empire. Skip past where Josh wants to talk about book titles. Scroll, scroll, scroll…
  5. Get down to what you really want to talk about. Book stuff. The things you’ve been working on. The pending questions. The things you wanted to run by the other person. The stuff that came up while you were working on things.Or, even better, try to remember why you put something on the list. That’s always fun. At the same time, try to remember all the things that came to mind while you were trying to fall asleep, or in the shower that morning.
  6. Talk for 2.5 hours. Write down any decisions you make, and any notes for future modifications. Save the file, giving it a timestamp. Keep the pending items in the NextJam for the next jam session. Go home.

Repeat the above steps until you have a novel. For Mike and I, we have held one hundred and eleven jam sessions according to our records. Possibly more impromptu or unrecorded ones that didn’t make it onto the system.

Some jams are more productive than others. Some get off on a topic that you didn’t even have on the list, but needed to hashed out anyways. Sometimes nothing gets hashed out, and you just sit and gossip for hours. But most times it can be effective in breaking you from your collective procrastination. Regardless of productivity, you should always walk away from a jam session with work to do. Don’t go home until you have work to do.

For instance: You aren’t sure about a character’s decision? Ask the other person. Not sure how to implement an aspect of world building? Ask the other person. Between the two of you there is most definitely an answer, a clever solution, or a way to cheat around it. Something that may be a showstopper for one person may be trivial for the other. One of you is super into maps? Great. Fix the cardinal directions I ham-handedly misplaced in my latest edits. I’d rather be inventing magical cryptosystems anyway.

The final, and maybe most important feature of a jam session is seeking the assurance that you are not crazy. As an author, your job is to make shit up and hope that it sounds like something somebody would want to read. Wherever this stuff comes from is usually a pretty crazy place. And unless you have unwavering confidence in your creative abilities, there will always be the doubt that whatever you came up with is silly and dumb. Or crazy. The jam session is there to run these things by your coauthor. To have a system of checks and balances. Having someone else there to drop a ‘Awww jeaaaah’ or a ‘Awww hell nah’ can get you past whatever snag you are on and solving the problem.

The jam session is pretty central and somewhat holy to our process. It’s something we started early, and while at the time we probably didn’t realize it, it would become pretty important.

So. Yes. The answer, part the first: we jam.