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.
Subject:Re: How to fend off a tech writer From:puffwriter -at- darksleep -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Sun, 12 May 2002 02:46:48 -0400
On Fri, May 10, 2002 at 03:07:33PM -0300, Bruce Byfield wrote:
> > I'm not sure anyone said the work was _better_ when in "the zone"
> > (but it's always possible that I missed something).
>
> No, but the implication is always that "the zone" is important, and
> not to be lightly interrupted. I assume that, in terms of writing or
> coding that importance means the work is supposed to be better or
> faster.
Faster, generally, although, depending on the development
methodology, faster can mean better (typically in heavy-refactoring
environments, where the focus is on a process of transformative
refinement).
> > I do believe, though, that people in general are _more productive_
> > when they can concentrate on one task for an uninterrupted period.
> I'm not altogether convinced of this idea. True, I'm sometimes annoyed
> when my concentration is interrupted. However, uninterrupted periods are
> so rare or so short on the job that most of us have to learn to be
> productive despite interruptions.
Hm, well, you have no evidence for this, either.
> If we wait for the uninterrupted space that we'd like, we'd never get
> anything done.
The fact is that for jobs involving a lot of contextual information
that you have to keep in your head, uninterrupted periods of concentration
are important. The greater the amount of context, the more important
"flow" is. Saying "too bad, learn to be productive in spite of it"
is cute, but pointless.
> Besides, a lot of work on the job is collaborative. Whether they like
> the fact or not, part of a programmer's job is to collaborate with the
> writers. If they don't know that duty is in their job description, they
> should.
Developers collaborate all the time; "cowboy programmers" who don't
want to communicate are a problem for developers as well as for writers.
Collaborating with the writers isn't a question of collaboration, it's a
question of collaboration with writers. As (I believe) John Posada said,
look for the common factor :-).
> For these reasons, the hacker claim of the right to uninterrupted space
> can be unrealistic and uncooperative. It suggests that, because they
> program, they deserve a privilege that other people would like, but
> can't have - and I don't accept that. Interruptions and collaboration
> are part of work, and nobody, even managers, can be escape the fact.
Well, to be bluntly _realistic_ about it, the economics say otherwise.
If it were so unrealistic, programmers who are productive while being
interrupted all the time would be easy to find and the ones who aren't
would be out of a job. Reality says otherwise; programmer productivity is
greatly affected by interruptions; this fact is sufficiently universal that
employers have decided to put up with it. Having done both - written
database manuals and developed complex multi-user networked applications -
I can say for a cold, hard fact that it's harder for me to maintain flow
while programming than while writing.
Maybe it has something to do with the level of complexity, ambiguity
and variability in programming. I'm fairly certain it has a lot to do with
serious programming requiring a right-brain geometry/spacial mind-state
while serious writing requires a left-brain analytic/linguistic mind-state.
Maintaining the former is a lot harder for me than the latter. Most of the
programmers I know who are better at the former are also the classic
absent-minded math professor types. Frankly, after a day of deep
programming, so am I. I find it hard to string words together, a state I
normally need the aid of alcohol to achieve.
> Don't get me wrong - on the job, I try not to interrupt anyone who's
> concentrating, and I try to communicate using a medium that's acceptable
> to both the programmers and me. That's both courteous and practical. Nor
> do I deny that coders have a job that I would find difficult. But the
> reverse is also true, and I'm not inclined to give anyone special
> treatment simply because doing so fits into their personal mythology.
Coming from a member of a profession that spends a lot of time talking
about their own personal mythology - writing is valuable and difficult, you
just don't understand! - that comment is fairly ironic.
Most of the competent programmers I've known - both while I was
writing for a living and since I've been programming for a living -
recognize and respect the writer's domain. Frankly, the abilities I
developed as a writer rank among my most useful skills as a programmer;
most programmers aren't able to tackle a nebulous, unknown situation and
bring order out of chaos.
Steven J. Owens
puff -at- darksleep -dot- com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Free copy of ARTS PDF Tools when you register for the PDF
Conference by May 15. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com
Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.