TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Geoff Hart wrote: <snip>
That's sad to hear, because it means that companies are still foolishly insisting that one person can do the work of two people. This isn't an expertise issue imho; it's a simple matter of time. This only makes sense when you don't have enough work to employ a full-time programmer or a full-time writer. In that situation, having dual expertise is a very good solution. But when you have a sustained 80 hours worth of work, your programmer-writer ends up either burning out, or accomplishing only half of both jobs.</snip>
Not sad at all. In fact, the opposite; as a "writer/programmer" I get a higher rate because of my programming skills, while rarely--if ever--being asked to actually write code. The important thing is that I understand the code, not that I write it. Specifically, being able to look at a class, function, subroutine, or test case and understand what it is supposed to do is a major advantage. It also cuts down considerably on the time needed to arrive at that understanding by interpreting the comments of a harried programmer who may or may not be willing (or able) to clearly explain what the code does.
In the cases that I have been tasked to write code, it has primarily been as a backup for a team member who is unavailable for one reason or another. In that case, I function as a "temp" and that normally lasts only a day or two, until the "regular" programmer returns. The increased pay is for what I am capable of doing (when necessary), rather than what I actually do.
In the instances when the title has been "programmer/writer," (rather than "writer/programmer"), coding is my primary job function, and the "writing" part is primarily descriptive comments in the code, using JavaDocs or something similar. That is, rather than the XP tendency to avoid writing comments ("documentation") entirely during the development process, "programmer/writers" are expected to document their code competently enough that another programmer can look at their work and understand almost instantly what they were doing, why they were doing it, and what needs to be done next.
I have (perhaps fortunately) never been required to do the work of two people, or to work longer hours without compensation (as a "salaried" employee exempt from overtime constraints), or anything remotely like it. Programming skill puts me on an equal footing with the developers, who are able to "explain" their code one programmer to another, rather than as a programmer explaining his or her code to a "civilian." I am in much the same position in dealing with executives, courtesy of three years of graduate school majoring in management. Specifically, I don't need an interpreter to understand business, in the same way that I don't need an interpreter to understand row locking code in a database application.
Some years ago, Inkos dumped $25 million that it had invested in a pilot program to implement SAP software because their personnel lacked the skill to use (or, apparently, even to understand) the software without an endless parade of $300 an hour ERP consultants holding their hands and doing most of the work. For such companies, an additional $30 to $50 an hour for someone with specialized expertise in the field is a trivial expense. I like that.
ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals. http://www.doctohelp.com
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-