Day Jobs
Many of you have written about your day jobs in your Medium posts, and to be honest, it’s kind of fun knowing what you do outside of obsessively checking your Medium stats. Whether you’re an IT professional, a freelancer, or championship oyster shucker — whatever it is, it probably affects your writing.
Try to guess what I do for a living. Go on, give it your best shot. What’s that? You had me pegged as a Carny? Nice try, but I just speak fluent carny talk, I don’t actually make a living that way. Although I do know how to make a kick-ass funnel cake.
I’m a Technical Writer, which obviously leads you to such thoughts as, “A Technical Writer? She’s probably well versed in several fascinating topics such as DITA and XML editors and the Inverted Pyramid.” You’re right! And I love talking about these topics, especially with unsuspecting people who introduce themselves to me at parties.
I’m a triple threat, too, because once I run out of technical writing topics, I will smoothly transition into Lord of the Rings trivia and then ask you if you’ve had any interesting dreams lately, which I’ll interpret in my head, learning more about you than you probably wanted me to know. Socially adept and fun!
Here are some other beneficial side effects of being a Technical Writer (other than making me a super awesome conversationalist).
Note: Before you all send me private notes asking how you too can get in on this tech writing action, please understand, it’s not for everyone. But if you love to nerd out meticulously documenting peripheral details, minutiae, and hair splitting, by all means, drop me a line!
Writing Discipline
Tech writing has made me extremely disciplined as a creative writer. When I start a technical document, I finish it. There’s no option to start working on some other project because the Wiring Diagram muse just isn’t singing to me. I suck it up, I write it, and I finish it.
Not only must I finish the document, but it has to be written in simple, unambiguous, ordered, and most of all, accurate language. My end users won’t forgive me for technical mistakes because that warning about “spinning fan blades causing bodily harm” was so darn funny. There’s no room for error or winging it — my words are logically ordered facts which convey precise information meant to instruct and inform a specific audience. Yes, you just heard my stern technical writing voice right there, and she does not mess around.
During the workweek the bulk of my writing is technical. I grapple with conveying information clearly through the written word, working around my end users’ constraints, and finding creative solutions despite the limitations of technology. As a creative writer I have the discipline to write even when I don’t feel like it or when I’m blocked. I view my creative work in the same vein as a technical document, just another problem to solve.
I’ve had to rewrite hundreds of pages of technical documentation due to changing requirements. If I write a chapter in a novel that gets tossed on the scrap heap, that’s fine. It’s the exercise of writing that’s helped me improve.
Document reviews and rewrites are now less painful than root canals
My technical writing goes through multiple reviews and rewrites before approval, which has taught me to take my ego out of my writing. I can’t walk around butt-chapped all day because my work wasn’t clear enough for an engineer to understand.
All redlines that come back are addressed. “Dismantling the engine sounds more mellifluous written my way” has no weight. Neither can I fall back on an artist’s moody temperament, although there have been meetings where I’ve wanted to run out crying, “Leave me alone! No one understands me!” then run to my cube and slam my imaginary door like Les Nessman.
Nothing is bullet-proof when it goes to the editing phase. I once wrote a User’s Manual where I made the following controversial word choices. “Click the light blue icon.” I thought it was a real gem until I got this suggestion back in my redlines:
“Whoa there Shakespeare! Light blue is not on the approved list of words. To avoid misinterpretation, general mass confusion, and the resultant panic, please use #BFEFFF. Use neutral terms or better yet, no words at all.”
I can see now I was getting carried away, using flashy descriptive words like blue, but still, I kind of need real words here and there.
Realistically, there’s a good chance if the engineer doesn’t understand it, then my end user won’t either and ultimately my product is for the end user, not for me or my ego. Same goes for my my beta-readers. I just accept that some of my favorite lines are crap, then make the changes and move on.
My audience isn’t everyone who knows how to read English
No one other than a small group of people will ever read my technical writing. My audience is specific to people who perform certain jobs on certain equipment and my writing is tailored to them. I know what their skill levels are, how they interact with the equipment, the dangers of working with the equipment — in other words I have to know a lot about a small audience.
Obviously, the same is true for a creative writing audience. I used to try to write pieces everyone would like because I thought it would attract a larger readership. It didn’t. When I read someone else’s writing and I feel like I could talk with them in a coffee shop for hours, I’m the reader they’re writing for. I appreciate it, and I will read everything they write.
I’ve noticed many writers (not you though) seem to have a deep-seated need for people to like them, and they think they can get that approval through their writing. After years of watching my technical writing crunch through the grist mill of review boards, I know one has nothing to do with the other.
Side Note: The only time I really intended to get someone to like me through my writing was in fourth grade when I wrote a note to Barry M. “I like you, do you like me? I have cookies to share.” And he did! He cut all the hearts out of his deck of cards and put them on my desk. Looking back, that seems a bit creepy.
My story has to make sense
Just like technical writing, a story has to be in some kind of structured form for you to glean any sense out of it. It doesn’t have to be sequential, but ultimately the reader has to follow the progression. Hopefully the story is taking us somewhere, right?
Technical writing has to be ordered in the most standardized, straightforward, dull, and lifeless manner possible. No one is going to read this stuff for entertainment unless it’s so awful it’s entertaining. For example, the instructions I attempted to use last weekend.
The text had obviously been translated from Dutch to Sindarian back to Dutch, then Google translated to something masquerading as English. One of the steps was to “enable the provided gyroscope for the ultimate perpendicular results.” It’s a cat fountain, and I can tell you honestly, that as of right now, I never located a gyroscope and I am not achieving the ultimate perpendicular results. (For those of you who read about Sweetie, after 10 years of missing her, we just adopted two cats).
J can tell you this is my most pernicious writing issue. My thoughts are very freeform, a jacked-up, jumbled mess some might say. I write out my thoughts as they occur to me, then I add the structure later, unless I leave out the structure part altogether because, hey, it makes sense to me.
When J reads my raw writing he says, “It’s like hearing a conversation between best friends, but as the confused and annoyed outsider listening in.”
“Remember the trip…”
“…that song at the place that time?”
“Hummus and vodka!”
“One headlight…”
“…microfiber…”
“Oh, yuuuuck….”
“…greasy tentacles…”
“Hahahahaha!”
It’s like that. I’m working on it.
If you like what you’ve read, please recommend so others can see it.
Last week on Drafty — Characters First
Next week — Why you should always write in a lawyer into your fiction
