TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:RE: What does it mean to be technical? From:"Sharon Burton-Hardin" <sharon -at- anthrobytes -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 23 May 2003 08:52:12 -0700
While I agree that you don't need to know code to document a spreadsheet
program, I totally disagree that you don't need to understand PC issues.
Folks, regardless of the area of tech writing you work in, you do work with
your computer every day for hours at a time. Writers who do not understand
how their box works and how the software works with the stuff in the box are
at a strong disadvantage.
Why? Because when printing your manual does not work, you are dead in the
water. You have to ask for help, often of your co-workers or help desk. "It
worked yesterday," you say, "I don't know what is going wrong."
The perception from the people you work with (read: the IT group and/or the
programmers) is that you don't know how your tools work. And for those who
_are_ technical, now understanding how your tools work is considered a sin.
That means your IT group and your programmers think you are not technical.
This is one of my biggest complaints about tech writers. Not knowing your
tools is a great way to embarrass yourself in front of the techies in the
office. These same writers complain they are not taken seriously by the
techies in the office. No kidding. Want respect? Learn your tools.
Understand how your computer works, down to the board level. Understand how
software works with the stuff in the box. Take a class, or several, if you
have to to learn this. This is not time wasted and will gain you great
respect.
Maybe I need more coffee. I am certain to be assaulted on this topic. I
usually am.
Example: When a spreadsheet is documented, the writer needs to know
about formulas, user interfaces, printing issues, scripting and the
like; but does not need to know C programming or PC hadrware
maintenance issues.
In addition the writer needs to be able to communicate with the SMEs
well enough to understand what they are saying and to ask them relevant
questions.
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.