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:"Lauren Tozer" <TAMETO01 -at- noa -dot- nintendo -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 23 May 2003 09:27:42 -0700
>Victoria wrote:
>"Every good technical writer I've known could look at any code and at the
>least figure out what is happening in it. While a good "technical" person
>may not be able to program in code, they should always be able to look at
>all the parts and figure out how they work together."
The "Every good . . ." part is painting with a rather large brush. While I took many programming classes in college (and discovered I really really hate coding), it's been so long that I am not sure I could look at code these days and figure out what is going on in the code.
However, the documents I write have nothing what-so-ever to do with code, and any knowledge I have of programming is next to useless in my job. I write hardware repair manuals. I could rephrase her last sentence to say something like, "While a good 'technical' person may not be able to solder well, they should always be able to look at the solder fillet and know that it was made at the correct temperature and not bridging lands." (Or some such.)
Rather than couching "What does it mean to be technical" in terms of the software industry, we can broaden this a little and say (again rephrasing Victoria):
Every good technical writer can look at the job/process and at least figure out what is happening in it. While a good 'technical' person may not the complete set of skills to do the job, they should always be able to look at all the parts and figure out how they work together.
This implies that a good 'technical' person has at least some of the skills required to do the work. When I first started in my current department, I had none of the skills that the repair technicians have. It shows in my early work. Looking at those manuals is very embarrassing. While that don't totally suck (decent repair technician could figure out what I was trying to say), they are certainly well bellow my current standards. My current manuals are much better, and my future manuals will be even better. Why? Because I continue to learn more about the processes that I document.
Being "technical" means different things to different writers. I my previous department being "technical" meant knowing how to play games really well (no, really).
To sum up:
Being technical is not about having prescribed knowledge (like being able to read code), but having knowledge applicable to the documents being created.
---
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.
