Blogging to Overcome Technical Writer’s Block

Peter Villani
Technical Writing is Easy
4 min readFeb 9, 2019

This is the last in a series of articles in which I express frustration with the art of technical writing. This series came about while undertaking a particularly difficult assignment for my company. Writer’s block can be selective — it was far easier to blog than to do my assignment. But it’s thanks to blogging that I finally faced the beastly assignment.

Our day jobs are punctuated with the purely executory, like filling out papers and filing folders, or performing hundreds of simple hand / eye movements to complete a daily or weekly chore.

Some jobs are only this, and I am thankful that this is not my case, as technical writer. However, as technical writer, I am hounded by the mundane and repetitive task. I avoid thinking about the number of times I’ve renamed files and folders, redirected URLs, cleaned up code, added or deprecated parameters, shortened already short half-sentences, and searched and replaced one boring technical term with another.

Basically, a lot of what a technical writer does is a form of punishment for having created a monstrous tome of esoteric reference material called documentation.

But every job has its pitfalls. So what’s different about technical writing? What’s the darker side?

Before getting dark, let me say something bright. When I am given a blank sheet of paper, and a rich subject on which to write, and carte blanche to do what I do best, which is to “break down complex information into an understandable form”, then there’s no stopping me. Time stands still, deadlines come and go, a writer is writing. Ecstasy comes to mind.

Unfortunately, I am not often given carte blanch. My carte turns rouge — red like blood. Deadlines do not come and go, they stay.

So let’s not delay — What’s the real evil in being a technical writer?

Consider a large writing task, one that will be scrutinized and reviewed by people who do not share your vision of technical documentation. Or maybe you do not share their focus on helping developers do their job. You’re more interested in engaging the reader, expanding her universe.

The people who review my work are highly competent and driven people. They are - to a fault - highly technical insiders who know more about the subject than their readers do, and who think they know more about technical writing than me. But maybe I confuse writing with technical writing, and I resist what they are saying and they resist what I am saying, and so we are blocked, or more to the point, I am blocked, writery blocked.

Ok, so in plain language, what am I complaining about? The difficulty I have with technical writing is that I can’t do it in the proper way. We have a review process. We have several layers of review. Nobody in the review process is a writer. Everybody is technical. The point of the review is to ensure that what I write is useful to technical people. But who is my audience? I think the insiders forget that we write for outsiders, people with different purposes, technical abilities, points of view, and learning styles. I have to write texts that work for everybody.

But it’s an uphill battle to prove that bullet points are not always preferable, or that immediate access to raw facts and code is not always meaningful for people who need more context. It’s an uphill battle that tires me, my legs give out at the start of each ascent, with each new assignment. I find myself hesitating, not wanting to face the next challenge. I get stuck. I don’t move. The uphill does not change. A large block, like a monolith, crushes, blocks my path. Technical writer’s block.

But all writing is a dark undertaking. There is always scrutiny. There is always another way to write that differs from an editor’s preferences.

What makes technical writing a particularly dark challenge, though, is that the scrutiny is not about voice or story, or the beautiful ambiguity of words, but on the accuracy of the facts and the conciseness of their expression. These days we speak about voice and tone in technical documentation, which is a relief and a really good move forward, but these terms are often overly formalized or formulaic, acceptable if upbeat and friendly, carefully idiomatic and fun, but never ironic or provocative or reflective or lengthy, lengthy, and (did I say?) lengthy without much of a point …

Well, now I need to get back to work.

--

--

Peter Villani
Technical Writing is Easy

Started writing this blog to reflect on my writing craft. I have another blog where I publish fiction and creative non-fiction. www.codeharmonics.com.