“If you’ve nothing to say, say it any way you like…If what you have to say is important and/or difficult to follow, use the simplest language possible. If the reader doesn’t get it then, let it not be your fault.”
—Larry Niven

A bad day at the office

I once got into an argument with an engineer over writing style. He was under the impression that unless text was written “as an engineer would write it,” then it wasn’t technically correct. Needless to say, I disagreed.

Things came to a head one day when he was assigned to provide the technical review of a paper I had written and he did his level best to make me want to tear my hair out: passive voice, bad constructions, multi-line separations between subject and verb, bad punctuation–you name it, he had it all. And the Track Changes markups were a sight to behold.

I had two choices: try to go back through the red markups and reconstruct what I had originally written or accept all of his changes and start over on my editing. For the sake of my sanity and blood pressure, I did the latter. I then went back and fixed the blatant errors of grammar and construction, added non-engineering language to make points more clearly, and reconstructed things so they sounded like English again.

This wasn’t passive-aggressive (I was nearly on the verge of full-on aggressive). I showed him what I did and explained it to him. He accused me of “dumbing down” the paper. I explained that a) engineers would not be the only ones reading the paper, and b) it was not a sin to write an engineering paper in language that a non-engineer could understand. He shook his head, not buying my muted English major outrage.

Setting editorial expectations

I took a deep breath and asked, “Is anything I did with your prose  technically incorrect?”

He admitted that, with one or two exceptions, my edits were technically correct. So finally I made a deal with him. I would do my job and write about the hardware as best I could with the knowledge I had on hand. His job would be to make sure that I wasn’t saying anything that violated the laws of physics or contradicted how the hardware actually functioned…and that was all.

A lot of this culture clash stemmed from a mismatch of expectations:

• He expected me to write like an engineer.
• I expected him to review only the technical correctness of the content, not the style.

In the end, I calmed down and life went back to normal, though it did require some education in both directions. I had to explain what I meant by a “technical edit” and ensure that he kept his hands off my prose unless it was getting the hardware or the physics wrong. He, in turn, had to educate me on some of the ways I was explaining the way the hardware worked.

Lessons learned

So things worked out and there were no hard feelings. But it did take some relaxing of the ego and reduction of control on the part of both parties. The engineer had to accept that writing in non-engineering English was acceptable for the products I was writing, and I had to accept that my wording could give the wrong impression of how a technology worked.

My usual refrain now when working with engineers is to ask them to “Please review my prose so that, in my zeal to make things grammatically correct, I don’t make them technically incorrect.” That arrangement seems to work. I trust the techies to get the technology write, and they trust me to get the language right. But if someone accuses me of not writing as an engineer would, I will still answer guilty as charged. If someone wanted the engineer to write, they wouldn’t have hired me, would they?