A Career in Technical Writing: Life as a newbie
July 10, 2008 by J.C. Hewitt
Bullet points
- Struggling to make the wrong tool work for a job can add months to a project
- FrameMaker is good for long technical documents
- PageMaker is good for sending a newsletter to your Aunt Fanny
- Sometimes the most important thing a technical writer can do is gather information
- When expectations are sufficiently low, it’s easy to be a star
Meet your Maker
I wish I could say I got off to a running start and quickly proved my value at my new job, but this is about my real career, not my resume. Life at PHPS did not begin with a bang. No one really knew what they wanted me to do, and my equipment wasn’t exactly state-of-the-art. I was hoping for FrameMaker, but I got PageMaker instead. The two products sound similar, but there is the world of difference between them. PageMaker wasn’t designed for long documents or technical material; it was designed for creating newsletters and flyers. I knew the product pretty well from my days working as an editor for a small newspaper, and I knew it wasn’t going to do anything I needed it to do. That didn’t stop me from trying. I designed a few pages of how-to materials, but the process was slow and tedious. Before I knew it, three months had passed and I really hadn’t produced much of anything. It was at that point that I decided to change course.
That report has a lot of fans
I had spent a lot of those first three months reading code and looking at output. Both the code and the output came on long bands of fanfold paper. You don’t see it as much anymore, but back then most reports were printed on page after page of green and white paper held together (and in order) by perforated edges. For some reports the code ran only half a dozen pages or so, but others ran much longer. As for output, that could go on for hundreds of pages, but I rarely needed to see much beyond the first and the last page. Those were the ones with the column headers and the totals.
Sometimes your audience is just a cube away
After three months of banging my head against a monitor trying to develop something for the end users, I gave up on that and decided to create a reference manual for the programmers. I wasn’t sure if it would be useful, but there was no one to tell me not to do it, so I just switched gears and started putting something together.
The reference manual was far from pretty. I created it using Microsoft Word, which could handle text just fine, even if it fell short on the artistic end. I went through the code for each program and documented the one thing I was sure the programmers would care about — the variables. Every program had a list of variable names somewhere in it, which it used to call up information from the database. In addition, the program code listed the header information and the column names for the output, so I documented those items too. I also had (from the interface) a list of what programs were used by which departments, so I recorded that. If I had any other information, such as someone’s description of the report, I plugged that in too. All of these items together started to look useful, so I showed it to the programmers.
Believe it or not, I’m on top of the world
The programmers were ecstatic. They loved it. Without knowing it, I had created exactly what they were looking for. They could now look over the reference and figure out if an old program could be turned into a new one because it shared enough key information. This would really speed up the programming process, they told me. I was a hit, but I felt a little guilty. Creating this really wasn’t that hard and I didn’t do any real writing. All I did was gather information. If I had known that this was what they needed, I could have given it to them three months earlier. I didn’t say this, of course. I just went back to my cube and tried to figure out what to do for the end users…
Further reading
Quick Reference Guides: The Poetry of Technical Writing by Tom Johnson: An excellent guide to condensing a manual down to a two-sided piece of laminated paper.
How to Get a Lot Done – 7 Tips to Achieve More by Collis Ta’eed: Planning, teaming, delegating… give it a try.
Discussion questions
- How do you set goals for an unfamiliar project?
- When a strategy isn’t working, how do you know when to scrap it?
- How do you handle praise?
Comments
10 Responses to “A Career in Technical Writing: Life as a newbie”
Job Categories
Subscription Options
John what a delightfully detailed series this has been so far. I just relish small details like, “I created it using Microsoft Word, which could handle text just fine, even if it fell short on the artistic end.”
It’s this type of insight that lets readers know what a writing niche is “really like.” Kudos to you for doing a masterful job of peeking into the world of a Technical Writer.
Yuwanda Blacks last blog post..How to Stretch Free Articles into Dollars
Yuwanda,
Thanks for the comment. I really want the series to paint a true and engaging picture of the career. There is the good, the bad, the mundane and the strange. I hope I can capture a bit of it all.
John, I think some of the biggest job problems I have had over the years stemmed from supervisors who didn’t really know what “they” wanted. Sometimes I got lucky like you and did something that was a hit and sometimes I fumbled around with no direction. As I got more experienced and older, I tried to communicate with some of them about what they wanted, but that didn’t always work either.
Looking forward to the rest of the story!
John,
It’s interesting that you felt guilty because you just gathered information rather than doing a lot of writing. Sometimes our own expectations get in the way – you met the programmers’ need yet didn’t feel right about it because you didn’t meet the need in the way you thought you should.
@ Morgan
Morgan, I agree completely. It is hard to show initiative if you have no idea what direction to go in.
@ Lillie
I’ve never been good at accepting praise I don’t feel like I’ve earned.
John, I have to chime in with Lillie here. You say, “All I did was gather information.” You should be praised for seeing the need and having the initiative to move forward on it. Gathering information is time consuming, and I imagine that the programmers you worked with probably didn’t feel they had the time to do what you did. The fact that you did it without having to be asked to do it is highly praise-worthy
I tried to do something at my most recent job by creating a relatively simple Access database of all the programs for which I was responsible for running on a routine basis. I used Access because I wanted to be able to create simple reports such as lists of programs that are run on a monthly schedule or a weekly schedule. One of my goals was to eventually include variable lists in the database but I left the position before I could get that far.
Still, the database was popular among the section managers who saw it as a way to keep our programs up-to-date. My coworkers were actually less enthusiastic since they were delegated the responsibility of providing background for each of the programs. Most of the programs had no documentation attached to them, and so, for many of them, this was just more work for them to do.
In spite of my coworkers’ antipathy, I feel good about creating the database. At the least, it enabled me to do my job more efficiently. Most of my praise came from my supervisor, which I accepted with as much humility as I could muster
.
Marie Ann Baileys last blog post..Using Writing to Mentor Students in an Online Course
Hi Marie,
I understand what you are saying. One of the side effects of showing my career as a writer is demonstrating the ways in which I have grown. What I was pointing out was that I had struggled for months to do something fancy when what the programmers needed (but didn’t know they wanted) was something simple. It didn’t take much work on my part compared to the other project, but it is probably the most useful thing I produced there. At that time I felt as if only hard work should be rewarded, and that project wasn’t very hard work. I know now that if what you created helps someone else, thats the important thing.
Well, John–
If it took you three months to figure out what they really needed, that’s hardly your fault. If they’d told you they needed that particular report “three months ago,” they’d have gotten it “three months ago.” If the company doesn’t even know what it needs, how can it expect the “newbie” to know? I think they were fortunate that you figured it out–and did so without their help or guidance.
Jeanne
Jeanne,
I agree. A clear plan always helps, and it was in the company’s best interest to have one. In the end though, having that much autonomy helped me, because it forced me to manage a project, which was a skill that I would need later.
[...] A Career in Technical Writing: Life as a newbie [...]