Bullet points
- Companies that hire contract technical writers are often in disarray
- Many companies don’t know quite what they want and they don’t know what you need to do your job
- Technical writing and research go hand-in-hand
- It is always nice to know who your audience is
A not quite new building
My first day of work was not the first time I had been to the PHPS building. When I had worked as an associate lobbyist, I had sat in the office of the PHPS CEO and rattled off a list of bills coming up in the next legislative session. I had shaken the CEO’s hand and made small talk about the UA basketball team. PHPS had been one of the firm’s largest clients. Two years had passed since then and my run as a lobbyist had come to an end. I wasn’t meeting with the CEO this time. My place was in the IT department, and my main contact was the lead programmer.
Who hired me?
It turned out that the lead programmer, the guy I had interviewed with over the phone, was a contractor. I was a contractor hired on the word of a contractor. In fact, most of the programming staff was employed by the same agency as I was. My manager was a well-dressed blond executive who shook my hand towards the end of the day and didn’t come by again for two months. The organization was “flat”. That meant the manager was in charge of over seventy people. He set me up with a computer and a cubicle and headed off into the sunset. I get the feeling he wasn’t even sure why I was there.
Undocumented workers
The lead programmer, Clem, gave me a basic rundown of what they needed. The program they used to track medical records was called AMISYS. AMISYS had several stock reports that it generated, but the company had decided that they needed custom reports — a lot of custom reports. To create these, they used a programming language called Speedware. When I started at the company they had already created 160 custom reports. The problem was that they were completely undocumented. No one had bothered to record what each report reported on, how to generate the report, or even who requested the program. There were just 160 report programs out there flapping in the breeze. It was my job to figure out what these programs did and document how to use them.
You can’t always get what you want
The challenge didn’t stop there. To add a level of difficulty, I was not allowed to actually run the reports. Running the reports might alter the data (or so they said). Altering the data would be bad, so running the reports was verboten. In the end, I could do four things. I could go through the screens and do everything but run the report. I could read through the Speedware code, which would give me the variables and the report headers. I could also try to get my hands on reports that had already been run. The remaining option was to ask people questions and play the role of a detective. That last option was the scariest one for me. Digging through data was my strong suit. Calling strangers was not.
Before I did any of that though, I needed to figure out what I was going to write and who I was going to write it for. Was I there to write for the programmers or the end users? Was I writing a reference or a manual? No one really had a plan for me. They just assumed I would take care of things. They gave me my tools, a P75 computer with Windows 3.1, Microsoft Word and a bootleg copy of PageMaker. The rest was up to me…
Further reading
- 14 Widespread Myths about Technical Writing by Tom Johnson: Not all of these “myths” are false in my opinion. My tools knowledge has gotten me more than one job, for example, but this is a good introduction to what people think technical writers do.
- The Sinking Ship is in Beta by John Hewitt: An article about some of the things that can go wrong on a project.
Questions
- What are the first steps you take when you start a new project?
- Do you thrive in situations that call for improvisation or do you need structure?
- What do you do to feel comfortable at a new job?
Comments on this entry are closed.