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 21:25:37 -0700


At 07:07 PM 6/2/02 -0300, Bruce Byfield wrote:

>Or, on a more relevant level, I wouldn't want a surgeon who concentrated on his or her part of the operation while ignoring the nurses, the anesthesiologist, and any other experts that were involved. Often, what programmers describe as "interruptions" are actually necessary interactions for the end goal.

Have you ever watched an operation proceed? The surgeon DOES mostly ignore the others who are also working in the ER, concentrating mostly on the patient and interacting with the other professionals in the room only when absolutely necessary. What's important during the surgery is what's happening to the PATIENT and what the PATIENT's body is doing, not what the other people in the ER need or want.

>However, I didn't bother responding to this analogy last time because, while it's dramatic, it's not relevant. Coding and tech-writing are not immediately life-threatening. Yes, mistakes may be life-threatening in the future, but there are reviews, bug checks, and QA that should catch mistakes of that magnitude.

But the point I am making is that in the case of a developer, what's important is the software. Until the software actually is mostly done, the needs/wants of QA, documentation, marketing, etc. feel very secondary to me when I'm being a developer because I know that if there is no software, then there's no reason for documentation, QA, etc. If I perceive a priority one bug in the software, then, it's the health of the software I care about, not the needs of anyone else.

And to ensure the health of that software, when I am trying to solve a sticky, important problem, I really do need to concentrate.

It's like -- let's say you were working out a complicated equation. You're just about to perform the 42nd of 50 steps and your manager walks into your office, turns off your computer and tells you that you have to explain all 50 of the steps to the tech writer immediately. There are a number of problems with this:

1. You might not remember exactly where in the 42nd step you were interrupted, so you therefore have to repeat all 42 of them.

2. You aren't sure the 42 - 50th steps are going to work so you're not ready to "explain" them to the tech writer.

3. You haven't checked the work performed in the first 41 steps so you're not sure exactly what you did or whether that was the best way to do it.

Yes, a bomb might drop and interrupt your work, but that's a circumstance your manager could not plan for.

But as for explaining stuff to the tech writer -- why can't the tech writer call you, or better yet send you email and set up a time that's convenient for both of you? Or, couldn't the manager schedule this in advance, rather than just walk into your office and demand immediate answers?

Haven't any of you read Virginia Woolf's diaries? How infuriated she'd become if anyone disturbed her when she was trying to write her novels? How she'd budget her mornings to ensure she had a swath of time to write undisturbed? It wasn't an ATTITUDE. It was the environment she needed to get her work done. And, no, what she was doing wasn't heart surgery. She was just writing fiction. Just fiction.

And we are just writing technical documentation. It's just technical documentation. And, in my opinion, if the technical documentation isn't perfect, well, we can fix that in the release notes. But if the software doesn't compile or if it doesn't do what it's supposed to do, it just doesn't matter whether the tech writer got answered promptly enough to feel valued.

And, yes, in many workplaces, I have absolutely not been able to obtain an environment conducive to productive work. But I really think a pleasant, productive working environment is something well worth striving for.

I believe in The Zone, Bruce. I've been there; I KNOW it's real. And I know that EVERYONE (even tech writers) needs to be, and deserves to be undisturbed in, The Zone sometimes.

--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.


Follow-Ups:

References:
Re: Handling developers, "the zone" and other myths: From: Emily Berk
Re: Handling developers, "the zone" and other myths: From: Emily Berk
Re: Handling developers, "the zone" and other myths: From: Bruce Byfield

Previous by Author: Re: Handling developers, "the zone" and other myths
Next by Author: Re: When users want jargon
Previous by Thread: Re: Handling developers, "the zone" and other myths
Next by Thread: Re: Handling developers, "the zone" and other myths


What this post helpful? Share it with friends and colleagues:


Sponsored Ads