Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Habits and routines for my first tech writing job

+0
−0

A Japanese company has offered me a gig helping translate an Android1 business application + documentation into English. Their staff will do a rough translation, and I will polish it into something reasonably professional.

This is my first writing job. My “qualifications” are availability, cheapness, and a fair technical background. (I also happen to think I can write good prose, but the client didn’t bother to check that.) But still, I want this contract to be a success, and I hope it will lead to more work.

What work habits and routines do I need to establish in preparation for this new job?

1. Android OS is the operating system that drives most non-Apple smartphones and tablets.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

This post was sourced from https://writers.stackexchange.com/q/5208. It is licensed under CC BY-SA 3.0.

0 comment threads

1 answer

+1
−0

I'm answering this as a technical writer but I don't have translation experience so can't address any aspects specific to that.

Many of the habits that (I hope) you already have as a software developer apply equally to technical writing:

  • Design first: figure out how you will structure the document to cover everything with a good flow (more on that in a minute). Stub it out -- does it work? In your case it sounds like they'll be giving you a rough document so this might not apply as much, but review it for structure/organization first anyway.

  • Put yourself in the user's shoes: what tasks will the user be attempting to complete? What does he need to know in order to do that? Don't just "walk the menus" (as is common in application documentation); think about his goals. If you've ever written API documentation and have risen above the level of the individual class/method/function to produce package overviews, developer guides, etc, do the same thing here.

  • Work breadth-first, not depth-first: especially because this is a new area for you, there is risk that you'll get bogged down in the early sections and have to rush the end to meet the deadline/time-allocation. Do one reasonable pass over the whole thing using no more than half the time allotted. Then assess where the most work is needed and address that. Save about 20% of the time for an editorial/polishing pass (and to address any comments you receive).

  • Ask your questions early: something they've given you won't make sense but you won't spot it early if you don't look. Review everything they've given you first, before you start designing and writing, so you can queue up the questions and go on to other work while waiting for the answers. (This is particularly important if you're looking at at least a one-day turn-around due to time zones.) As with any other work you've done, you don't want to get blocked on everything because you're blocked on something; structure your work to support this kind of multi-tasking.

When will your work be reviewed? Only at the end, or will there be a review of a draft before you're done? If the task is more than a couple of full-time weeks then, especially for a first gig, I would ask for a draft review to make sure everyone agrees about the level of detail, prose quality, structure, etc that you're producing.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »