|
I started as a programmer many years ago and found that, while I
liked coding, I often ended up as the intermediate between the software
team and the client. I’ve always had fairly strong verbal skills and,
being Irish, have a natural predisposition to chat to people, anyway.
These
communications skills helped in the transition to tech writing,
which brings me to our first point.
1. Technical writing is about learning.
If you want to succeed in this field, you need an appetite for
learning; a real hunger to know and understand how things work. I’ve
always had a keen interest in technology and my career over the past 15
years has allowed me to satisfy my own intellectual curiosity.
Training Plan Template | Instant Download
There is
always something new to learn. It really isn’t enough to have to
document an application. At some point, you have to want to help the
reader genuinely understand how this works. To share what you’ve learnt
and hope this makes their experience of the product that little bit
better.
2. Technical writing is about organization.
Most tech writers are fastidious and like to organize bits of
information. For example, while I would never say I’m the greatest
writer in the world, my editing skills are quite good. Without really
trying, I find errors in text, layout, and typography that most people
don’t see. Distilling random bits of information into a more organized
format can brings its own reward.
3. Technical writing is about teaching.
One of the misconceptions about Technical Writing is that it’s a
solitary profession. While there are phases when I need to close the
door and write for the afternoon, an equal amount of my time is spend
talking to developers and clients (i.e. understanding the application)
and holding workshops and sessions where we discuss the results. So, the
role of a tech writer is as much about sharing information as it is
about writing.
Q - If you were going to a desert island and were only allowed to
bring DocBook, DITA, or nothing at all, what would you choose and why?
I saw Tom Hanks in Cast Away and I believe his life would have been
considerably easier if he had built his raft based on the founding
principles of DITA.
Ok, maybe not, but I
gained considerable exposure to DITA when working
for a large US technology firm and, after some initial skepticism, was
impressed with the end product.
The XML tool, in conjunction with DITA, enabled us to create chunks of
text that could be exported to different platforms quite successfully.
While there was an initial learning curve involved, it proved to be a
more flexible and pragmatic solution than writing the documents into
other tools.
Q3 During your typical documentation project, which tool or software
do you use the most, which one do you prefer using, and which one do you
wish existed?
1. Microsoft Word – most clients generate their documents in
Word, so updating and developing documents is generally in this package.
I’ve learned how to get the most from it and use macros to automate
manual tasks. I’ve recently made an aim to
use Google Docs as much as
possible and see if I can perform my word processing tasks over the web.
I’m about to buy a netbook and this will save me the expense of
getting Microsoft Office installed. So far I’ve been
impressed with
Google Docs, especially so of the round-tripping to Word.
2. Camtasia Studio – a lot of my work involves online
documentation and preparing tutorials. I try to convince (i.e. persuade)
clients to use video to accompany the print manuals and use it to
demonstrate how their products work.
We create
product demos and promotional material with Camtasia
and it really is a joy to work with. Camtasia Studio beats the
opposition hands down.
3. Speech recognition software – the amount of typing I do would
be seriously reduced if I could find reliable speech recognition
software. I’ve tried some products without success as I had to decipher
what the product showed me and gave up.
Q4 - If you had a magic wand that could change one thing about the
documentation reviewing process as you know it, what would it be?
My father worked in the auto industry for many years. His company heard
something interesting about their rival’s quality control process.
Instead of checking the cars at the end of the production cycle, they
were checked as early as possible.
At each phase in the production cycle, the car was assessed and sent
back if defects were identified. The rationale was that detecting
errors early in the cycle disallowed other defects from arising.
I mention this as I’m surprised that document reviews occur so late in
the development cycle.
If smaller, more
focused reviews occurred earlier, I believe the
product and documentation would be delivered to a higher quality and
also faster.
Do you have a fun anecdote to illustrate life without a magic wand?
A junior tech writer joined us a few years back. He liked to impress us
with the speed in which he could docs out the door. A fatal flaw in this
industry, by the way.
He used the Autocorrect function in Word for finishing his words
automatically. This makes sense to a point. Unfortunately, a
document was later retuned by a client asking who was the IT Mange
referred to in the document.
Data Model - Business Requirements Template
Somehow ‘Manager’ and ‘Mange’ were switched in the auto-correction
process. I think the moral was to slow down and check the documents by
hand. Word lacks divine abilities.
Q5 How does online collaboration work in your documentation projects?
Do you have a favorite LiveTechDocs feature?
Companies are always looking for ways to reduce costs, especially in
today’s economic climate. Recently we completed a project for a US
non-profit where we used open source and freely available tools, such as
Google Docs and Zoho.
While there was a few teething pains, we managed to write the
documents online, use the platform to review and add comments without
the overheard of using Microsoft Office applications.
For the organization in question,
online collaboration meant they could
keep their team in the field AND get the material delivered on time.
As software products become more sophisticated and development teams are
increasingly distributed across the globe, collaboration is becoming the
norm and not the exception.
Products live Skype, Google Docs and LiveTechDocs enable companies to
make these advances and distribute information secure and efficiently.
Software Development (SDLC) Templates
About the Author
Ivan Walsh teaches people
how to make money in Technical Writing.
Read how he makes over
$150,000 as a technical writer on his blog. You can
also catch him on Twitter @
ihearttechdocs
Other Technical Writing articless:
|
I'm Ivan Walsh, the person behind this site. I help people improve how they write, publish and extend their business assets.