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.
> Development should charge back the SME salary costs to the
> Documentation department every time we ask a question...
No. We should be part of the development department. And not just on paper,
but in practice.
"Mr. Developer, tear down that wall!"
> Yes, we must learn, but that learning has a cost attached to it.
Find out how new developers are integrated into the development department.
TWs should be considered peer developers, and should be integrated the same
way. And the cost should be accounted for the same way.
{Note though - and some on this list might find this unsettling - If you
want to consider your TWs as peer developers, you *might* need different
TWs. )
Do developers charge each other for every conversation they have with each
other? No? why not? Maybe because they consider themselves part of a team?
A lot of junior developers are brought on board with a hell of a lot less
experience than some of us TWs have. What happens when these newbie
developers have questions? When a new developer wants to know how the
application works, how do they tell him? Do they give him full access to the
source code? Then they should give the TW full access to the source code.
When a new developer has questions about the code implementation, do they
have an experienced developer answer his questions in a natural, collegial
way? If they do, then that's how they should work with TWs.
Knowledge of a technology is widely available, and everybody is responsible
for learning it themselves. You can just go read the documentation. But
knowledge of a particular implementation is site-specific. True, nobody
should have to take time to explain to a new TW how Java works, for example.
But it's perfectly legitimate for a programmer or tech manager to take the
time to explain the business logic, architecture, and infrastructure of
their particular implementation. It's not like you can just go read the docs
for their product - you were hired to *write* the docs.
And... Don't assume the SMEs are always developers. When I'm doing something
new I spend most of my time with *business* SMEs, not developer SMEs. I
usually figure out most of the developer stuff on my own. And if there is
some techie stuff I need to ask about, I expect an answer and not a bill.
NEED TO PUBLISH YOUR FRAMEMAKER CONTENT ONLINE?
?Mustang? (code name) is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to Web, intranets, and online Help.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! See a live demo that
will take your breath away: http://www.ehelp.com/techwr-l3
---
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.
