“What no wife of a writer can ever understand is that a writer is working when he’s staring out of the window.”
— Burton Rascoe
“Waiting for the break of day; searching for something to say; flashing lights against the sky; giving up, I close my eyes…”
— Chicago, “25 or 6 to 4”
Those of you who write creatively — whether it’s a book, an article, music, etc. — have all experienced writer’s block. Even if you don’t write, maybe you’ve experienced it in some form. Maybe you were assigned a writing project in school. Maybe you’re trying to come up with ideas for a party or how to celebrate a co-worker’s special occasion. It even comes up when my wife and I discuss what to do about dinner (“What do you want?” “I don’t know! What do you want?”). No matter what form it takes, the moment when your brain fails to come up with any ideas (sometimes called a “brain cramp”) happens to all of us at some time or another and more often than we’ll admit. As much as I’d like to post a ‘blog article each day, there’s a reason why I don’t. A lot of it is because I don’t necessarily write articles professionally and I don’t always have the time to do it, but an equal part of the reason is not being able to think of things to write about.
For this article, I’d like to talk about technical writer’s block — yes, there is such a thing, and it happens more often than you think. (I don’t know if that’s a widespread term; for all I know, I might have just coined a new phrase.) However, it differs from other forms of writer’s block in that a technical writer already has a subject about which he or she is writing. In this case, it’s not a matter of what you’re writing about; it’s more a question of how to write about it. I can’t tell you how many times I’ve stared at a computer screen for (at least) twenty minutes, only to realize that I spent those twenty minutes just blankly staring at the screen.
Those of you who are technical writers, let’s see a show of hands: how many of you have been given, say, a step-by-step instruction to write about, but have agonized about how to put it together? Should you list them as numbered instructions? Should you keep it to simple bullet points? Is it better to put items into a table and write out definitions for the terms? People who know nothing about technical writing don’t understand the struggle; they think it’s just a matter of throwing it together and making numbered points from them. What they don’t realize is that it is not that simple.
For one thing, writing instructions isn’t that much different than writing code. Both involve logic. But let’s say you have an instruction to “push the red button” but only if you performed another step or are faced with a specific circumstance. In structured programming, this would probably take the form of an IF-THEN or CASE statement. But when you’re writing a document, situational instructions aren’t as clear cut. There is no standardized method for writing an if-then statement in a step-by-step document. I’ve seen this situation addressed in different ways; in one job where I was employed as a full-time technical writer, the group include a style with their template that included a small table for these situations: do this for one situation, do that for another. I’ve seen others where a step is accompanied by a note: “this only applies to (whatever).” Since there is no standard way to address this, it likely makes writing instructions more, not less, difficult than writing code.
Your audience likely plays a role. I’ve espoused time and again that you need to know the audience for which you’re writing. In my first successful technical writing project, I made sure that I put myself in the reader’s shoes, empathizing with the reader. “How do I write this so I can see what I need to do?” That strategy made things very clear, and I was able to write a good document. Unfortunately, tech writers don’t always have this luxury; sometimes, either the type of audience is unclear, or the writer is writing for multiple audiences. If you know your audience, it gives you an idea as to how to structure and write your document.
As I wrote earlier, design matters. Of all my experiences with technical writer’s block, this is probably the one with which I struggle the most. How should things be laid out that would most help the reader? Where should things be placed so that they best direct an end user? A document’s design often makes or breaks a successful document.
I just wrote about some of the issues I face. How to resolve them is not as clear cut, and I don’t have as many answers as to how to address them (that might be worth its own article). Here are a few ways that I’ve dealt with technical writer’s block.
- Ask questions. Clarification helps answer some of the issues with which I have to deal.
- Get help. Another set of eyes can sometimes break the impasse.
- Work on something else. Working on another task can sometimes spur ideas.
- Walk away. Sometimes, you just need to take a break.
I’m sure there are others ways as well that haven’t occurred to me. How do you deal with technical writer’s block? Feel free to respond in the comments.