by Anonymous

Do good work, lose your job

analysis
Mar 21, 20063 mins

Basic economics: One well-paid employee is cheaper than two poorly paid ones

I’m a database programmer by trade, but I can write too. Several years ago, a large hardware vendor offered me a handsome salary to oversee documentation for the company’s embedded utilities. I decided if they had the money, I had the time.

There were changes to the docs almost every week, which was fine; but they needed to be delivered in three different formats (print, browser-based online help screens, and 80-column terminal text), which wasn’t. The previous writer had been dropping text changes into multiple files, and falling behind hour by hour. The terminal files had her counting characters manually and inserting line breaks before she ducked out the door.

Given my engineering background, I decided to design a system that would deliver repeatable, automated output with minimum hassle. No text would need to be entered more than once.

I used a desktop publishing app for content entry.  Next, I designed a text converter to parse the existing files. Configuring for PDF (the print requirement) was easy. Coding for the browser wasn’t too bad. Transforming WYSIWYG pages with complex tables into well-formed, column-delimited plain text was tricky — and something I’m still proud of.

The hours invested in setup were murder. But once the system was running, you could drop new text into the source files at 4:45 p.m., click a couple of buttons to generate all needed output, post it, and hit the street in time for an early movie.

Still, all good things come to an end. I’d been working hard for several years to make the job look easy. So when another hardware maker bought the company, my new boss figured I was being overpaid and gave me a choice between walking out and accepting an insulting pay cut. I walked.

Shortly before my last day, a project manager showed up with half an hour to spare so I could “show him what I do.” I did my best to explain my automated, multiformat build process: how to edit source files, run my build tools, and post the output. There was no time to discuss technical subtleties that could cripple everything: manual vs. styled tagging, vector graphics vs. browser-compatible images, valid XML, the effects of different DPI settings on PDF output, you name it. I considered advising him to port everything back to Word for simplicity’s sake, but ultimately decided to let him twist in the wind.

The first release after my departure dropped the browser-based help screens. The next release shipped without plain text. All you got was a PDF with dodgy formatting. I heard that incoming support calls went through the roof.

In recent months, all three formats have returned. I’m told that most of the documentation work has been outsourced to an offshore tech writer. Of course, the company had to hire a local developer whose only job is handing off snippets of documentation to India, along with precise instructions on where to insert each piece of text in which format files. I’m sure the company pays more for their overseas typist and engineer baby sitter than they did for me, and they get only a fraction of the output.

If you think you can clinch job security with innovation and high productivity, you’d better think again. You may be doing a job that someone in the skybox couldn’t care less about.