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.
RE: Fun: 15 High-Paying Jobs for People Who Don't Like Stress
Subject:RE: Fun: 15 High-Paying Jobs for People Who Don't Like Stress From:"Janoff, Steven" <Steven -dot- Janoff -at- ga -dot- com> To:"Weissman, Jessica" <WeissmanJ -at- abacustech -dot- com>, Helen OBoyle <hoboyle -at- gmail -dot- com>, techwr-l <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Fri, 18 Apr 2014 08:44:52 -0700
Thanks, Jessica. Very instructive. :) Perhaps I'll count my blessings.
Steve
-----Original Message-----
On Thursday, April 17, 2014 9:19 AM, Weissman, Jessica wrote:
I'm not Helen, but I have done both, and done non-development jobs such as business analysis on software development efforts. Take this as one woman's opinion, from someone who has been a developer on and off for 35 years or so.
Dev has unique satisfactions, if you like programming/development at all. There's no high like the high of getting it to work. I sometimes wonder whether we somehow introduce extra bugs because fixing them is so rewarding. You also have a strong set of peers who band together with a pretty strong bond - even stronger than the editor bonds or the tech writer bond, partly because developers almost always have to work in teams despite being (mostly, and this is a stereotype) shoe-staring introverts.
BUT there are also heavy stresses. Deadlines are tight, the consequences of failing are high, and at any time YOU could be the obstacle to the team finishing. Development projects have a zillion moving parts beyond your code or module, and you don't control any of them. There are emergencies and bugs and so on.
Technical writing doesn't have that kind of high, at least for me. There are special satisfactions that come from extracting information from developers (usually after convincing the developers that you aren't an idiot and that you won't take up more of their time than absolutely necessary; this sometimes involves throwing bits of rubber brain or nerf balls over the cubicle walls at them, or providing plastic toys from Archie McPhee as bribes). And getting the info organized and the points expressed clearly is rewarding, natch.
There are few emergencies and next to no bugs - not counting the anomalies in how our tools function. The deadlines are generally reasonable (or maybe I've led a lucky professional life). In my entire career I've run into two documentation emergencies. One was a consequence of a fundamental change in deliverables at the last minute, and one was a consequence of the IT people having messed up the backups so I had to redo a lot of stuff from my unofficial backups.
When I gave up my traveling-business-analyst job I wanted something with low stress that paid well, so out of all the things I had done I chose tech writing to return to. I tame my programming itch by writing Word macros.
- Jessica
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Doc-To-Help 2014 v1 now available. SharePoint 2013 support, NetHelp enhancements, and more. Read all about it.
