The Daily Word Count Conundrum
Authors are repeatedly told that success means writing each and every day. Some have gone so far as to say 3,000 words is the absolute minimum, otherwise kiss your career goodbye. (For the record, my average doesn’t come close to that mark.)
NaNoWriMo awards anyone who can scribble out 50,000 words in a single month with a grand, shiny, virtual ribbon, and provides a platform where others can cheer the aspiring word generator toward the finish line. The experience is similar to running a marathon; participants tell anyone and everyone who will listen that they are participating and, much like a televised event, post frequent updates so fans can track their progress almost in real-time.
Most writing groups asks members weekly for word counts. Those who actually have something to report do so proudly. Those who don’t hang their heads in shame, silently or with apologetic excuses about how life got in their way or, heaven forbid, they had to stop cranking out content to get some editing done.
In essence, daily word count has become the measure of an author’s worth.
Unfortunately, this measurement smacks of an old misconception in the programming world, where developer productivity was measured by the daily number of lines of code they committed. Now, the concepts aren’t exactly parallel: efficient coding can do the same job in 100 lines as 1,000 lines of inefficient code (there may also be readability and maintainability issues with the shorter version, but that strays beyond the point of this article =] ), whereas book genres demand certain bands of word counts. That said, you can imagine how developers compensated for this measurement. Efficient coding went out the window in favor of voluminous programming styles. Developers became afraid to sit back and think about what sort of disastrous design implications their code had on the application at large because their performance reviews depended upon writing, not thinking.
The problem, as you can imagine, is that any complex piece of work, such as novels or large applications, requires thoughtful planning and care or it will most likely fall short of quality expectations. In applications, this means unmaintainable spaghetti code fraught with performance issues and cross dependencies that make troubleshooting and modifications a living nightmare. In novels, this means plots that go nowhere or make little sense, characters who have no purpose or are as flat as cardboard, and exposition that rambles into the sunset like a wayward cowboy with no particular destination in mind.
Now, even with meticulous planning, the above issues can easily crop up in a novel. Stories take a life of their own, after all, but as most authors would argue, this is why we have multiple drafts and alpha / beta readers (and editors, if you can afford them). The first draft is telling yourself a story; the second draft is telling that story to someone else—i.e. where all the problems are miraculously (read: painstakingly) fixed.
And yet, even during a first draft, when the characters have stubbornly refused to conform to my outline, events have not played out as scripted, and that spectacular ending I had in mind now fits about as well as my high school jeans, I sometimes stare at a half-finished chapter and wonder where on earth it’s going, let alone the rest of the book?
This, I’ve learned the hard way through 10+ novels, is a big flashing neon-sign warning that it’s time to pull my head out of the story, take a good look around, and seriously consider if the rest of the outline still applies, or if I need to crumple it up and re-outline based on where the novel has actually gone, which at that point is usually a place I couldn’t have dreamed of when the story began.
Let’s also be clear: this is not an easy process. I have to unwind all the expectations I’ve been running with, assess the current situation—including all the interpersonal nuances I never expected to develop—draft several rounds of notes outlining possible directions, discard the ones that simply don’t make sense, then solidify it into a plan I can continue with. This plan may involve re-writing key chapters or entire characters, whose motivations may have dramatically changed, and ensuring every chapter those characters touch, along with every interaction, reflects their new reality.
Undergoing said adjustments is a daunting commitment that I have accepted as normal for almost every novel I write—and, in that same breath, would prefer to do as few times as possible. To me, that means taking the time to really think it through. And the more time I take (usually 2-4 days), the more solidified the ideas become, the easier it is to continue because I’m excited instead of stuck, and the final work is much more compelling to readers. Conversely, the longer I try to push forward through the mess, the less I like my own work, and the more cleanup I end up having to do later.
But… what about my daily word counts? I’m not writing anything! Sometimes I’m just staring at the wall, letting my mind wander with possibilities. Doesn’t that make me a bad author?
I sure hope not. In software, iterative development is a common, encouraged practice. This means writing code in short, intense sprints, but then making sure to pause periodically, check with stakeholders and each other, and make sure that what you’re developing is actually what the customer needs. If not, you might scrap your entire backlog and create a new one that aims in a different direction and requires adjustments to existing code, but you’re doing it sooner than later, thereby saving a lot of time and hassle, both for the team and for the people receiving the software.
So the next time you’re struggling to write, and you feel that ever-present pressure to churn out words or be seen as a failure, remind yourself that creating space to think is a natural, necessary, and healthy part of the craft, then hold your head up high and tell everyone that no, you haven’t written a single word, not because you’re a lousy author, but because you’re trying to be a great one.