It is easy to be underestimated as a technical writer/editor, especially in high-functioning organizations like IT or aerospace engineering. Just because you don’t have an engineering degree does not mean that you are ill-equipped to correct scientists or engineers when they get things flat-out wrong. They have their expertise, you have yours.
Now I freely admit to being an “English major” by training and inclination. That doesn’t mean I’m not paying attention when I’m proofreading or doing a comprehensive edit of a technical document. As a writer/editor, I can add value by keeping things orderly on the literary side. As I noted before, I have learned a great deal about rocket engineering by following the syntax and identifying which verb operates on what object and how. The good news is that scientists and engineers are required to write in English, albeit a very specialized form of it.
(Random side note: I’d read recently that the reason individuals started writing in an indirect, depersonalized manner to avoid the Inquisition. The logic being, “It’s not me doing this–any human being could do it. I am only an eyewitness.” True or not, this sort of writing has led to some rather bad, passive-voiced construction when it’s really not necessary. The auto da fé hasn’t been in business for awhile.)
Here are some things you can watch for even if you are completely unfamiliar with your content:
- Consistency: how are processes described? What is equipment called? What units (or abbreviations therefor) are being used? You can watch for these without “speaking the language.” Another thing–you can ensure that numbers and units are used consistently and correctly. Do the numbers make sense? Do they seem too large for the condition described? Too small?
- Nomenclature: Acronyms are the bane of my existence. NASA is awash with them. Still, there is an advantage to them–the primary one being that they take up less space on the page or on the tongue if you have to speak them aloud. Consider NTO vs. nitrogen tetroxide, for example. In any case, you can act as a quality control checker to ensure that all of this alphabet soup is properly and consistently defined.
- Syntax: If you cannot follow the technobabble, follow subjects, verbs, and objects. Let’s say you’re following the flow of liquid hydrogen through the conduits of the J-2X engine from the propellant tank to the combustion chamber, where the fire and smoke happens. Your process reaches the heat exchange channels around the combustion chamber then leaps directly to the fire without explaining how it got to the combustion chamber. Something appears to be missing.
- Spelling: It’s not like I knew off the top of my head how to spell monomethyl hydrazine, but if I see it spelled two different ways, I can flag that and let the subject matter expert sort it out. And, of course, you can catch errors of a more pedestrian sort, such as there, their, and they’re…
In an unfamiliar situation, the most important thing you can do is watch for differences, gaps, or things that don’t make sense. Is an being used as a noun in one place and a verb in another? Is a process labeled or described one way in one part of your document and a different way in another? Again, all this can be done without “speaking the language.”
When starting to edit a new project, the first thing I do is compile a list of nomenclature that shows the correct spelling, capitalization, hyphenation, usage, etc. of terms and abbreviations.