by Steven J. Owens (unless otherwise attributed)
Andrew Plato writes:
>> "It's difficult to rank technical writers along with Engineers,
>> because people who go into tech writing and QA are usually people
>> who tried to be Engineers and failed.
>
>Your boss is correct in some regards. Many writers are writers
>because they aspire no further. Half the writers I meet are writers
>only because they want to pay the bills and cannot get a job doing
>anything else. This might not be the case for yourself, but it is for
>a lot of writers out there (in my experience).
I really have to take issue with this.
Before I get into details, I should caveat the following with the facts that a) I am one of the more technical folks, and b) in fact I also left tech writing for consulting (doing Perl/Java/RDBMS dev for web sites).
Also, in most of the following, I base my comments on experience in the software development world. I will caveat that caveat with the fact that most of what I've heard from other writers backs up my statements, and in any event I have heard statistics that place the distribution of technical writing work at something like 50% in the computer/software industry.
I know the common stereotype of a technical writer is that of a failed engineer or programmer who becomes a writer because they can't hack the serious work.
I also know why this arises - because of the common management misfocus on hiring knowledge domain experts to write books instead of hiring writers. This happens because it's easier to figure out whether somebody knows about or is experienced in a knowledge domain than to figure out if they're a good technical writer. The fact that writing ability has a lot more to do with whether the book is readable or not than knowledge of the topic kind of slips by management. (You can get knowledge, and in fact being good at getting knowledge - interviewing, taking notes, organizing the mess into a coherent whole - is a critical skill for a technical writer, but it's pretty hard to develop writing ability within the scope of such a project).
This leads to subsequent confusion between cause and effect, and hence we get the stereotype.
In my experience, I know far more people who, like myself, are failed technical writers turned programmer (or engineer or whatever) than vice versa. This happens quite simply because a) leaving aside the skill and talent issues, writing is a lot more difficult in everyday terms - in sheer obnoxiousness of the job situation - than being a programmer, and b) writing doesn't pay nearly as much as programming, in either cash or respect.
I have no doubt some programmer is getting ready to jump down my throat for comment (a). So I should say up front that I believe programming is demanding and requires talent, and in fact programmers have difficult jobs. However, to clarify "writing is a lot more difficult", I'm talking about sheer day-to-day obstacles to writing. Let's look at a few:
The ratio of writers to projects is almost always the opposite of the ratio of engineers to projects. Typical industry ratio is one writer to every ten engineers. On a software dev project you'll usually see a team of engineers and one writer - who also has responsibilities to other projects.
Writers are also largely self-managing; they have to be, because they so seldom work in a team-writing situation (team situations can be a lot of fun, when it works right). Although the odds are not great for a programmer to be managed by somebody with a technology background (let alone a programming background), what are the odds for the writer to be managed by somebody with a writing background?
Writers also have to contend with the fundamental contradiction that they always have to do the most to adapt to changes, while having the least influence over whether that change will happen or not. And, if things come to a showdown, regardless of who's right, who do you think will lose - the writer or the engineer who gets paid twice as much?
If you define the interface of a product as the part that the user directly interacts with, then that includes the documentation (both the online help and the printed docs). Hence writers are responsible for a large chunk of the interface. Yet they have the most constraints in developing it. They are required, by the role most employers force them into, to react to change, not to initiate it.
In the ideal world, the writer works with a stable product that is undergoing final Q&A. In the real world writers work with barely-usable or unusable products 99% of the time - and again, this is not the programmers' fault, it's a result of a variety of office-political, market, and economic pressures. But the net effect on the writer is still the same.
Writers typically have more severe deadlines than engineers - whatever the engineers' deadline is, only three to six weeks earlier. Document printing usually requires at least three weeks lead time and more often three to six weeks. Management wants that product shipped out the door as soon as possible, and although they'll scream bloody murder if the docs aren't done, they don't consider the docs as part of the "as soon as possible" equation. (No doubt in part this goes back to both the ratio and the relative pay scale).
It's no wonder so many people get fed up with it and leave for more lucrative jobs.