My job regularly involves writing and reviewing (in the form of pull requests) English prose in the documentation for our internal system, which solely faces other developers, in a strongly American firm spread around the world.
That writing falls into two categories - a documentation website, and documentation snippets in our API (e.g. Swagger docs for our REST API). I feel that both of these have a large effect on users' initial impressions of our system/product, and that initial impression is important to me. We do not have formal technical writers on the team, or indeed any in the firm that I'm aware of.
I'm a native English speaker, and I did OK in English in school. Over half of my team are not native English speakers. Obviously their English is infinitely superior to my skills in other languages, and they deserve credit for the English they do write and speak.
However, I'm often disappointed in the quality of English that I see in the documentation, including from native English speakers. I'm very comfortable reviewing code - drawing on static analysis, best practices, team guidelines, rules of thumb and personal experience. I'm significantly less comfortable reviewing documentation changes - I don't feel I have datum points or concrete evidence to rely on, just the gut feel that I've used ever since school. I often end up commenting on PRs with what I think the text should be, without much justification or logic.
On a bad day, that makes me question my own writing. Nobody ever comments on my English, so I don't get regular feedback like I do on my code. It also makes me feel that if I can't be sure of my own writing, I shouldn't be coaching junior developers on improving theirs.
I'm not sure if I'm just lacking the comfort and safety of a programming language and compiler - or whether there is genuine room for improvement here. How can I improve what I write, the constructive criticism I make on documentation, and ultimately the whole team?