Friday, July 8, 2011

The 48 Hour Power Plant Job

I write training modules for power plants around the country – from home.  I am just completing my first work order, which consists of six modules with six documents each (system description, system operating procedure, job performance measure, facilitator’s guide, system questions, and in-process control sheet) for Unit 8 of the El Paso Electric Company Rio Grande Power Plant.  I get paid only when a module is finished so the more efficiently I work, the more profitable the job.

For this first assignment, I planned a two day visit to the plant.  Two days to get all the photographs and documents I would need to complete the entire assignment.  I have to pay all my own expenses, including travel and hotels, so two days seemed like the minimum I could get away with to get everything I needed with the least possible expense.  I would have to fly to El Paso the night before so I could have a full first day at the plant, then fly out late the next afternoon.

I took a Canon PowerShot SX130IS digital camera.  That model is well suited for power plant work.  It has a very good zoom lens, can be operated one-handed (for those times you need to hang onto a railing or ladder with the other), and it uses AA batteries.  AA batteries are good because they are cheap, I can buy them anywhere, and it is easy to carry enough for a whole day of shooting.  I do not want to be out in the middle of nowhere with a fancy lithium battery that could run out of juice on you and require half a day to recharge.

With an eight gigabyte memory card, I can take all the photos I want without running out of space.  For this job, I took over 750 high-resolution photographs.

I also took my MacBook Pro, a hard hat and steel-toed boots.

The first day I had someone from the plant give me a tour of the whole unit I was working on.  We covered every piece of equipment from the ground to the roof, climbing on top of the vertical deaerator, hiking out to the cooling towers, and getting close and personal with the boiler furnace.  El Paso was over 100 degrees that day, but after examining the burners, it felt like a cool breeze when we stepped outside into the noon sunshine.  I didn’t take any photos the first day, just took it all in.

That afternoon I spent with a copier, making copies of all the engineering drawings and manuals I could get my hands on.

The second day, I went into the plant by myself, retracing the route my guide and I took the day before.  I photographed everything I could possibly need.  In the weeks since then, I have gone through those photos dozens of times and it is amazing how many things I got shots of, more or less by accident, that ended up saving me later.

I spent the whole morning in the unit going through some areas several times, always looking for new details.  After lunch, I walked back out, reshot some areas, got shots in the control room, and made sure I had photos of all the remote control panels and data plates I could find.

By the time I was ready to fly back home, I had my laptop case crammed with drawings and documents.  My previous power plant experience was on site.  I could go out into the plant anytime I wanted for the whole time I worked on the project.  Having to fit all the research into two days was a valuable exercise in the discipline and organization.  I prefer having free access to the equipment I am writing about, but this has been a great learning experience.  What I learned on this assignment will help me be better prepared for the next one.

Saturday, February 26, 2011

Be Prepared, Be Flexible, and You Will Be Employable

Working as a contractor, you need to have a wide range of skills. Every company and every job situation presents new challenges and the more prepared you are to meet them, the more valuable you will be as a contractor.

Despite what many beginning technical writers seem to believe, there are no established formats or guidelines that have been adapted by all companies for technical writing. My experience is that every company has its own set of requirements for technical publications. Some are informal and some are set out in specifications hundreds of pages long, but all are different. Even in military technical publications, which all follow the same specifications, companies and even technical publications departments within the same company, will apply their own interpretations to the specifications.

You need to be familiar with a wide variety of software. While Word is the most common software used for writing, different companies use different versions. You may also find companies that want writers who have experience with FrameMaker, InDesign, Open Office Writer, or Word Perfect. They may also want you to be able to handle spreadsheets, databases, presentation software, and software to create online training modules.

It has come in handy for me to have some programming background and experience with relational databases. I got this building web sites as a hobby. Knowing how to work with HTML, XML, SQL, and other web scripting languages helps when you are writing about software.

In my current contract, I am not doing any actual technical writing. I was contracted by the agency as a technical writer, but the client (a mortgage company) calls me a “data consultant”. In the position, I convert documents templates from PowerBuilder database to custom XML templates for CaseAware (another database system). This involves writing queries for MySQL, translating the PowerBuilder logic to work in CaseAware, and testing the translated templates. I also find myself leading a team of writers who I need to mentor because they don’t have the experience with SQL, XML, and databases that I do.

Every bit of experience and education you can pick up will serve you sooner or later. In this job you cannot afford to specialize. You need to be an expert in every industry in which you may be hired. For that you need to constantly be learning and developing skills. Follow your curiosity wherever it may lead you and you just may end up with a job or jobs you will love.

Tuesday, November 16, 2010

Evolution: 1983-1990

I worked those seven years at Martin Marietta in Denver. We used Wang word processors. PC's were still more overpriced toys than serious office machines in 1983. The Wang system consisted of terminals connected to a mainframe computer. We had up to five writers cramped in a small room with old government issue desks pushed together. The writers shared one word processing terminal for each room, so we did a lot of writing longhand.

Illustrations were generated from a separate department using AutoCad machines. In those days, the graphic artist sat in what looked a chair used for checkups in an optometrist’s office with lots of mechanical controls within reach in all directions and big screen attached to the front. The room was kept dark and the effect was like sitting in a space capsule. While a simple drawing may not take long, a complex one could take a week or more.

The writers would mock up illustrations to submit to the AutoCad department. We learned before long that the more accurate and detailed the mock-up, the quicker the turnaround and fewer revision required for the finished drawing. This forced us to develop skills designing isometric drawings, callout placement, and designing illustration that would fit on the page economically, making the best use of space to enhance rather than displace text.

Having to put this much work into the drawings made us better writers. We had to pay such close attention to the details of how the mechanisms worked that writing about them came naturally.

Saturday, October 23, 2010

Evolution: Transition 1983

By 1983 I had been at FMC in San Jose three years. In the early 80's if you had been in a job over two years in Silicone Valley, you were considered stagnant. During those years, young workers made a second career of job hopping. I had come to all this from the outside (California) world, and didn't buy into the job hopping but, pushed on by peer pressure, in November I went to a job fair. Several fellow writers from FMC had gone to the fair earlier and were recruited by Martin Marietta in Denver. They convinced me to go to the fair and I agreed to an all expense paid interview in Denver.

I had never been to Colorado. I had envisioned Wyoming as a place to escape the fast pace of Silicone Valley, but Colorado would be close enough. California has a reputation for being laid back, but the truth is there it takes a lot of energy to maintain that image. To me is was more like a buzzing hive, and I was ready to move on.

When I interviewed in Denver, Martin Marietta was hiring droves of writers, editors and logistic support analysts to support the Peacekeeper (MX) missile project. They offered me more money than I made in California and full relocation. I fell in love with Denver at first sight, and signed on. The only hitch was that I had to move to Denver and start work within a couple weeks, December 5 at the latest.

Martin Marietta arranged for a mover, so I packed everything else in my 1978 Datsun pickup and Thanksgiving weekend, to avoid bad weather north, I drove from San Jose to Bakersfield and across the desert to Las Vegas. I spent the night in Vegas then left before dawn traveling I-40 through Flagstaff to Albuquerque. I stayed overnight, then took I-25 to Denver. It was -25 degrees in Denver my first week there.

During the interview process in November, I had a one-on-one with the director of technical publications. He told me that when I came to work for Martin Marietta I would be joining a family and I would be taken care of for the rest of my career. He had been there 35 years, since he came out of college. Two months after I moved to Denver, he was laid off. He was at the end of the last generation where you could confidently believe in a safe job for life at a corporation. My generation watched that generation's beliefs crushed and had to learn to adapt to the new culture. That is evolution.

Thursday, October 14, 2010

Evolution: 1980-1983

I came to technical writing through Kelly Temporary Services in 1980. I was hired as a temporary proofreader at FMC Corporation in San Jose, California. FMC started in 1883 when John Bean invented an innovative insecticide spray pump. In San Jose in the early 1980's we built tracked military vehicles including the LTV-7 landing craft, the M113 armored personnel carrier, and the Bradley Fighting Vehicle, all of which I worked on.

I worked a few months as a proofreader before being taken on as a direct hire as a technical editor. I worked in that position for several more months before moving up to technical writer.

At that time the state of the art equipment for the technical writer was the IBM Selectric typewriter. Typesetting was done by a special department (which I worked in briefly) that manually typed the information into a mainframe word processing program. This turned out to be useful years later when I was learning HTML. In that old program you had to enter carriage returns, tabs, etc. as tags just as in HTML. Later I worked with a state-of-the-art Kodak typesetting system that printed publication-quality pages on photographic paper at an unimaginable cost-per-page.

During that period there were no classes in technical writing, much less college degrees. Companies were looking for journalism majors, which I wasn't. I got in by going through the temping back door, which is still a nice inroad if you don't have the "right" degree.

When I was working at FMC the entire technical writing department, below middle management, was under 30 years old. Anyone older either moved into management or on to another job. In Silicone Valley at that time, if you stayed more than two years at a job you were stagnant. I didn't buy into that environment and moved on to Denver and Martin Marietta in December 1983.

When I left, an Apple II personal computer cost $10,000 and PC's were in the future.

Monday, October 4, 2010

Assumptions

Assumptions are tricky. You have to take into consideration the skill level of the reader performing a task so you don't waste their on things they should already know. You also need to take care not to assume they know acronyms and terminology that is common within the company or industry, but not outside the company.

If you are documenting professional design software, you should be able to assume the reader knows how to open a Windows or Mac program and what a cursor is. You cannot assume they will be able to infer how layers work in Photoshop or how the filters work, unless that training is a prerequisite to your document.

In the early 1990's there was a trend for companies to do away with professional technical writers in favor of engineers or business analysts writing the documentation. The problem with this was those people were too close to their products. Have you ever tried following the user guide for a stereo amplifier that is filled unfamiliar jargon and missing steps?

A procedure needs to describe and illustrate every step that needs to be performed to satisfy the purpose and scope of the task. If the reader is required to remove a part, the steps need to tell them where the part is, how to remove whatever is necessary to allow it to be removed, and how to remove it. If there are any acronyms or unusual terms, define them. You need to mention all mounting hardware that has to be removed and the quantity to prevent the reader from missing any and possibly damaging the part. In other words, you need to make it as difficult as possible to the reader to make a mistake. That doesn't mean you need to tell the reader which direction to turn the screws, but you do need to point out any special tools needed and hazards that may be encountered.

Saturday, October 2, 2010

Consistency

Technical writing is not creative writing. Do not try to find different ways of saying the same thing in the same document. The goal in technical writing is to communicate everything the reader needs to know to perform a task with the least possible opportunity for the reader to misunderstand.

Consistency can seem boring, but if you use the simplest and most clear language possible, all readers should interpret the instructions correctly. Adding unnecessary adjectives, articles, adverbs, and other embellishments just gives the reader opportunities to confuse the matter.

Do not change the name of an item after it has been mentioned once. This should be a no brainer, but I've seen manufacturer manuals where there same part was called by two or even three different names. I've seen manuals where a part was called one thing in text and another in the illustration. The situation is worse when there are several manuals for a piece of equipment that were apparently written by different departments.

The answer to this problem when I was writing military manuals was having a staff of technical editors who ensured all documents were consistent in format and wording and compliant with military specifications. The problem in civilian companies I've found is that the technical publications staff usually consists of a couple writers at most and the editing consists of reviews performed by subject matter experts on the sections that concern them. Seldom does anyone look at the project as a whole. So, it is up to the writers to edit their own work, and no matter how closely they proof they will likely overlook some mistakes they made in the first place.