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 09:42:35 -0700
I agree and disagree. If you want to be able to cope with all the stuff that
can happen as you document that spreadsheet application, you do need to know
your hardware and what can go wrong.
What happens if your power supply goes the day before you need to ship this
manual? IT can't get you another computer because there are none. You can't
borrow one, because everyone else is working frantically. IT has an extra
power supply but, because of other workload issues, cannot get to replacing
yours for 3 days. "But my manual is on this machine!" you cry. "We are
shipping tomorrow!" (I have seen this exact situation)
Knowing how to replace a power supply, much less diagnosing that is the
problem, becomes VERY handy at that point. You can offer to do it yourself
and can get your manual out the door on time.
Our jobs are not just writing about the products. Understanding our tools is
also a big part of our jobs.
Would you hire a carpenter who did not understand his tools? That is called
an apprentice. Can you build a cabinet without understanding your tools?
Probably. I have and it took me forever to do it. But my master carpenter
husband considers me an apprentice and I am. I generally understand what we
need to do and can get there eventually, unless something odd happens. Then
I am dead in the water and cannot recover.
-----Original Message-----
On Behalf Of Jan Henning
> 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.
I didn't say that you "don't need to understand PC issues". I said that
you do not need to know how to do hardware maintenance on your PC -
exchange the power supply or finding out which of several SIMMs is
defective.
And while this may be useful knowledge for a writer - because you are
less dependent on the IT people or because you find it easier to gain
respect from them - it is not necessary to write good documentation
about a spreadsheet application.
---
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.