Categories: Techwriter
9. Have a backup plan in case you can't open a file format, especially if it's a legacy one. Did I mention Linux has a plethora of open source applications supporting almost every file format out there?
10. Unless you're a freelance writer, remember that your work will pass through several hands – project managers, dozens of translators, editors, assistant editors, engineers, proofreaders, designers, the printing staff, the sales guy, etc. Include everything they're going to need like images, sources, layout files, proofs and of course, the final output. Keep several copies backed up of all revisions and originals. Changes come and go and having a library of resources, unused or otherwise, can go a long way.
11. Have your own backup plan. Whether or not your company backs up regularly, you should have your own method of keeping your source files and designs safe. Back up all your work across all the systems you're using especially if you're using both a Mac and a Windows machine. Time Machine is a no-brainer and Linux's rsync works across networked PCs (Use grsync if you prefer a GUI).
12. In the beginning, follow whatever the veteran writer, the engineers, or your editor says even if you think you're much better than they are technically, grammatically, and artistically. You can make a lot of enemies really quickly in a publishing environment.
13. Even if you have a strong technical background with years of experience in hardware, Windows, Linux, or Mac, trust the engineers, RD staff, researchers, programmers, and technologists you're talking to. Don't bother to share your "veteran opinion." These guys know what they're talking about. Likewise if they hired you for your multilingual skills. Sure, you can speak as many languages as Indiana Jones but are you sure you want to give your suggestions as to how memory dumps, UEFI, and AMD chips should work?
14. Editors can be thugs. They will always find something wrong with a document. Speaking geek, suggesting advice from Wired or Ars Technica, talking MCSE, Unix, Oracle, Novell, CISCO, or command line will elicit little to no response from them . . . and they will more likely spit at all your certifications, especially your Adobe ones.
15. Realistically speaking, you can get by without learning XML, especially if your technical background and Adobe certifications are solid. However, it is highly recommended. Live, breathe, and eat XML. And XHTML, Javascript, and Java would help, too.
16. Even if you used the right color profiles, followed the templates, packaged all the fonts, backed up properly, followed the engineers to the letter, and proofread till your eyes bled, everyone's still going to blame you. After all, YOU'RE THE NEW GUY.
0 comments:
Post a Comment