technical writing

First question: (I'm assuming this is already done.) What is your definition of a technical writer?

Second question: Which industry do you want to be a technical writer in? Each industry has a different knowledge base you'll need, e.g., medical vs. technological.

I don't suggest books at this point, because they're a static investment and go out of date pretty quickly, particularly for the software industry.

I'd recommend starting with free online articles. There are a myriad good ones out there related to the industry you want to enter.

The lack of resources may be because it is probably more common for a particular technical expert to write the necessary manual, advertising, reports etc than for a writer to develop the content expertise. And doing the reverse is more likely to happen if you enter a particular specialty. I do some technical writing in my day job but they pretty much got lucky that I already had writing skills.

I would second looking at job ads. It constantly surprises me what jobs I get and what jobs I didn't even get a call back. But even if you are not applying now, you can see what skills they list as must-haves or good-to-have. Then you can built a bit of a skills tool kit. These are evolving areas. Lass year i learn meta-analysis, this year it is qualitative interview methods, next year... who knows! These things are barely on the radar when I started out.

I used to do a good amount of technical writing to supplement my more creative freelancing. (It paid a whole lot better but was also a whole, WHOLE lot duller.) Anyhow, a very smart guy I know gave me the following advice which proved very helpful:

You first need to know what industry (or section of industry) you want to do your technical writing in. Start reading everything you can relating to that particular group and (most important) figure out the 20 most common buzz words (or phrases) for that group. For example, in the cable TV biz it used to be 'scaling', 'to the home' 'arpu' (for average revenue per unit) etc. Anyway, once you know the meaning of those 20 or so words or phrases you can talk to virtually anyone in that industry or subsection and sound knowledgeable. Which is the first step to getting hired.

Goshawk31 said:

You first need to know what industry (or section of industry) you want to do your technical writing in. Start reading everything you can relating to that particular group and (most important) figure out the 20 most common buzz words (or phrases) for that group. For example, in the cable TV biz it used to be 'scaling', 'to the home' 'arpu' (for average revenue per unit) etc. Anyway, once you know the meaning of those 20 or so words or phrases you can talk to virtually anyone in that industry or subsection and sound knowledgeable. Which is the first step to getting hired.

Click to expand...

That sounds more like copy writing than technical writing.

Generally the point of technical writing, whether its a cookbook, a help system, a software manual or the assembly instructions for a flat-pack desk, is to communicate specific information clearly so that the reader can understand and follow instructions or otherwise accomplish a specific task.

Technical writing in general emphasizes clarity and precision.

I say this as someone who has been tech writing and tech editing for somewhere around thirty years. I've worked on hardware and software documentation for end-users, engineering documentation, proprietary help systems, manuals for computer hardware and appliances, and consumer instructions written with restricted vocabulary so that they could be computer translated.

I think figuring out the niche in terms of the kind of technical writing first, and concentrating on writing and revising in general is good advice.

Being able to learn new information quickly, and explain it clearly to someone else has helped me a lot. Being able to revise prose to fit a style guide and space limitations while still being clear is important.

I'm looking for some book recommendations that would be a good resource for a person with a pretty non-technical background (me, it's me) to maybe feel half-way competent at trying to pick up technical writing. I found a used one a while back, which I bought on a whim, but it was published in 1990, so it is super basic, and not much beyond what seems like common sense stuff for me, someone who theoretically already understands the concepts of basic writing and organization. Of course, since 1990, all sorts of computer/tech things have happened, and so all the recent things about "learn to be a technical writer" that I saw on Barnes and Noble.com seemed to assume you already know html or XML or some other language, which I do not. I'm willing to learn, I just can't figure out the best place to start. When I look at job postings, none of them seem to mention XML, for example, but they often reference a ridiculous variety of software, almost none of which I've ever heard of. Sometimes it seems like none of the jobs use the same software at all, if the postings are any guide, so I'm not sure how big of a deal the software is to start with.

Click to expand...

I don't want to discourage - but you've got a pretty steep hill to climb.

As a design engineer in my past life - working in Silicon Valley for Cisco Systems, Olivetti, Hewlett Packard, GTE, and many small firms - I've waded through a ton of poorly written technical documents, most of which were written by people who couldn't find their ass is they used both hands. So, I suggest you learn as much about the technology you'll write about as possible before you apply for a position. THEN if you get hired, befriend an engineer and learn more.

Of course, there are empty-suits out there that will hire people to write pretty, nicely formatted books that no one pays attention to, so I could be very wide of the mark. I've gotten into shouting matches with Senior VP's over why we ignore the documented procedures, it wasn't pretty.

Having done a fair amount of technical writing and documentation over the last 20+ years, I would say: The ability to learn things quickly and to write with clarity and precision are what you need most to get started as a tech writer.

So you need to be able to demonstrate you are competent in the core skill of organizing and presenting complex information in a way that makes it clear and useful to others.

As far as tools and software are concerned -- there are a huge number of tools that technical writers may be expected to use, but many of them are either proprietary to an organization or extremely specialized, and in either case not something that an entry-level hire would be expected to have previous experience with. Plus there are always new tools, new packages, new methodologies and business fads that cycle in and out of importance. It sounds like you're set with most of the basics. You should also have Visio and basic HTML. (Visio took me literally 10 min to figure out when I first encountered it, so really not a big hurdle!) Beyond that, note what's mentioned most frequently in the entry-level job postings you're interested in. You should be able to categorize them -- markup? scripting? graphics? CMS? Familiarize yourself conceptually with the major categories of tools, and if something is named a lot consider spending some time with online tutorials or classes so you can put it in your toolkit. If you're the kind of person who picks up new software easily, don't stress about it. If you're the kind of person who struggles with new tools, don't waste your time trying to become a tech writer.

Domain expertise is a more difficult question. Organizations do tend to favor candidates who know their way around the subject matter and are able to ask intelligent questions and understand the answers when dealing with the subject-matter-experts who are your sources and often your customers too. As indianroads says, it helps to know what you're writing about! So if there's an industry that's dominant in your area that you're specifically targeting, learn what you can. BUT... especially at the entry-level, if you don't already have in-depth knowledge of some subject area or a deep commitment to a certain type of organization, you don't want to over-specialize yourself out of being able to follow up many different potential leads. In my area, major employers of tech writers are found in software, healthcare, manufacturing, financial services, pharma, health insurance, and education. A new tech writer who does not have prior experience in one of those domains may want to apply to any of them, and then learn more in the field where they're actually working.

And just knowing what an organization's core business may be doesn't tell you much about what their documentation needs are going to be. Especially with large organizations, there are a lot of process and service areas that don't involve the core business but still need tech writers. A company may manufacture industrial widgets and have fiendishly complex equipment and logistics, or they may sell medical SaaS with a giant server farm and a horde of installation teams and software engineers, but they both have HR and Accounting departments too, and those tax forms don't print themselves...

Many tech writing jobs require candidates to provide writing samples. Since you haven't been working professionally in the field, go ahead and write up some sample documents on your own. If you're ready to work as a tech writer it should be simple enough to write up some procedures or technical guides around relevant things in your own environment. (Frex, back in the day I wrote a step-by-step guide to programming my VCR. My procedure was WAY better than the gibberish it came with!) It's probably a good idea to prepare samples that may be at least vaguely connected to the industry you're trying to break into, otherwise the hiring manager's eyes will glaze over if they're confronted with a type of information they know absolutely nothing about.

I've written a number of books on various pieces of Microsoft software and you really need some expertise in the software to be able to write about it. And not just how to use it, but how it works and how it's programmed. You say you know Office pretty well, but can you write a macro to merge a mailing list in an Access database to both letters and labels? Or program Excel spreadsheets to calculate sinking fund returns using pivot tables? Those are the kind of skills a technical writer for a software program needs to be familiar with, if not an expert. There' aren't a lot of book sales in the "How to change the color of your fonts" category.

That said, most software technical books are about upcoming releases, not current ones. That means access to beta tests, designers, programmers and the tech people at the company. Many manuals on the operation of specific equipment need less hands-on knowledge. They need someone who can take the ramblings of the engineer's notes and put them into a checklist for proper operation of the equipment. These kinds or projects don't require as much intimate knowledge as they do the ability to organize and accurately describe a specific set of tasks.

My first technical writing was how to make a peanut butter and jelly sandwich. The instructor brought in bread, jelly and peanut butter and, in front of class, followed everyone's instructions to the letter. Nobody wrote instructions that resulted in the perfect peanut butter and jelly sandwich, which was the lesson. Something very ordinary to you can be very unordinary to someone else. Get past that issue and you're there.

Jeff