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.
Actually, this is one of the strengths of contracting.
Was I an employee, I might learn all aspects of a
particular "something". However, that's broad
knowledge of a very limited subject. Also, what
happens if what I'm learning about becomes obsolete.
** Well, we all specialize, whether intentionally or not -- career Oracle
DBAs tend to know the heck out of that to the exclusion of other things, car
mechanics know cars to the exclusion of other things... It's part of
focusing a career, I guess, that we make good decisions and avoid the dead
ends and soon-obsolete technologies.
I'm sure there was once a technical writer that knew
everything there was to know about constuction,
usability, design, layout, graphic look, readability,
and usability about buggy whips and whip documentation
in the late 1800's.
** Haha. Cute. :) I used to know a guy whose specialty included knowing
colonial torture methods. It was, perhaps, a limited career...
<snip a bunch of stuff>
But what if that technology has a very limited niche.
If the job or contract should end, maybe I would have
a hard time finding a replacement situation to use
that knowledge.
** Well, you're right of course -- you limit yourself on BOTH ends of the
spectrum, by having very limited technical exposure at all (I've met tech
writers writing software manuals who weren't even comfortable with their
PCs), and by having such specialized technical exposure that it can't convey
to other projects (...those who know the heck out of a specialized
application, for example, used by two people in the entire free world).
I don't want to be involved in the product development
end. I'm not a developer. I'm a technical writer. I
want to know just enough development to be a very good
technical writer.
** This, I guess, is the crux of what I'm getting at. That is true for most
of the tech writers I have interviewed in the last few years, as well --
most of them see their advancement as coming from moving into management,
not by gaining more technical expertise. Having been an Oracle DBA, a <very
bewildered> UNIX system administrator, and a bunch of other non-tech-writing
things in my life, I'm not 100% committed to limiting myself to JUST
developing the skill set surrounding tech writing -- feels too restrictive,
just like knowing only buggy whips. I *want* to learn programming
languages, databases, etc. Not because I want to do them now, but because
knowing them definitely gives me an edge in the job I hold now, and keeps me
current should I decide later that I want to do something a little different
next time.
** I'm like a darned cat, I guess -- when I'm with programmers, I want to be
a tech writer. When I feel restricted to just tech writing, suddenly I want
to be a programmer. Always on the wrong side of the door.... What I'm
looking for, then, is the perfect middle ground. To be a VERY technical
technical writer. For now. :)
** And so the short answer seems to be this: If the goal is to focus on
being a very good technical writer, and that's the area where you're
"hunkering in" with your career, then the frustrations aren't quite the
same, maybe, as what I'm experiencing.
** Massive disclaimer: I have ABSOLUTELY no belief that it's a bad decision
to be the best tech writer possible. I'm always fidgetty like this. Just
ask my father... :)
