Where Creativity and Technology Meet
When I started my first technical writing job back in 2005, one of the VPs of the company I was working for would stop by my desk on occasion and ask me, “Technically speaking, have you written anything today?”
The truth is, in my 12-year career, I haven’t written as much as I thought I would, at least while on the job. If I can remember that far back, I think I probably just gave him a shy smile. But his question always got me thinking. In fact, I’ve been thinking about it for the last twelve years, as I have moved from job to job, as is the nature of being a government contractor, for one, and second as a worker in that weird gap between Generation X and the Millennials.
What is Technical Writing? It seems like every job posting I’ve ever read for a position in the field is boiler-plate, out-of-the-box, standard language. And believe me, I’ve read A LOT of job postings. Here’s one, however, that I just read recently that stands out to me:
“Opportunity: Do you find yourself wanting to discover the breaking points of software in order to understand the quality? Do you have the art for writing complicated technical documentation in terms a non-technical person could understand? Do you have the desire to make the world a safer place? Then we have just the job for you!” (I’m not making this up!)
Technical Writing is a great profession to be in, and has been, for me, very lucrative. Even during the recession that started in 2008, I had a great job that paid well, and allowed my husband and me to buy a condo outside of Washington, D.C. at the end of 2009. Since then, I’ve worn many different hats, starting with Entry-Level Tech Writer, to Technical Writer/Proposal Writer, Technical Writer and Trainer, to what I do now, which is Business Analysis.
But back to the writing. Technical Writers do a lot of different things, and writing is certainly one of them. I have an undergraduate degree in English with a minor in Creative Writing from Washington College, a small private liberal arts school in Chestertown, Maryland. There, I learned about 20th Century English Novels, Contemporary Native American Literature, and Romantic Poetry, (think Wordsworth, Keats, and Byron), to name a few. But while writing papers on Hamlet and Linguistics, I learned how to think critically, analyze, structure, and articulate my thoughts in my own unique voice. I once was asked in a job interview about how my passion for writing and English degree informed my desire for a position at an IT firm. I was able to answer the question for a few reasons. What are those reasons?
First, Students who are well-read and required to write a lot are better creative and analytic thinkers. They know the language backwards and forwards, have learned grammar, and can even speak more clearly and articulately than their peers. I remember when a fellow student in one of my high school English classes asked our teacher, Mr. Axelrod, “How can I improve my vocabulary score for the SATs?” Mr. Axelrod told us, “First, go back to when you were born, and learn to read, and then read all the books you can possibly get your hands on.” The student’s face fell. So, essentially, the more you read, the better you will write because you will have a better vocabulary and sense of the language. Any writer worth their weight or their book deals will tell you that.
Second, writing well is essential for any position that requires you to communicate ideas: whether it be via email, a Standard Operating Procedure, a Training Plan, or a Security Document – even informational brochures and Quick Reference Guides.
That’s where the technical aspect comes in. As a Technical Writer, you need the ability to translate often complex, technical information into Plain Language, or at least for an audience that may include clients, non-technical colleagues, the public, or government officials. I’ve written for all those audiences during the past decade or so. You also must be able to take diagrams that range from the simple to the complex and write descriptions of the workflows, processes and procedures, concepts, etc., that make sense and follow a logical order. That takes creativity.
One exercise that my Intro to Technical Writing professor Susan Lawrence led our class in was to come up with instructions on how to make a peanut butter and jelly sandwich, as if the person following the instruction had never completed such a task before. It seems like a pretty simple assignment, but it gets to the root of what writing technically for a non-technical audience really means, and provides a visual of what the results could be if the instructional steps were not written precisely and properly, with careful analysis and a touch of creativity.
I first learned about Technical Writing as a career option while at a poetry reading as a freshman at Washington College. Tarin Towers read her Pushcart Prize winning poem, and then told us what she really did. She was a Technical Writer. Having published manuals on what was then Macromedia Dreamweaver and other IT tools and products, she wasn’t exactly making her living as a poet at the time. Her bread and butter was Technical Writing. I had never heard of such a thing. I thought I was going to be a novelist or a creative writing teacher, and as a junior, made plans to go to grad school in Wales at Cardiff University for their program in the Teaching and Practice of Creative Nonfiction. I never imagined that I would end up as a Technical Writer, now Sr. IT Consultant, working as a government contractor in Washington, D.C., a few blocks from the White House at the Department of Commerce.
At the time of that poetry reading (nearly 20 years ago,) I couldn’t even hook up my own computer and set up the printer my parents had bought for me. Albeit, in 1998 we had giant CPUs and huge bulky monitors and lots of cords and wires connecting everything. I didn’t get a laptop until I studied abroad at St. Andrews University in Scotland my second semester of my junior year. Now, I work at a desk with multiple monitors and multiple laptops, wireless mice, and my smartphone with me at all times to take customer calls about the system I am supporting. I conduct virtual training sessions for customers across the country and help them with their IT issues. I would say this was ironic, but as an English major, I actually know the definition of irony.
I was given the opportunity to interview for my first tech writing job because the company I was working for as a Business Administrator (fancy term for “receptionist) knew I had an English degree and could write well. They hired me for that role, and after a few months on the job, I thought I had gotten the hang of it. I took meeting minutes, worked on multiple User Guides, and helped support documentation for a financial management system that local, state, and federal government customers used. I learned how to use Snag-It, TechSmith’s excellent screen capturing tool, and RoboHelp, an online help authoring tool, as well as Visio, which helps you make all kinds of fun diagrams with swim lanes and process flows. These are all valuable tools of the trade and excellent skills that I have used throughout my career.
However, if you spend a lot of time in school learning how to use specific tools, know this: those tools and technologies will change rapidly. I took a class on Flash in grad school at George Mason, and had a great time adding eye-popping images and visuals to the website project I built using Dreamweaver, which I also learned how to use in a class. But it was learning the very basics of HTML that has helped me in many jobs that I have held since taking those courses.
I even have a tee shirt that says, “Take a Screenshot; It will last Longer” that I picked up from the TechSmith vendor booth at the STC Summit in Philadelphia in 2008. I was a grad student at the time at George Mason University in their Professional Writing and Editing master’s program, so I was able to snag the student rate for the Summit. I took a bus from D.C. to Philly and enjoyed the conference immensely, taking both the student or Academic track and the Professional track as well, because I was in both worlds simultaneously.
I decided to go to George Mason because it was conveniently located, affordable, and the PWE program certificate required 21 credits, which seemed manageable with my schedule. I applied and was accepted in 2006. My degree was completely paid for by various companies I worked for during the three years it took me to graduate while working full-time. My advisors and professors were great, so I decided to tackle the full Master’s Degree and all 30 credits. I had already made that decision when the program changed from Professional Writing and Editing to Professional Writing and Rhetoric. The focus seemed to shift more towards the academic side of writing spaces and the analyzing the rhetoric of websites and theoretical frameworks rather than how to write a Standard Operating Procedure.
I took several valuable courses that, as I had hoped, helped me with my career goals and job skills as a tech writer. I took Introduction to Technical Writing, Computer-based Publication, Writing, and Design, and a great course on Editing from an outstanding professor named Roger Lathbury. He taught me about blue pencil editing (which may be old school, but it’s the foundation for being a good editor). I also highly recommend getting yourself a copy of Hodge’s Harbrace Handbook for your grammar needs, if you don’t want to lug around a copy of The Chicago Manual of Style, or you can get your daily dose of style from @ChicagoManual on Twitter.
Speaking of Style Guides, I consider myself to be quite the connoisseur. My first manager gave me a copy of the Microsoft Manual of Technical Style and I’ve been using and applying its guidelines ever since. In fact, when it came time to write my thesis in the final year of my master’s program at GMU, I decided to write on the topic of Technical Style Guides. The title came to me while I was using the copy machine at my job at the Bureau of Labor Statistics, part of the Department of Labor in Washington, D.C. Are you ready for it? Keeping to the Code: A Rhetorical Analysis of the Evolution of Technical Style Guides in the Computer Age. Note that the first Pirates of the Caribbean movies came out in 2003 and was followed by several sequels while I was in graduate school. Hence the “Keeping to the Code” reference.
Here is a link to my thesis. Enjoy!