: Re: How should I respond to a supervisor/editor who thinks my technical writing is "too conversational?" My team and I are drafting a technical report to summarize the methods and results of a pilot
One comment he repeated several times was that parts of my text sounded "too conversational." I think meant that I didn't sound professional or academic enough.
You'd be better off asking for clarification instead of guessing at the meaning.
He also suggested revisions that increased the word count and complexity of the sentences without adding any additional meaning. I disagree with those comments and I don't like the suggested edits, and here's why:
You're exactly like me here. I also disagree with pointless elaboration.
However, that doesn't mean that there's never a reason to elaborate. You've been silent on why you were suggested to elaborate. Maybe the supervisor didn't tell you, maybe he did but you don't think it's relevant, maybe you subconsciously omitted that from the question, or maybe you intentionally omitted it.
I'm not here to judge; but it's impossible to review someone's feedback as meaningful if we don't know the problem the feedback is trying to point out.
There are reason to elaborate an explanation:
Legal reasons
Disambiguation that may not seem necessary to you, but may be helpful to people who aren't as knowledgeable about the subject matter.
Rephrasing in order to avoid certain words which could be mistaken as keywords in a tangentially related subject matter (e.g. avoiding the word "class" in a C# educational application)
I get the feeling that you only presented part of the full picture.
I believe that sometimes (always?), simple language is best.
I agree with your intention, but not your statement. Not always. This is very dependent on who your target audience is.
For laymen, simple is most often the best option.
For experts, you should favor precision and disambiguation, even if that entails a higher complexity.
For lawyers and legalese documentation, pedantic precision and utter disambiguation is the standard.
I also believe the impenetrable "academic" writing style of many scientists is a major shortcoming - it only hinders communication among scientists and isolates us from the public, who can't make sense of what we're trying to say.
I have yet to lay eyes on a single document that is written in a way that:
The laymen find it clear and understandable
The experts find it detailed enough to rely on it
The lawyers find it disambiguated enough that there are no reasonable loopholes
If there were a writing standard that could fulfill all of these requirements, it would be the only writing standard that was in use since it has no drawbacks.
As a technical writer, you'll generally be writing documentation for experts. Experts generally don't see linguistic simplicity as the main priority. Therefore, simplicity should not be your main focus when writing.
The higher word counts, more complex sentence structures, and lack additional meaning in the revisions were a clear sign (to me, at least) that he was taking things in the wrong direction.
You're overgeneralizing. More often than not, reducing sentence complexity leads to a higher word count, and reducing the word count leads to increased sentence complexity.
If the supervisor were adding complexity and word count at the same time, his feedback would obviously not be good.
However, we come back to my earlier point that we're only hearing your side of the story. The level of detail and the (apparent) lack of common sense in the supervisor's feedback are not matching up. You are likely omitting a key part of the supervisor's side of the story (this may be unintentional, I'm not accusing you of anything).
I know there's room for subjectivity, but I honestly think the sentences I crafted are just better - and I don't want to trash them.
You tell us they're better, but you don't showcase your point. Since this issue very much hinges on whether the supervisor is correct or not; I'd say it's very relevant to include an actual example so that we can see if his feedback has merit.
If I were to defend my writing, I feel like I'd be calling his own writing skills and workplace authority into question.
Generally speaking, ask for them to explain the feedback instead of arguing why the feedback is wrong in your opinion. Asking for clarification shouldn't be interpreted as calling the other person's skills into question. If anything, asking for his explanation implies that he knows it better than you.
At the same time, I take pride in my writing and I want my published documents to reflect that.
Pride should not come at a cost to the company. If the supervisor's version is objectively more in line with the company's expectations, the supervisor's version should be picked. Regardless of whether your version was only marginally or notably worse.
I don't think we should just "go along with it" and let them sully our writing, especially if our own names will be on the published document.
With the exception of some egregious fringe cases, the customer (in this case the company) gets the product how they want it. If they stress that they want the word "computer" replaced with "puterbox" across the entire document, then that's their choice.
If the company makes demands that you personally cannot live with (e.g. ideological differences), then you can refuse the project; but this will of course have consequences. Depending on the company, this can be seen as insubordination and grounds for firing.
When you refuse a project, you should already have accepted the consequences of your refusal.
More posts by @Kaufman555
: How to get opinion freelance articles accepted? I have had a similar experience about six or seven times: I email an editor, and, after several dozen times of pitching articles to various of
: How to show a character being bored for multiple chapters without boring the reader When my protagonist is learning to use their magical skill, they must remain in hiding. Because they have
Terms of Use Privacy policy Contact About Cancellation policy © selfpublishingguru.com2024 All Rights reserved.