TechWhirl Sponsors

About TechWhirl

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.

It’s worth going back every so often and asking some basic questions about
what we do, how we do it, and what it’s all for. We here at TechWhirl
subscribe to a deep belief in “42,” and we also think the concept of
“re-framing the community” is fascinating, challenging, and probably
somewhat controversial. At least it should make for some really cool
debates. We’ve come along way from square dances, one-room school houses
and town criers, but electronic mobility and connectedness casts both
shadows and lights into the corners of our communities, and it means big
changes in how we think about what we do.

Speaking of community, it’s always worth a few minutes to visit the email
discussion list and see who’s talking about what. And, if you have an
interest in taking a more visible or active part in TechWhirl, the Special
Writers Unit <http://techwhirl.com/about-techwhirl/swu/> is happy welcome
you into our rather laid-back but enthusiastic little community. If you
have areas of expertise that you’d like to write on, are looking for some
portfolio-building writing opportunities, or want to help out with editing,
graphics or curation, drop Connie a note (news -at- techwhirl -dot- com), and we’ll
“onboard” you and get things going.

A quick *shout out* to our Technical Writers and their discussions in our email
discussion group <http://goo.gl/YUrbb>:

- Dan Goldstein started an interesting debate on word usage,
specifically on “’Allow’ vs. ‘Require’" in design documents on a
development project. After a lot of discussion on the connotations of
each, and of “enable,” Dan’s going with Fred Ridder’s suggestion "allow but
not require" for clarity and lack of ambiguity. Word usage debates are
always entertaining, and this one is also educational.
- Kim Bieler is “Interviewing technical writers” and wants advice on
reviewing samples, identifying red flags, and doing background research on
candidates. Not really a new question in technical communications, but
it’s always interesting to see what kind recommendations come up regarding
how screen the resumes, what kinds of questions to ask, whether to ask for
samples in advance of an interview. Gauging a candidate’s work style,
approach to problem solving, grace under pressure, and basic competence
with the requirements of the job take a lot of forms, and there are plenty
of interesting tips to review no matter which side of the desk you’re on.