Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Technical Writing Other Than Software

+0
−0

There is a lot of advice on how to be a tech writer for software without a tech background. (That is, skills such as understanding end-users, investigative reporting-type skills to probe experts, etc. as applied to software.) Software has a lot of information available that is relatively easy to pick-up by gaining the relevant language and elementary skills needed.

However, I have trouble finding advice about breaking into tech writing for other, more complicated (perhaps) areas, such as electrical engineering or physics, without a tech/engineering background.

My question: Are "more technical" areas outside of programming accessible to the non-tech-background technical writer; and, if so, what are some necessary steps without becoming a full-fledged engineer or scientist?

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

This post was sourced from https://writers.stackexchange.com/q/27158. It is licensed under CC BY-SA 3.0.

0 comment threads

1 answer

+1
−0

This is one of the great debates in technical communication. Do you need to be a technical expert or is it enough to be an effective communicator? Different tech writers, and different employers, come down on different side of this debate.

I think there are two main factors to consider here.

First, good writing, fundamentally, in not just about good grammar, it is about knowing what needs to be said. Saying the wrong thing in beautiful words is of no use to anyone. Saying the right things in clunky words is less than ideal, but still usable. So the question is, how easy is it to figure out what needs to be said? Chances are that the engineers who built the product don't know what users need to know, so it is not use asking them. When we were mostly documenting home and office software applications, technical writers were themselves home and office software applications users and so they had a pretty good idea what needed to be said. But when nobody knows what needs to be said, you get documentation that is engineering bafflegab. A writer may strip out the jargon, but the content is still not what end users need to know.

The proliferation of desktop apps has largely ceased. Most people know how to use them. The consumer action now is mobile, where apps are much simpler and easier to figure out. Therefore there is less demand for this sort of tech writing.

Many of the people who were doing desktop software tech writing 15 years ago have transitioned into more developer-oriented tech comm or into more marketing related roles. If you are writing for a developer audience, you don't naturally know what developers need to know about a product unless you are a developer yourself. But at least those tech writers have had the benefit of working with developers for a long time, which certainly helps.

For non-software-related tech writing, though, knowing what the user needs to know can be far more difficult, and understanding the equipment so that you can figure out how to map its properties to the users needs is also more difficult. In many cases, there are safety and regulatory considerations as well. And most writers -- people who identify themselves as writers, I mean -- don't have any experience with the task or the tools that these users are performing and usng. All this means it is more difficult to get into the position of really knowing what it is that the users needs to know.

Also, users in these fields often require specific training before they can use the machinery or perform the tasks, which means that the share much more of a background and vocabulary with each other than typical desktop software users do. All this means that it is easier of people coming from working in those fields to turn to doing technical writing in those fields. They are writing for people with tasks and backgrounds very similar to their own. Domain knowledge is therefore more crucial than writing skill.

Second, while the ideal qualifications of a tech writer are that they a) know how to write, b) understand the technology so they can talk to the developers, and c) understand the users and their tasks so they know what to write, the fact is that it is hard to find enough people with all three qualifications. People do therefore get hired for tech writing jobs with only one of two of these qualifications.

There are many in the field who insist that this is the natural proper state of things, that all a tech writer needs are good writing skills and the ability to do research. Many employers disagree, for the good reason that they have cost constraints and deadlines to meet and that tech writers researching things from scratch not only takes too much of the tech writer's time, it takes too much of everybody else's time as well.

In short: Technical communication is not a profession with fixed boundaries or expectations, much as some people and organizations would like it to be. Your mileage may vary.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »