My Internship as a Technical Writer: what I learnt

Guest Post By Dave Fruscalzo

Over this just-passed Australian summer, I completed a five-week internship as a technical writer for a growing software company. The internship was arranged through my university, where I am now completing my final semester, enrolled in a Postgraduate Diploma in Arts (Editing and Communications).

I was persuaded to try technical writing through many sound and convincing arguments. Last semester’s class, titled “Technical Writing and Editing”, informed me of some of the profession’s strong points: reasonable pay, a boom-time for the industry, the opportunity of contract work, rewarding and challenging work, and in Australia, a lack of any clear-cut university course geared towards technical writing, the idea being that it is a profession relatively easy to get into.

Of course, like I understand of most professions, it wasn’t all to the glowingly positive; contract work can bring with it workflow uncertainty and possible job insecurity, what goes boom can also go ouch, and challenging and rewarding are ideas too personal and subjective to measure in any certain terms.

However, Technical writing appealed to me. What I had learnt in class was that writing and editing into plain, clear and efficient English was an involved process. It was kind of like a puzzle where all the words were jumbled, meaning something, but not in the best way they could be. My lecturer in my technical writing class referred to badly written procedural/instructional documentation as, “Terrible, unnecessary time-wasters; something to avoid at all costs.

So, with my internship finished, I’d like to reflect on a few things I learnt.

Writing is not always the biggest part of a technical writer’s job

I worked closely with one other technical writer (let’s call him, Frank) during my internship and on my first day I was told, “Writing only takes up about 20% to 25% of the job.” Shock. What an inappropriately named job title, I thought.

My duties consisted mainly of compiling documents for an internal help system. My time was spent adding tables of contents, tidying up headings, trying to keep the look of documents consistent, adding a glossary of terms and an acronym definitions list, and the odd editing job.

Frank told me, “Most of what I do is act as a buffer, a facilitator of information between whoever is writing the documentation, and the audience. Now, sometimes it’s me writing the documentation, but sometimes it’s someone else, say a software developer, who has intrinsic knowledge of the process he or she is trying to convey, but they are not a trained writer; that’s more my thing. It’s my job to get the information to the audience in the most clear and accessible way, so they can best understand.”

Although the actual writing only made up a fraction of Frank’s work, it was still an important part of the job. He said, “Anyone can learn software or applications, but it’s harder to find a good writer, someone who knows how to use language in the correct way.”

You need to know how to ask the right questions

After my first few weeks were spent doing a bit of grunt work, Frank decided to give me an editing project. “Your first, professional editing gig,” he said, beaming with what appeared giddy delight. I reassured him that I was, in fact, partaking in an unpaid internship. He repeated, “Your first, professional editing gig.”

I was given a rough, 1000-word document that covered a specific process in a complex software application. A software developer had written it. English was their second language. I was left to my own devices.

I probably spent about two-to-three hours just reading over the document, trying to make sense of it, doing basic copy-editing, keeping styles consistent, adding captions to images, etc. The software developer had done a good job getting all the information in, and the instructional content was of value to many who would be reading it in the future. But it was rough. Not to mention I had no idea of how this software worked, and was unfamiliar with all the terminology/jargon.

There is only so far you can go when editing a complex procedural document with which you have no real idea or concept. And around this time of banging my head against my very slow computer’s monitor (not really; the slow part is true, not the head-banging) is when I received an email from Frank, who was working from home on this day. He suggested talking with the software developer (let’s call him, George), and asking him my questions. “He is sitting just a few desks behind you,” Frank’s email informed.

And boy, what a luxury that turned out to be. Speaking with George was the best thing I could have done for this particular assignment. I was able to understand his ideas more clearly when he was able to explain them verbally. Although it did take me going back to George a few times, with more questions, before I realised the best questions to ask. They were the questions covering the fundamentals, and I believe, the most important ones to ask first. What specific idea or step are you trying to convey? Who are you conveying it to? Asking these two simple questions really sped-up the editing process.

Where there are writers, there will be quibbles

That verses which? Serial comma, or no serial comma? Vonnegut, or Foster Wallace? Decisions, decisions.

Any good technical writer will have a decent understanding of grammar and syntax. Therefore, I have also surmised that they must have an interest in the written word. And that brings opinions, beliefs. Is there anything more fraught with debate than the topic of English and its usage? Doubt it (Ok, there are a few, but usage is right up there). What about if two technical writers working together are from different English-speaking nations? Opinions, beliefs.

The quibbles all subside when the most important aspect is considered: the audience. If we’re writing for Americans, we will use American English, writing for Australians, we will use Australian English. You get it. Has the word which really become so obsolete in Australia that that is used to mean both which and that, defining and non-defining? Well, if that’s how our audience understands something to be, then that is how we will write it.

Frank said, “My job is not to come in and be a grammar snob, telling people how language should be used. Maybe, if I was writing documentation on grammar, I would have a right, but that scenario is probably pretty rare. My job is to make sure the reader comprehends; I am not going to go out of my way to break the rules of grammar, but the most important thing is that the reader gets the message we are trying to give them. So, I will write it how they want to read it.” Wise words.

So, if you must know

I am going to pursue technical writing as a career. My internship was worthwhile; I was lucky to have a good mentor, in Frank, and an exciting company that made an effort to include me in ways that go beyond your standard coffee-making-intern cliché.

I learnt many things, and more importantly, I am excited about learning many more.

Dave Fruscalzo is a postgraduate university student and soon-to-be technical writer in Melbourne, Australia.