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: Tech writers and engineers From:Sean Hower <hokumhome -at- freehomepage -dot- com> To:techwr-l -at- lists -dot- raycomm -dot- com Date:Mon, 1 Mar 2004 08:06:04 -0800 (PST)
I think you need to know, or be able to learn, about a subject that you're writing about (both technical and user). Period.
As I've said before, if you're not working in the software industry, you have no need to learn VB, Java, or any other programming language. If you're writing about soil horizons and levels of acidicy, you better know a little bit about geology. If you're writing about language disorders, you better know a little about how the brain works and about linguistics. If you're writing about database design, you need to understand database design, and a bit of SQL might be helpful.
Why?
Because if you know about it, you can take mediocre writing and make it great writing. You can take helpful writing and turn it into a priceless resource that no one will want to be without.
If you're writing GUI stuff, chances are you can get by without knowing a programming language. You will, however, benefit from it. I know that I am always pleasantly surprised when a bit of technical knowledge that I have allows me to take in something an engineer says and immediately understand it, without having to go into blank-stare mode. I'm even more pleasantly surprised when I receive a piece of code as an example and I can tell from the code exactly how it will impact the user's workflow. I don't have to ask the engineer what it will do, because I can see what it will do. I can decide for myself how a change is going to impact a user. I can decide for myself what I need to say about the change, being as technical or as lay as I need to be.
And, of course, the other benefit of knowing the technologies you're writing about is that you will be able to find mistakes, problems, or just plain bad design and understand why it should be changed. So, all of those helpful suggestions that you want to make suddenly have some weight and validity to them beyond the visceral feeling one might get.
Am I saying you need to be an expert in the field?
Nope.
Am I saying you need to have some knowledge?
Yep.
Am I saying you need to be able to (and willing to) learn new things?
Yep.
Technology doesn't bite so go out and learn it. Well, if you're building your own computer, you do usually have to bleed a little to make it work, but other than that, technology doesn't bite. Oh, unless you're talking about an Ibo, in which case it might be programmed to bite. And of course, there's all them nanites out there that are going to otherthrow our world some day. But other than building computers, the Ibo, and nanites, technology doesn't bite..........<twitch /> :-)
