Hi Felicity,

Here's one view, based my day job as an engineer (who likes writing so gets dragged into it), with a wife who is a scientific writer / editor and a sister who used to run a technical marketing agency:

To be honest most technical writing I come across is just done in Word! The trick is in the writing style rather than the software.

If you get into the design side of technical publications then it's a bit different, and you may then be using e.g. Quark or the Adobe suite, but often these days there will be a separate designer who will take your words and put them into the layout. That said, it probably is useful getting the hang of one of the basic publishing tools, e.g. MS Publisher, to see how this works and for working with smaller organisations. Don't spend a fortune (or preferably anything) on it though - you may never use it professionally. We haven't bothered updating my wife's business subscription to Adobe for years because it just never gets used now, she does everything in Word.

You may find that academics recommend LaTeX. Personally I have never seen this used outside academia. It's useful if you want to write something with lots of mathematical formula in, otherwise it's (imo) pretty awful.

Here's some other thoughts on entry to technical writing:

Main thing is to build a portfolio, you may need to take on some very small jobs for local companies first (I hate to say it, but potentially at low / zero cost) to get some samples of work to be able to win bigger pieces of work (if you want to go freelance) or to get a position (if you want to go permanent).

Show that you can listen, absorb information, and then turn it into something readable by the target readership - which may be engineers or the general public depending on the assignment. Sounds obvious, but there is plenty of technical writing that is pitched at the wrong level - too simple or too full of jargon. Having a portfolio of different types of writing is really useful. Just as examples: perhaps an installation manual aimed at engineers, a technical report aimed at the local council, a user guide aimed at the home user.

Show that you will go back to whoever gave you the original information and work with them to correct any misunderstandings you may have made in the text. Again, should be obvious, but it is scary how often technical writers don't do it - and it can lead to real embarrassment for the organisation. Don't be tempted to say "just give it to me and I'll sort it out" - as engineers it's really scary when we hear that!

Good luck! I can strongly recommend it as a career, it's a really valuable and satisfying role if you can find the right position.

Thanks,

Andy

G'day Andy,

Thanks for taking the time to make such a helpful and common-sense reply. I have a couple of smaller jobs on at the moment and I will prioritise developing my portfolio over spending time learing a new software package.

Felicity 

G'day Andy,

Thanks for taking the time to make such a helpful and common-sense reply. I have a couple of smaller jobs on at the moment and I will prioritise developing my portfolio over spending time learing a new software package.

Felicity