Does a technical writer need a technical background?
asked Mar 17, 2011 at 17:02
Add a comment
|
17 Answers
Short answer: no.
Nevertheless, it's a plus. It is good to have a deep knowledge of the field you write about, so your documents have more weight and insight.
I'd choose, given the same writing skill level, a person with technical background over one with no technical background, if what I'm looking for is technical documents.
Why not have the edge, if you can? Make sure you're a great writer, or get work with whatever subject you're going to write about, but do land the gigs.
I am an experienced technical writer specializing in API documentation. In my experience, in order to be successful a technical writer needs enough technical aptitude to (1) understand the users' needs and (2) probe the subject-matter experts (SMEs). If all you're going to do is parrot what the SMEs tell you, you're going to miss important details. SMEs (in any field) have blind spots; they've been living in the depths of their code so long that they can forget that the "obvious" assumptions aren't obvious. They also tend to have a particular model of how users will use their product, which might be more speculative than reality-based. (I'm not criticizing them; they often don't have enough information.) It's the technical writer's job to dig into all that. (Also the tester's, if you have one.)
When I hire technical writers I look for a certain threshold of writing skill but then I look for technical aptitude. I'd rather have a competent writer who understands the technology than a writer who produces excellent prose but needs lots of help to figure out what to write. It's easier to help the competent writer improve writing than it is to help somebody deeply understand the relevant technology.
answered Aug 28, 2011 at 3:27
From my experience, not explicitly. But a technical writer does need to understand what they are writing about in order to communicate it effectively. If you'd like a book on the subject, Technical Communication by Mike Markel is an excellent resource for all aspects of technical writing and communication.
I have a technical background myself, but I've worked with some first-rate tech writers who wandered into the field from the humanities or social sciences. In my opinion, the best technical writing teams have a mixture of techies (to provide technical insight) and non-techies (to ask useful "stupid" questions).
That said, good technical writing is based on a solid curiosity about the subject matter. Your goal should be to make the technology accessible to your readers. Tech writers who are incurious about or intimidated by technology (and there are a lot of them!) write about things they barely understand in a superficial, misleading manner that drives readers crazy.
I do technical writing and publishing in the computer field, and to an extent I'll say yes. You must have some idea of the technology if you are writing original material about a technology. If you are writing technical details about work someone else has done, I think you can get by on good communication skills with a person that does understand the details of the subject.
I do think you need some technical aptitude or interest so that you can pick up on the jargon and general application of the subject.
Good rapport with a subject matter expert is going to be required in any case so that you can get a second opinion on what you have written and have a check to see if it conforms to the topic.
answered Mar 22, 2011 at 0:23
Technical writing is a three legged stool. To do it well and efficiently, you need three things:
Sufficient knowledge of the user's task to figure out what they need to know and how to communicate it to them.
Sufficient knowledge of the technology to figure out how it works and what you need to say about it, and to ask the developers the right questions.
Sufficient knowledge of writing and publishing to actually create a comprehensible and usable work.
Can organizations find tech writers with all three of these skills? Often they cannot, therefore they often have to settle for only one or two.
Do organizations all understand that technical writing is a three legged stool? No, sometimes they just want someone to do the words or someone to make the document look pretty.
Organizations who don't know that they need all three legs of the stool will careen from one communications disaster to another until they figure out that they do need all three. Then they will face the problem that it is very difficult to find a person with all three, especially for the salary they are willing to pay.
At that point they have to decide which of the three they can manage without. This will depend on the product and the market. If they are delivering a consumer product, the first leg is actually pretty easy, so they may focus on the other two.
If the market is highly technical, they may focus more on the first leg.
If they are desperately pressed for developer cycles in their production process, they may focus on the second leg in order to minimize the time that tech comm takes away from their development schedule.
Because of these different reactions to the scarcity of people with all three skills who are willing to work for the wages offered, you can get a job with only two, or sometimes only one of the three legs, but different opportunities will be open depending on which legs you have.
And, of course, both the first and second legs are more or less specific to particular industries. You can be have exemplary task knowledge of accounting software, for instance, but be entirely unsuited to tech writing for medical devices.
In short, it depends. Technical writing is not a generic commodity and you can be eminently qualified for one job and hopelessly unqualified for another.
-
Good, thorough answer; thank you for coming back to an old question to add it. Many companies are not aware of what a good technical writer with all three can provide (and why it's worth a good salary), but they are out there if you keep looking. Commented Aug 2, 2017 at 0:33
Yes, an effective technical writer will have enough technical background knowledge and experience to create useful content from the (often sparse) source material.
However, more important traits of effective technical writers are strong writing/communication skills and a deep curiosity about the subject matter and the audience. These will take a not-very-technical writer a long way in the job.
The "technical writer" title covers a broad range of job descriptions. As a result, in the field, working technical writers have a broad range of technical skills and knowledge requirements. The less technical the subject, the less stringently technical acumen applies.
Writers working with end-user documentation and help often have less need for deep knowledge of programming, for instance, though knowledge of the field in which the product is to be used is often expected. A background in user experience design (cognitive psych) is often a plus. And there are typically requirements around the production tools used by the team (Office, HTML, XML, etc.).
So the definition of "technical" may vary with the subject, audience and team.
On the other hand, more deeply technical content requires deep understanding of the subject matter. I don't think a writer with no programming experience could write useful API docs, and the usefulness of the docs probably increases with the experience and knowledge of the writer.
I have worked with technical writers who did not have particularly technical backgrounds. For the most part they could fake it by following forms and styles and reusing bits and pieces from other sources. This is, really, just glorified editing.
To be fair, however, I have also worked with writers with deeply technical backgrounds who also could not writer useful docs because they were not effective communicators. They understood the subject matter extremely well, but were unable to clearly and succinctly convey how it worked or what to do with it.
So technical knowledge is a requirement, but not the only one.
There are two scenarios where one could argue
I have done quite a bit of technical writing for healthcare information systems. There are two major categories that I can identify and each has different requirements. There are plenty of projects between these two categories with different requirements.
- General End User Docs:
- Documents that non-technical people must use to understand a minimally complex technical system. An example of this might be the user manual for a medical billing system. When writing this type of material, very little technical knowledge is needed.
- API Docs
- Documents that programmers use to understand a programming interface for a piece of software. Poorly written API docs can be fatal to integration efforts. This does require some technical knowledge, especially an understanding of programming. You don't need to be a full time programmer, but you should at least understand the basics of programming and anything specifically important to the API you are documenting. You should be provided a programmer, or someone who understands the API very well, as a resource on this type of project.
My company provides a human technical resource when we hire a writer without a technical background in the required area. If you can work well with a human technical resource, or even a non-human technical resource, it can drastically reduce your need for a technical background.
So in summary, it depends on how technical what you are writing is and the resources provided by the hiring entity.
I'm about to turn down a pretty good contract role as a technical author (TA) writing API for a company based in Gibraltar - sun, sand and senoritas! Why? Because I was able to get through the interview based solely on my personality rather than my aptitude for the subject. I'm a good enough TA to know my limitations and I have previous experience writing API so why am I saying no to a contract that I really need? The answer is that I don't believe that I could do it justice.
I do not have a 'reasonably' deep understanding of programming (JSON/Java/RESTful) and I would have to lean heavily on the developers to explain each nut and bolt of the code - thereby exposing what a wally I was and eventually discouraging developers or technical experts from providing the techy stuff that as an author, I should be clarifying for the audience.
I truly believe that a good author writes from experience, from a sound knowledge base of the subject, from a position of strength. Understanding your subject makes your prose flow, and flow with clarity and succinctness. So yes, a technical author does need a technical background in the subject matter that he is writing about; if only so that he can obtain the cooperation of the subject matter experts he will be getting the information from.
It goes without saying that if the author does not understand the information he is writing about then he will be clueless on how to sift through the data and clearly explain the subject.
No, you only need to know as much as the end-user would.
In my case, I came from a marketing and translation background and went on to become the Lead Technical Writer for Samsung mobile user-interface text. I never had to write guidelines or text for high-level programmers. I only wrote for UX designers and for the end-user of the devices.
The skills that allowed me to succeed in this role were a drive to understand and simplify as much as possible and always finding logical reasons to back my decisions. On top of that, remember that normally you'll work alongside a team or subject matter experts who will fill in the details for you. Force these smart people to think with lots of dumb questions and you'll produce extremely useful content.
-
And in some cases knowing less than a typical end user can even be useful, as long as you learn and tell everything they want to know.– hildredCommented Aug 3, 2017 at 15:33
No. I have been there and done that from both sides.
A technical writer needs to know enough to understand what they are given/told and turn it into something useful. Their job is to turn technical talk into something useful for non-technical people, and also to format it in a style the company uses for their documents.
Content has to come from the engineer/programmer, who may need help getting the useful information onto a page for editing and rewriting. The worst case would be interviewing them and creating the first draft for them. More often, it is checking back to see what they really meant or to fill in holes of things they omitted because 'everybody knows that'.
As with teaching, technical writing can be described as "the art of imparting information without knowledge."
You are the advocate for the end user. Your technical skills in this case are simply to get the necessary information from the experts, then present that information to your readers, in a way that both the experts and the readers are pleased with the results. I kid, I kid.
Seriously, given the necessary interviewing, research and writing skills (without which you'd be one of the experts, not one of the writers), a genuine interest in the topic area is helpful. Experts generally love to talk about their favorite subjects, and welcome a sympathetic audience.
I guess it depends. For writing end-user oriented documents such as SAP, JDE step-by-step work instructions on how to do something you don't really need technical background. You need to be a quick learner.
No, you don't need to have taken classes or earned a degree in your area. What you really need is an insatiable curiosity. One of the best examples I know of this is Martin Gardner, who for over 20 years wrote a column for Scientific American called Mathematical Games. He is given much credit for the popularization of recreational mathematics in the 20th century.
According to wikipedia: "Ironically, Gardner had problems learning calculus and never took a mathematics course after high school." As I recall, Gardner credited his lack of training in mathematics for some of the success of his column. Each month for his column, he had to learn about the topic, before he could teach it to his audience.
You need to understand (hopefully in a bit more depth than what you write) what the reader needs to know and what they already understand so you know what analogies, examples, level of detail, and other things to use to bridge the gap between that and the new material. So, you don't have to be an expert, but you do have to know where you're going if you want to lead someone else there.
Working with experts, you also have to know what the reader doesn't have to know so you can filter out unnecessary details and tangential topics.
You can always learn some of this as you go, but starting out with a general feel for the material and background really helps.
A slightly different angle is that technical (or any other kind of) writing can be as much about culture as explicit content.
To be most effective in writing for a particular technical community, you need to understand the subject matter you are covering, but also need to communicate in a style that resonates with that community. For example, if you were writing about the contemporary music scene in a particular city, you would lose credibility with the readers if you misused local slang or made out-dated references, even if your facts about the local bands were entirely correct.
In the same way, technical communities tend to have subtle but distinct ways of using and perceiving language that can mark you as an outsider, a sympathetic visitor, or "one of us". Read some well-regarded writing for the field in which you plan to work, and look for examples of the community's style.
Yes! But that doesn't mean an engineering degree, and the level of technical knowledge depends on the type of documentation. You need more engineering and science background to work for an engineering or science firm. You might need more statistics and financial background to work for a bank or write grant proposals. Here are some of the technical areas that most documentation and proposal writers will need to use: Math: Percentages, fractions, measurements, time, unit conversions. Science: Physics (basics like acceleration, force). Engineering: ISO standards, scientific notation, engineering drawings and symbols. Software: Code repositories, operating systems, databases, web technologies, publishing software and methods.
Personally, I have English and Journalism degrees, but I would be pretty lost if I hadn't taken physics, trig, microbiology, chemistry, astronomy, and other science and engineering-related classes in high school and college. I especially needed that foundation for engineering writing (my current job), but the technical background was also important in journalism jobs when I wrote about environmental issues, government budgets and taxes, weather stories, and many other areas.
