Do good work, lose your job
Basic economics:
One well-paid employee is cheaper than two poorly paid ones
By Anonymous
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.