Learn more about me and my books at

Friday, April 20, 2012

A Sad State of the Art

As mentioned, I’ve been looking for work. Scoping the ads, I find that an old prejudice that has been around for a long time refuses to die. It involves companies looking for technical writers.
Think about it, folks. When you were in college, did you ever meet an engineering student who just devoured the English language? Of course not. If they had been interested in writing, they would have been pursuing other majors. They took only the writing courses they were forced to, and many of them still struggled with writing coherent papers. Why then do companies continually look for technical writers who have several years of engineering experience?
The idea with technical writing is usually to take the jumble of engineerese that initially “documents” a piece of equipment or a software package and translate it so that the people who will be using the product can figure out how it works. So how is an engineer who speaks almost exclusively in technical lingo supposed to do that? Ninety-nine times out of 100, they can’t. And therein lies the problem.
Suppose we’re talking about the medical field. You go to the doctor—one who can’t translate medicalese into English—and he/she tells you that you have pyrexia indicative of acute rhinitis. You might suffer a myocardial infarction on hearing that! However, if someone can explain the terminology to you, you’ll learn that you have a fever, which is a symptom of your cold. You can therefore avoid the heart attack.
Or suppose you buy a video game, Japanese edition, and you don’t read Japanese. You’re on your own figuring out how it works. Unless you are willing to spend a lot of time at trial and error, you may never understand all the nuances of the game.
The same kind of thing is true for the products turned out by engineering firms. THEY understand what they have created and how it works. Unfortunately, when they try to explain it to the rest of us, they often want to include a lot of the details that are irrelevant to the end user. When we turn on our computers, we just want them to work and we want to know how to get them to do what we need done. We don’t need the code and the backstory—we don’t speak that language.
Sometimes engineers document in the opposite direction—oversimplifying, assuming that we know much more than we do. Enter the writer, who can see the product in the way that most users will see it and ask the questions they would ask to make the product work. Most of the population needs instructions written in plain, ordinary English that tell us enough, but not too much.
Example: A software user manual may tell you that to insert a picture into a document, you choose the picture from your library on the Insert menu. For most of us, that’s backward. Better instructions would be: On top of the document page, click the Insert tab. Then, in the Illustrations section, click Picture. This will bring up your picture libraries. Open the folder that contains the image you want; double click on that. The picture will appear in your document, stretching to the margins of the page. You can resize it by clicking on the image. Go to one of the corners and move the cursor until you get a double-headed, diagonal arrow. Hold the left mouse button down and drag the corner of the image until you have the size you want, then release the button. If you want to center the image, highlight (click on) the image. Click the Home tab at the top of the page, then in the Paragraph section, click on the icon for centered text. (Which is how I inserted this guy.)