RE: Being an expert

[jgarison -at- ide -dot- com]

Karen Casemier opines:

>>Could I write the manual without the SQL knowledge? Yes - but 
>>I can write *more accurate and complete manuals* with it, without 
>>depending on another department 

I have been documenting products that run on databases in SQL and Oracle
(and others) for more years than I care to admit. I also freely admit that I
cannot "read" either SQL or Oracle. I have been employed without
interruption since 1974 as a technical communicator, so obviously I am
employable without this skill.

I guess it all depends on what you are writing about the SQL/Oracle/DB2. I
document an application for end users. Most do not know nor do they
particularly care what database is behind the application. They have no need
for insight into that as it would only confuse them.

The ONLY place where detailed (or even superfluous) knowledge of the
database innards is important is when writing the installation guide which
does instruct the administrator users to run certain scripts to update the
database from one release to another. I have a writer on my staff who is
very competent at doing so, however she also doesn't have any great detailed
knowledge of the database itself.

HOWEVER - we are not a database company. I would not be Oracle or Microsoft
or IBM's first choice for the doc manager for the database itself. Someone
who knew database design and architecture and care and feeding protocols
would no doubt be a better choice.

I am also not a technological neophyte. I can come up to speed VERY quickly
on whatever technology I am required to master. My background and experience
prove it.

So ... What does this prove? That there is room for just about every level
of skill - if you can match your level of interest and knowledge with the
customer's needs, you can be employable.

The thing about today's job market that seems to be getting everyone into a
tizzy is the fact that companies have a LOT more people to choose from than
they did a year or two ago. However, if I were hiring today, I would NOT
choose someone with the deep experience in databases. I would choose someone
with broad experience and superb writing skills. More important that
database knowledge to me is the core competency knowledge about our REAL
subject matter: business process and product management. And no, that does
not necessarily translate into hiring someone who's used MS Project for
years and can make it stand on its head. It means someone who sees the big
picture, can understand how things work in context, and can learn the
details and understand their relevance.

And I agree, Karen - this IS the longest running thread. And I'm convinced
that those people with deep experience in some areas will continue to
maintain that that is the secret of their success, and those with breadth of
experience will claim it as their savior. Both are right. And I still
maintain that the more you know, the better off you are (even if it's
possible not to derive that from my previous statements).

Now - back to work!

John

John Garison
Documentation Manager
IDe, Concord, MA
978-402-2907
jgarison -at- ide -dot- com



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Save up to 50% with RoboHelp Deluxe. Get 2 great products for 1 low price!
You'll get RoboHelp Office PLUS RoboDemo, the software demonstration tool
that everyone's been talking about. Check it out and save!
http://www.ehelp.com/techwr-l

TECHWR-L is supported by ads and sponsorships...and donations.
You can help maintain the TECHWR-L community with donations
at http://www.raycomm.com/techwhirl/abouttechwhirl/donate.html

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