A while back, someone left a comment on a post aimed at novice technical communicators. In the comment was a request to explain “what should a tech writer know, step by step, beginning with level zero”. I posted a comment, saying that I’d bang out a reply in a few days.

Well, it took a little longer than that. Partly because a number of other things got in the way. And partly because the request wasn’t as simple to tackle as it looks. What you’re about to read isn’t the definitive guide to what a new technical writer needs to know. Not by a long shot. If you have anything to add, please leave a comment.

So, here goes …

Get educated

Knowledge, as they say, is power. And you can’t have too much knowledge in this profession. Aside from basic computer skills, you should have (or plan to acquire) a good level of technical knowledge. At the very least, you should have a cursory knowledge of the key technologies you will or may be working with, of programming and scripting languages, and more. Aaron and I discussed this in detail in a podcast.

Why do you need to know all of that? To get respect, you need to be able to hang with developers and subject matter experts. You can’t ask them very simple questions and expect them to take you seriously. In the past, I’ve seen developers and SMEs shun technical writers who couldn’t cut it technically. I always think I’m doing my job properly when a developer tells me to stop asking tough questions.

The level of knowledge that you need will vary. With some technologies, having enough knowledge to be dangerous is enough — you have a grasp of a technology, and can intelligently ask developers questions about it and understand the answers. With other technologies, you’ll need more in-depth knowledge.

There’s also a lot of what I call situational knowledge — things you know for the duration of a project or release. For example, a project that I worked on in my previous gig required me to learn quite a bit about logical partitions on AIX. I think I did a pretty good job of explaining how the software I was documenting interacted with LPARs. Now, about a year or so on, I’ve let a lot of that knowledge slip from my memory.

Learn the tools and techniques of the trade, but be adaptable. Aaron and I always say we’re tool agnostic — we can work with just about anything. We’re able to do that thanks to the experience that we’ve had will a variety applications, markup languages, and systems.

How about a technical writing course?

If you want to, fine. I’ve never taken a formal technical writing course and I’ve done OK. That’s not quite true; in the late 90s, I did start to do a certificate program in information design and finished about half of the required courses.

Essentially, I’m a street-trained technical writer and technologist. I learned the basics of tech writing from a textbook that I bought at my alma mater’s bookstore in the early 1990s. I put what I learned from that volume into practice by writing manuals for myself and for a community environmental group with which I volunteered. I critiqued those manuals, and others that I read. I wrote articles for technology publications. I taught myself HTML, graphics conversion, various computer skills, UNIX, and even tried to get a handle on SGML.

But a big part of my development as a technical communicator was the two years that I spent working at a financial software firm. Long hours, a mix of applications running on Windows and OpenVMS, and a lot of developers with a low tolerance for ignorance honed various skills.

That’s not to say a technical writing course won’t be useful. I just never saw the need for one.

Learn to write

Writing is an important part of technical communication. You don’t need to be a budding novelist or a brilliant essayist to write documentation. In fact, that’s hindrance. But you should know how to write concisely, and how to organize information. In that way, technical writing is like journalism. Comic book writer Mike Baron once said that journalism was mainly about knowing how to put information together.

Another important skill is knowing how to interview. Interviewing involves more than answering questions. It’s also a matter of asking the right questions, and how to draw information from someone — especially someone who’s reluctant to give you that information.

Get your hands dirty and build a portfolio

There’s an old saying that you can’t get a job without experience, but you can’t get experience without a job. Well, in the case of technical communication I think that’s bunk. Especially now. You can gain some level of tech writing experience without a job. By doing so you’ll not only be able to build a modest portfolio but also show potential employers that you’re eager and that you take the job seriously.

So, how do you build that portfolio? As I said earlier, I wrote and typeset a number of small manuals. This was before the Web went huge. You can do the same thing with applications that you frequently use — either put out a PDF or use a wiki. Or, create some content that covers how to use an application or device in a way that the bundled documentation doesn’t cover.

Also, consider contributing to FLOSS Manuals. You’ll gain some valuable experience, learn about some interesting software (not just what you’re documenting), and contribute to a very worthwhile project.

Enjoying what you do

Equally as important as anything I’ve already written is your mindset. To become an effective technical communicator, you have to really enjoy what you’re doing. You have to enjoy working with technology. You have to enjoy learning and solving problems. You have to be excited by the challenges that technical communication offers.

Technical writing isn’t art. It’s not going to prepare you to write the next great novel (Thomas Pynchon is a exception, though). And if you’re in the profession just for the pay packet then you’re probably not going to do the job to the best of your ability.

That said, you should keep in mind that your passion for the work will wane from time to time. You have to be willing and able to deal with that.

Summing up

OK, that was 1,000 words or so. All of that can be summed up with this thought:

I don’t think that there’s any one path to a career in technical communications, and I don’t think that there are a definite set of steps to follow. It will vary from person to person. But if you’re serious about a career as a technical communicator, you’ll find your way.

Related posts:

1. Technical tech writers, redux
2. Foreign language skills and the technical communicator
3. Situational knowledge and the technical communicator