People ask me how I became a Tech Writer. And I tell them it was by studying something else. In High school, my favorite English teacher once told me: “It doesn’t matter what you do. I know you’ll always be writing.” Looking back over time, I realize she had an amazing insight. I’ve always loved “playing with words,” but my High School self thought I was going to be a marine biologist. As time passed, I tried on other possible paths: pharmacist, medical technician, archeologist, botanist, and even a cook. I graduated from college with a BS in Biology, focusing on ethnobotany, hoping to end up as the Indiana Jones of the plant world. I was in for a disappointment and a surprise.

Let’s just say there wasn’t a major demand for ethnobotanists. Or botanists. Or even biologists, for that matter. My fellow biologists and I made grim jokes about having a great future in the Peace Corps. But then a strange thing happened. In college, I’d been doing English tutoring for friends in Engineering and Computer Science, to whom the art of constructing an understandable sentence was a mystery. I’d developed a system using computer flow-charting to demonstrate the parts of speech, which they could relate to, being presented in their own terms. Eventually, people started asking me to rewrite term papers into an intelligible form. To do this, I needed to understand technical concepts, which my friends were happy to teach me. Intrigued, I started picking up bits of programming and Boolean algebra. A few of these folks went to work for tech companies. After hearing I was a new graduate who was unsuccessfully looking for a job, a few friends reached out and asked if I’d ever considered becoming a technical writer.

“What’s a technical writer?” I asked, intrigued by this new prospect. And suddenly, I had a job interview in Silicon Valley. Taking along my friend Dave’sscrawled notes and circuit diagrams, along with my reworked copy of his thesis, I showed them to the manager. He looked back and forth between them, gave a low, slow whistle, and I had a job offer on the spot.

My varied background has served me well, especially since I found that“Technical Writer” is a title that only covers part of the actual job I’ve done over the years.

I’ve always enjoyed puzzles and mysteries, figuring out the big picture from clues. And I found that a lot of tech writing was ferreting out those clues and assembling them into a bigger picture, solving the mystery, as it were. Along the way, a tech writer learns to ask the questions that people who are too close to an issue often don’t think of, even those questions that evoke an eye-roll. It might be as simple as “does this have an on/off switch?” or as complex as “but wouldn’t this instruction cause an infinite loop?” And, of course, we writers also function as testers. If anyone can break a new software tool, a tech writer can! Because we do all the things that developers assume people won’t do. That may be why our closest allies tend to be in QA.

Also, because you have to learn new systems, you often end up acquiring additional duties. In one of my earliest jobs, I learned all about the company’s laser printer products, so I could write the manuals. The next thing I knew, the department was using me as an in-house laser printer technician whenever something broke! In another position, when the department started using Unix-based utilities, I learned Unix programming and ended up as the system administrator, in addition to my regular writing duties.

The job is always evolving. Along the way, you get to learn new skills, be present on the sometimes-bleeding edge of technology, and work with amazing and talented people. And sometimes, it has unexpected excursions into such varied fields as writing ad copy, documenting case studies, and creating blogs. During the Great Recession, I even worked with a group of lawyers on “The California Guide to Bankruptcy”!

Psychologists say constant challenges keep your brain nimble. I always joke that you don’t even have to change companies or departments to end up with a completely new job every couple of years, as tools and strategies keep changing. A few years back, I started work documenting hardware for a “big data” project. Oh, and you’ll also be working with Hadoop, they said on my first day at the job. “Okay,” I said, “What’s Hadoop?” The next thing I knew, I was learning Hadoop and SQL, and various databases. While I was there, we started porting Word documents into Confluence, then those files into XML, then XML into Markup, as the company experimented with different rendering tools. Adventure indeed!

Yes, it’s definitely an adventure. I’ve wrestled Github and AWS, fought poorly-written utilities, tamed unruly hardware, slain system bugs, helped resurrect dead applications, and still delivered the write-ups on schedule. Who says you can’t be the Indiana Jones of Documentation!

By Jane G. Beckman