How these made it into print, I’ll never know

30 Jan

Posted by Scott as technical communication, writing

While going through my files the other day, I found a set of examples of bad technical writing that I collected over the years. These examples were from various places at which I’ve worked, on from documentation on which I worked. None of them were written by me. Really!

What surprised me is that:

The writing was done by professional technical communicators.
It actually made it into print and into the hands of customers.

The morals of the story? Sometimes a good editor, or even just a solid peer review, can help avoid bad writing like this. And that some people just aren’t very good at their job.

So, for your perusal:

Bad Writing = Bad Thinking

Its objective is to provide individuals unfamiliar with <product name> ability to use basic <product name> functions.

When you have completed this section; the following tasks will successfully have been accomplished:

add and modify default cross reference codes
add and modify user defined cross reference codes
the meaning of the cross reference code effective date
how to cross reference transaction components

The DFV modifier in <product name> causes the generation of a CONTRA-FRA.

Each is allows only specific securities to be applied to them:

… using <mode name> mode for the display of portfolios is acceptable.

Client machines are for the users of the system to use.

How Many Times Can You Use “Field” In A Sentence?

Select the Portf_code field from the list of fields in the FIELDS field. The field name appears in the FIELD<EXPR> field.
Select NOT from the drop down menu in the LOGICAL field. NOT appears in the FIELD <EXPR> field.
Select the hold_mat.base_curr field from the list of fields in the FIELDS field. The field name appears in the FIELD <EXPR> field.
Select “=” from the drop down menu in the LOGICAL field. The “=” appears in the FIELD <EXPR>
field.
Enter ‘CAD’ after the “=” in the FIELD <EXPR> field.

Jargon, Jargon Everywhere

… facilitates the requirement that …

… for the purpose of illustrating …

The treatment of foreign exchange transactions can be classified into two types within <company name> systems: Spot and Forward Transactions.

Importation of designs from <product name> …

Huh?!?

An introductory statement regarding that leads into the subsequent sections would be useful.

Any questions as to the details involved in each step may be found in the appropriate section of this guide.

Once <product name> is installed user’s mau use <product name> without taking advantage of <product name>’s features. Although, this is not recommended.