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: Handling developers, "the zone" and other myths
Subject:Re: Handling developers, "the zone" and other myths From:Emily Berk <emily -at- armadillosoft -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Sun, 02 Jun 2002 17:23:01 -0700
At 05:35 PM 6/1/02 -0300, Bruce Byfield wrote:
>...However, I do question:
>- That programmers have any more need for lack of interruption than anyone else.
There are certain jobs that require more concentrated attention than others. When I am drawing an illustration using Visio or CorelPaint, I often listen to talk radio and can often carry on a conversation.
When I am writing code, I can't. When I am writing about a complicated technical procedure, I can't either. When I'm editing video, I sometimes like listening to talk radio. When I'm editing audio, I can't do anything else.
Do you remember in the movie Diva, there's the guy who's always walking around with a walkman stuck in his ear? Guess being a murderer didn't require his undivided attention, huh?
>...However, I do question: - That it's realistic to expect not to be interrupted in the typical office. Learning to work around interruptions is simply a basic necessity.
Once again, I'll ask: Would you want YOUR heart surgeon to be learning to work around interruptions while operating on YOU, or would you prefer that the operating theatre be set up so that no interruptions occurred until after the operation(s) were over?
Is it "attitude" to want to be able to concentrate, or, in certain situations, isn't common sense?
Isn't it the managers' job to make sure that the critical work gets done, which to me means setting up the workplace so that the work environment provides a way for staff to concentrate without interruption? (Admittedly, communication with tech writers is part of the critical work, but IMO it's usually not the bulk of a programmers' work.)
>No doubt my attitude is colored by having been a manager from time to time. A lot of the talk about "the zone" is simply copping an attitude - and that's something that can disrupt an entire office, not just a single individual.
My response is colored by:
1. My recent escape (or, was I pushed???) from a job where I had started with the agreement that I'd take less pay on condition that I not have to work on-site more than one day per week;
2. My twenty years' experience as a programmer;
3. My about seven years' experience as a technical writer.
At the job I recently left, there were two programmers who did the bulk of the heavy lifting (coding) and quite a few who did other things. All of our desks were arrayed in rows of 6 about 2 feet apart, without any partitions or any other barriers to sound or vision, in a large open room, in which also sat the entire engineering staff, including our exceptionally chatty VP of Engineering who never did anything but talk, loudly, far as I could tell. Both high-achieving programmers and I were constantly emailing updates to each other at like 1 or 2 in the morning, which was the time when we had left the office, gotten our work done at home where we could think straight and were ready to share.
It was when said VP of Engineering informed me that my presence was required five days a week, 9 hours a day in my seat in the on-site office (and after a 5-month stint at a desk without a keyboard drawer or mouse pad while I was awaiting surgery for an agonizing shoulder condition) that I decided that I did not fit on her team.
It has been my experience as a programmer that a good tech writer could meet with me for half an hour or so (max) per topic to get an overview of what I thought was necessary, use the resources I had prepared, write something up for me to review and then accept comments, possibly not in person.
As a programmer and as a tech writer I also was happy to set "office hours", at specified times during the week when anyone could walk in to talk with me.
However, there really were times when I could not work productively while coping with interruptions and I'm pretty sure I made those times clear to all my co-workers (and not just tech writers by the way. An interruption is an interruption, doesn't matter who's doing the interrupting.)
That's how I prefer to work as a writer too. I like to meet the SME once for an overview, regularly attend engineering meetings for context, write the docs without much intervention, email questions, and iterate via email or paper for a while, then maybe meet just before writing the final draft.
The managerial guff about how for the good of the team our behinds need to be in the chairs, and/or we have to be in meetings all the time, and/or that there has to be an on-going and perpetual meeting in the engineering space that everyone must attend so that everyone who is supposed to be in the loop is in the loop -- well, I think that's great for anyone who has no code to write and no documentation to write either. My theory about my ex-do-nothing VP was that she felt that if she was in the office 8 - 5 M-F, no one could accuse her of not working, even if that was what she was (not) doing. Since she lacked the ability to judge whether or not the rest of us were working, she felt the need to have us where she could see us "working".
Well, I guess I'm just infected with that egotistical programmer attitude thing.
--Emily
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Emily Berk ~
~ On the web at www.armadillosoft.com *** Armadillo Associates, Inc. ~
~ Internet and non-internet application development, project ~
~ management, developer relations and extremely-technical technical ~
~ documentation that developers find useful. ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
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
---
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.