I Saw the Light: From Programmer to Writer

by Pauline Horn

I sat there reading the job posting - Technical what? Just what is this thing called technical writing? It sounds a little boring. Will I be able to mentor other writers? Will there be enough variety to keep me interested? Isn't it just sitting at my computer putting words to paper or screen?

These were the thoughts going through my mind as I pondered a career change. For over 20 years, I had worked as a developer, analyst and project leader deeply immersed in the darkness of technologies that support business applications. I supported mainframe, mid-range, PCs, COBOL, PL1, JCL, DCL, SAS -- all these techie areas and more. Maybe it was a mid-life crisis but I wanted a change from the constant stress of not knowing if I'd be called in the early evening but expecting that call at 1 am, 3 am, 5 am, and so on.

The Search for a New Career

I was lucky enough to be working at Clarica Life Insurance where there were plenty of opportunities and a variety of choices. From Business Analyst, to Training Supervisor to Manager in a business area; I explored these choices but none of them seemed to fit or work out. Then that posting came along for a Technical Writer.

While I was looking for new challenges, Carol Lawless was working with her management to establish a technical writing area in the Information Technology department. The mandate of this group was to produce documentation for the many legacy systems at Clarica. Readers of The Quill and members of the local STC chapter know that Carol has an extensive background in technical writing. Even though most of her experience was in the business part of Clarica, where technology is used without going into the deep dark depths of how it works, she brought her credibility with her to the IT department. To make sure the company used best practices in setting up the document model and procedures, she engaged outside consultants to help define the next steps. The message was clear - as you build your team look for a "writer who can teach or a techie who can write".

My job search was still on-going at this point. My management and Carol's management worked together to let me have a taste of this new "light side" before committing myself. At least I thought it was the lighter side of life. Somehow, I quickly earned the title of 'Freak' and was constantly reminded that I had seen the light and left the deep dark technical world. Our summer coop student called me 'Freak' since she had never met a techie who could write and actually enjoyed it. That's a nickname I treasure still.

The World of Technical Writing

I quickly became immersed in the world of technical writing and started to work on one of the largest and most complex mainframe systems at Clarica. My skills as a developer/analyst were invaluable as I turned very old process specifications into a Data Flow Diagram (DFD). I discovered that it was faster and more accurate to read the code and JCL to create the DFD. Aha, I really was still using my technical skills.

As I was learning the ropes, Carol had arranged for Judy Glick-Smith of Integrated Documentation Inc. (IDI) to come and provide an assessment of where we were in the documentation process and model. Judy assured me that my ability to read the code and translate into English were skills that would add a lot to the documentation process. It wasn't cheating to dig deep into my bag of tricks. In addition, she said we should seek out the 10% of developers who were closet technical writers and get their notes and documented processes. Wow, I'd been a closet technical writer all along and didn't know it -- I wrote instructions for junior developers, business requirements, and I even documented my code. Maybe I did see the light and had really seen it all along.

My career change occurred over three years ago now and most days at one point or another the phrase "I love my job" comes to my mind. I have learned the writing skills that make documentation effective. I've helped to fine tune our style guide, our documentation model, and our documentation processes. I've been fortunate enough to be able to work with other team members so they can glean the important information from code, JCL, and from developers' documentation.

A Comparison of Skill Sets -- writing words versus writing code

The job of a technical writer has a strong parallel to the job of a developer. By understanding the similarities and overlap between the processes, I've been able to help other technical writers relate their role to the developers who are, after all, our primary audience. My background as a developer has given me, and by default the rest of the team, the credibility we need to act as an equal partner.

The more I enhance my technical writing skills, the more I use the skills I developed when I was on the dark side. Some of these are:

• Audience analysis - a developer needs to know who will be using the system.
• Information analysis - a developer needs to analyze the business needs.
• Organization of information - developers need to organize code to make sure the tasks are done in the right order and that others can understand it.
• Testing written procedures - developers do more formal and automated testing, but the end result is the same; you check your product to make sure it works and does the job it was supposed to do.
• Project Management - identify tasks, organize them, follow up for completion.

Writers use tools just as developers use tools to complete their work. Grammar rules exist just as there are programming language syntax rules. A style guide is very similar to the programming and JCL standards that developers are taught. We choose a document media based on what's available, cost effective, and works best for the audience and situation, just as a systems analyst chooses the platform on which to develop a computer system. Writers even use a compiler (although a human one) when they send their work for a usability test.

Conclusions

The opportunities to learn new technologies, to learn more about different areas of our business and to learn more about effective writing practices are available to me everyday. For me, the job of technical writing has provided me with more variety, given me the opportunity to be more creative, and involves mentoring people directly and indirectly everyday.

During my three years as a technical writer, I've probably worked in the dark side as much as in the lighter side of technology. I've translated code into documentation with no SME support. I've worked as a part of a large project team, documenting changes to existing systems and new systems to support a new insurance project. Integration work has been a constant in our industry and as a technical writer, I've been involved in many of these projects. We've been able to add the most value here by making sure terms are defined and that the integrating companies understand each other's language and assumptions. I've been a scribe at meetings (hey, I'm already in the room writing my notes -- I might as well share), a project leader for documentation projects, a business analyst, a systems analyst and even made a JCL change to provide usable information. What a lot of different hats we wear and what a range of technologies we need to understand. Many times I've had to wear the different hats simultaneously on one project.

Boring, repetitive, always at the computer? No way. I'm stretched technically to understand information and systems every day. There are always new situations that enable me to use my technical skills. I'm really glad that I've seen the light and been able to contribute to the growth of the technical writing discipline at Clarica. The sky's the limit for future growth for myself and for the team. Look out world, here we come.