Post History
Using "he/she" will annoy some of your readers; using singular "they" will annoy others. And referring to a user as "it" will seem weird to most people. What I do is to write around the problem wh...
Answer
#4: Post edited
Using "he/his" will annoy some of your readers; using singular "they" will annoy others. And referring to a user as "it" will seem weird to most people.What I do is to write around the problem wherever possible. First off, if you're referring to _the user of your API_, it's better to write in second person imperative anyway -- "do this, then do that". It's clear, direct, and less convoluted than "descriptive" style ("the user does X and...").Maybe you're not talking about the reader, though -- your reader is building something (using your API) that will in turn have users, and you need to talk about _those_ users. For example, let's talk about an API that lets your user build an app that somebody else will log into and configure. Here are some examples of ways to talk about that user without using gendered or wrong-number pronouns:> The user creates an account and registers it with your service.>> After logging in the user can access a configuration menu to (do something).I had to work a little to come up with those examples, not because of the writing style but because most of the time _your API documentation_ shouldn't be talking about _how your reader's users do something_. After all, your reader is responsible for the user interface. You're more likely to write things like this:> When the user logs out, remember to call some\_function() to also flush the session data.>> Use the register() function to tie a user ID to an OpenID credential.
- Using "he/she" will annoy some of your readers; using singular "they" will annoy others. And referring to a user as "it" will seem weird to most people.
- What I do is to write around the problem wherever possible. First off, if you're referring to _the user of your API_, it's better to write in second person imperative anyway -- "do this, then do that". It's clear, direct, and less convoluted than "descriptive" style ("the user does X and...").
- Maybe you're not talking about the reader, though -- your reader is building something (using your API) that will in turn have users, and you need to talk about _those_ users. For example, let's talk about an API that lets your user build an app that somebody else will log into and configure. Here are some examples of ways to talk about that user without using gendered or wrong-number pronouns:
- > The user creates an account and registers it with your service.
- >
- > After logging in the user can access a configuration menu to (do something).
- I had to work a little to come up with those examples, not because of the writing style but because most of the time _your API documentation_ shouldn't be talking about _how your reader's users do something_. After all, your reader is responsible for the user interface. You're more likely to write things like this:
- > When the user logs out, remember to call some\_function() to also flush the session data.
- >
- > Use the register() function to tie a user ID to an OpenID credential.
#3: Attribution notice added
Source: https://writers.stackexchange.com/a/19918 License name: CC BY-SA 3.0 License URL: https://creativecommons.org/licenses/by-sa/3.0/
#2: Initial revision
Using "he/his" will annoy some of your readers; using singular "they" will annoy others. And referring to a user as "it" will seem weird to most people. What I do is to write around the problem wherever possible. First off, if you're referring to _the user of your API_, it's better to write in second person imperative anyway -- "do this, then do that". It's clear, direct, and less convoluted than "descriptive" style ("the user does X and..."). Maybe you're not talking about the reader, though -- your reader is building something (using your API) that will in turn have users, and you need to talk about _those_ users. For example, let's talk about an API that lets your user build an app that somebody else will log into and configure. Here are some examples of ways to talk about that user without using gendered or wrong-number pronouns: > The user creates an account and registers it with your service. > > After logging in the user can access a configuration menu to (do something). I had to work a little to come up with those examples, not because of the writing style but because most of the time _your API documentation_ shouldn't be talking about _how your reader's users do something_. After all, your reader is responsible for the user interface. You're more likely to write things like this: > When the user logs out, remember to call some\_function() to also flush the session data. > > Use the register() function to tie a user ID to an OpenID credential.