What does it take to be a technical writer? This topic has been brought to mind once again by a mentoring request from a colleague. This person is very interested in making the switch to technical communication.

Technical communicators (also called technical writers, documenation specialists, publications specialists, and sometimes with specialized experience, information developers and  information architects) come to the field from many different backgrounds, educational and otherwise.  I know people in technical communication who were English majors, sure, and others who were fortunate enough to have access to get a degree in Technical Communication.  Others come from backgrounds more varied and esoteric (MIT, anyone?).

 I’m an Art major who minored in English due to a strong interest in writing since I was very small.  I”ve written short stories, poetry, newsletter articles, and had a non-fiction article  published in a magazine.  I came into the field because I was in the right (write) place at the right time, and I had a lot of  writing experience in my career as a public relations specialist. And, I was already familar with writing instructions, as well as writing news releases (just the facts, ma’am), training materials, newsletters, and so on.

So, educational background can be varied, as well as discipline. Some tech writers I have worked with started out as nurses, engineers of various stripes, analysts, secretaries and administrative assistants (who do lots of writing, by the way), scientists, computer techs, marketing folks, fiction writers, and more.

Experience is needed to move into technical writing, and you might say, “How do I get experience when I don’t have any? And no one will hire me without it?” You may be surprised to find that you have some valid experience already.  Have you ever written a policy and procedure document? How about instructions for accessing a system at work, or using the office copier? Did you contribute to a request for proposal (RFP), or answer one? That, my friend, is technical writing experience. 

If you really don’t have experience, but you want to get some, you can volunteer to document open source software (see sourceforge.org) or help out as an editor.  You can learn a lot and garner some great documentation samples to put in a portfolio.  

Other suggestions: Take a class; join your local Society for Technical Communication Chapter, and trawl Download.com or Softpedia.com for software that needs some documentation.  

Good luck and welcome to the profession.  If I can help you, let me know.

Diana

UPDATED! Poll Results Added.

I am working in a different medium nowadays, using DITA. The company I work for has some standards that are a little different than I have seen in quite a few years of working in this field. The formatting and layouts I am working with are more common in Framemaker shops than in most online-help-development-oriented departments.

Specifically, the standards call for using a different font (like Courier), bold or italic text, or a special indentation for text that describes a user action or choice, a window name, a GUI element, and so on.

This scheme produces text with many formatted “cues” in the text. I’m curious about the value of adding all the font changes in user instructions: Is is valuable, or is it a distraction to users?

What do you think? Access the poll and provide your answers. I promise to post the results.

RESULTS! Keep in mind, this was a very small sample (less than 25 people), but the results are interesting, and lean in the direction of using font cues in documentation text.

Answer
36% – I think this is very effective and use this in my documentation.
21% – This is somewhat effective, but time-consuming. I use it.
14% – Detracts from the documentation and makes it harder to use, not easier. I don’t use it.
14% – I have NO idea! What does everyone else think?
7% – I am unsure of the value, and I don’t use it.
7% – I am unsure of the value, but my organization requires it, so I use it.
0% – Absolutely valueless to my users, and they dislike it. I don’t use it.
0% – Other answer…

Thanks to everyone who took the time to answer this poll!

Recently, we purchased a new coffee maker for home to replace the five-year old brewer that had given up the ghost. The new coffee maker lasted exactly three days before the basket broke along the top rim, which made it fit poorly, and the latch broke that secured the swing-out brewer basket in place. The only way to make coffee was to use a piece of duct tape to hold the basket in place so the water went into the coffee grounds. And we NEED coffee at our house, so this was not…convenient.

This brought to mind deficiences in product quality in the news recently that ranged from annoying (errors in cookbook recipes) to life-threatening (lead in toys).  It made me think about quality and my responsiblity to base my work on quality principles. Quality can be described as a value, like ethics, even though that is not the strict definition of the word. How can I, as a technical communicator, uphold quality as a value in my work and the products that I document?

If quality is one of my values, I will:

• Do my best to ensure that what I write is true.
• Ensure the product is represented accurately.
• Understand, thoroughly, what I am writing about.
• Validate, to the best of my ability, that the the documentation portrays how the product actually works.