Technical writing and technical editing

Damon Garn spent about 20 years in the classroom, delivering technical training on Windows Server, Linux, security and CompTIA products. He also spent time as a network administrator for U.S. Figure Skating. In recent years, he left the training industry and now provides freelance writing and editing services for companies. I asked Damon about his role as a technical writer and editor.

Let's start with an introduction: Who are you and what do you do?

I'm Damon Garn, owner of Cogspinner Coaction, LLC. My organization provides technical writing and editing in the Information Technology field. I spent over twenty years as a technical trainer, delivering courses on Windows and Linux servers, security, and configuration management. I also spent time in the IT workforce as a network administrator.

I decided to translate my technical knowledge and writing skills into a thriving business that develops learning materials to educate future IT practitioners.

Is it just technical writing, or do you work on other projects for clients?

My primary technical writing opportunities are instructional guides for computer-industry certifications. I've written five Official Courseware guides for CompTIA, with a sixth planned for later in 2024. My role is not just authoring but also course design, translating exam objectives into a functional and logical outline, and advising on hands-on opportunities related to the content.

My business also offers tutorial-style articles covering server configuration on Linux and Windows, logging, security, and more. I also write many conceptual articles that explain the whys rather than the hows. I really enjoy this aspect of writing. I'm able to suggest new areas and hone new skills.

What does it take to be a good technical writer? Do technical writers have to be very "technical"?

I don't believe technical writers have to be experts in the topic. They certainly need some context within the field. For example, a beginner programmer could write a "how to learn programming" article, but they must still anticipate the challenges new developers face and possess some basic vocabulary terms. That said, research is a big part of writing prior to the authoring stage. Another crucial skill is project management.

However, I have two other observations about good technical writers.

The first is an ability to translate complex and role-specific terms and concepts into everyday language the reader can easily absorb. The writer is a guide and advocate for the reader, not the content. I honed this skill as a technical trainer and translated it into written communication.

Second, the writer must know when a visual aid is a better delivery tool than the written word. Screenshots, recorded demonstrations (I use many animated GIFs), and diagrams are all critical to IT professionals. I believe that many successful IT people are visual and such images help them grasp concepts. Technical writers can cater to this audience.

Are there any downsides to your technical writing career?

I've dabbled in writing fiction for most of my life. I even have two novel drafts around the 80,000-word mark (one is high fantasy, and the other is steampunk). However, once my daily job involved technical writing, I could no longer find the creative energy to sit in front of the computer and invent fictional worlds.

I really hope that changes someday! I hate that I've had to sacrifice creative writing for technical authoring.

You're also a technical editor. What does an editor do?

If you Google for types of editors, you'll find nice, neat matrices and job descriptions. Organizations don't necessarily structure their teams so rigidly in the real world. This becomes especially true when the company consolidates the content team, as is happening often right now.

My primary editor role ended up being very restricted. I served as a freelance technical editor for an organization for nearly four years. I was brought on for my technical knowledge and experience with Linux and given significant leeway to organize and structure article content. By the time that contract ended at the start of 2024, I was a glorified spell-checker. Other editors had taken on the technical role and were uninterested in input.

In the early years of that project, I enjoyed the ability to work on behalf of the reader to help the author develop a piece that communicated their knowledge in a way a less familiar reader could follow. I think the editor's job is to hone the edge the author has created.

What does a typical day or week look like for you as an editor?

I'm a believer in productive time. In college, I was most creative and productive at night. I often wrote papers and conducted research in the 6:00 pm to 2:00 am timeframe. Today, that productive time is reversed, and I am most efficient and energetic from about 5:00 am until 1:00 pm. I tend to do my editing as soon as I get up (I'm between editing gigs at the moment). I would rise, pour a cup of coffee, and open the articles I needed to work on. That process got me warmed up for my own writing assignments, which I would do from mid-morning until the end of my workday.

What skills does it take to be a good technical editor?

I believe a good technical editor (as opposed to a good copy editor) needs to see the big picture. What's the author's overall goal? Is the article structured in a way that communicates that goal effectively? The other role of a technical editor is the ability to comprehend the technical aspects of the project. For example, I often caught command typos in the articles I reviewed or noticed code snippets containing mistakes.

Copy editor skills are critical and no less important. I see this job as more detail-oriented, focusing on the proper use of commas, eliminating extra spaces between sentences, etc. 

Both jobs are essential and may or may not be completed by the same person.

What tools or technologies do you use as an editor?

I use a variety of tools, as noted in my recent Technically We Write article about my four favorite writing tools. I do a surprising amount of drafting in Vim, a Linux-based text editor. Vim eliminates the distractions more robust programs like Microsoft Word inflict. Obviously, Microsoft Word (and LibreOffice Writer) is essential. I don't tend to like track changes, and often, by the time a piece gets to me for editing, I apply the final changes. I do appreciate comments in Word and Google Docs.

I'm really interested in the use of Git for content authors. It's clearly a critical tool for developers but it has also become a valid utility for content creators. I haven't moved my writing process to Git yet, but I'm strongly considering it. In fact, there is a Git for Writing Documentation article on Technically We Write that's on my to-do list.

Here's a fun question: Do you have any editing pet peeve?

My editing pet peeves are pretty simple. I'll mention two.

1. Authors who cannot properly spell their own project. I saw this all the time with Red Hat OpenShift. An author might submit a piece with the sentence, "I work on the Openshift team..." and I'd have to correct the word to OpenShift. C'mon, it's your project!

2. I am also driven to distraction by two spaces after a period before the start of a new sentence. I learned to type on a traditional typewriter and was taught then to include two spaces. That convention is long gone.

Thank you to Damon for this very insightful interview about technical writing and technical editing! You can find him on LinkedIn at Damon Garn - Cogspinner Coaction, LLC.