So, elaborating on yesterday, I’m going to talk about your zero draft.
If you’re writing for someone else, you may think that once you get out the length and message you need, you’re good–you should just hit send. Maybe a spellcheck is in order, but after that? Go.
You shouldn’t. You have not produced a first draft, but a zero draft.
Zero draft is what I call it when the necessary words are on the page, but they have not been through an author-driven revision and editing pass. I try not to submit my work until I have gone over everything for corrections and improvements. You should do likewise.
While I am generally tweaking, correcting and so on throughout the initial writing phase, the end result is still zero draft. It’s only a first draft after another go around. I used to use GDocs, then transfer everything to Word with its more robust tools for revision. GDocs is simple and backs itself up. I increasingly find I’m okay just in Word, but it’s also because as a developer, I am often working with submitted Word docs and .rtf files. But exporting from a writing application to a different finishing application can sometimes help get your mind working in editing mode instead of writing mode.
I find it best to do this on a different day than the initial writing, so I have a fresh mind, but this isn’t always possible. You will eventually learn to see your own common mistakes, but perversely, the ones you miss will be as consistent as the ones to catch. Error is a style. Besides your mistakes, you’re going to be looking for ways to make sentences tighter, eliminate unintentional echoes in words and phrasing, get your headers in a good hierarchy, and just do better.
The pickier you are about your work, the more you understand it. The more you understand your own work, the better you revise it. Developers and editors really, really like refined first drafts. If I get clean, timely drafts from a writer, I am willing to do them a whole bunch of favours because I know I will have less work to do on their material.
The last thing you should do is finalize your formatting. This means following the specifications you’ve been given for the project. It always looks really bad when you don’t follow formatting instructions, but many developers, including me, won’t make a big deal of it unless we have to spend more than five minutes fixing it.
One thing that happens sometimes–not a good thing, all around–is that writers may hand in drafts that are rough, late, or both, and these problems are serious enough that the developer can’t make time to write a redline (calls for revisions and notes for improvement) for it. This is an awful situation. You don’t get any feedback, and you may not get hired again. I have seen multiple instances of this. It’s bad for writers, who don’t get to learn and grow, and bad for developers, who need to do the rewrites and, I believe, have a basic duty to help writers improve.
I make mistakes like everybody else, and don’t claim to be the greatest game writer in the world, but by using the zero to first process I tend to get pretty mild redlines with minimal curveballs chucked at me during the tight time between first and second draft submissions. Ultimately I owe this practice to Jesse Heinig, who shot back the first thing I ever sent him because it was a shambles.