Appropriate values to group user information by gender?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
11
down vote
favorite
We have an application that stores data regarding a user's gender. The end user does not see this data, only back-end developers.
Possible values for this grouping are as follows:
Female
Male
Other
I was recently showing my friend the project and she pointed out that other people who see this data might deem this sexist, as it doesn't include many identifiable gender types.
She also brought up the following concerns from a data point of view, that someone reviewing the back-end of this application might notice:
- People might think that the numeric values (0 for female, 1 for male) used to store this data in the database are referencing genitalia.
- In binary
0
stands foroff
and1
stands foron
, meaning there is a possibility that female colleagues and / or programmers might deem this (even more) sexist. - People might deem referring to them as 'Other' as outright rude and / or offensive.
I don't intend to offend anyone, regardless of their race, religion, gender or sexuality and I've realised that this could potentially offend those who see the way that we're grouping this data by gender, as it may not be inclusive of the gender type they identify with.
In summary, the question I'd like answered is the following: Is it appropriate to collect data regarding one's gender using only a select few gender types (Male and Female), and group the rest into an 'Other' category?
Please note that this was not designed intentionally to offend anyone, it was something we had not put that much thought into while we were designing the database.
colleagues gender sexism
suggest improvements |Â
up vote
11
down vote
favorite
We have an application that stores data regarding a user's gender. The end user does not see this data, only back-end developers.
Possible values for this grouping are as follows:
Female
Male
Other
I was recently showing my friend the project and she pointed out that other people who see this data might deem this sexist, as it doesn't include many identifiable gender types.
She also brought up the following concerns from a data point of view, that someone reviewing the back-end of this application might notice:
- People might think that the numeric values (0 for female, 1 for male) used to store this data in the database are referencing genitalia.
- In binary
0
stands foroff
and1
stands foron
, meaning there is a possibility that female colleagues and / or programmers might deem this (even more) sexist. - People might deem referring to them as 'Other' as outright rude and / or offensive.
I don't intend to offend anyone, regardless of their race, religion, gender or sexuality and I've realised that this could potentially offend those who see the way that we're grouping this data by gender, as it may not be inclusive of the gender type they identify with.
In summary, the question I'd like answered is the following: Is it appropriate to collect data regarding one's gender using only a select few gender types (Male and Female), and group the rest into an 'Other' category?
Please note that this was not designed intentionally to offend anyone, it was something we had not put that much thought into while we were designing the database.
colleagues gender sexism
Edited to bring in-line with the scope of TheWorkplace. Inserted a direct question that asks not for advice on what to do, but whether it was appropriate to group data using only the two types, grouping the rest into an 'other' category (and therefore 'excluding' them as options), which appears to be the OP's main concern.
– schizoid04
Mar 2 '17 at 16:18
suggest improvements |Â
up vote
11
down vote
favorite
up vote
11
down vote
favorite
We have an application that stores data regarding a user's gender. The end user does not see this data, only back-end developers.
Possible values for this grouping are as follows:
Female
Male
Other
I was recently showing my friend the project and she pointed out that other people who see this data might deem this sexist, as it doesn't include many identifiable gender types.
She also brought up the following concerns from a data point of view, that someone reviewing the back-end of this application might notice:
- People might think that the numeric values (0 for female, 1 for male) used to store this data in the database are referencing genitalia.
- In binary
0
stands foroff
and1
stands foron
, meaning there is a possibility that female colleagues and / or programmers might deem this (even more) sexist. - People might deem referring to them as 'Other' as outright rude and / or offensive.
I don't intend to offend anyone, regardless of their race, religion, gender or sexuality and I've realised that this could potentially offend those who see the way that we're grouping this data by gender, as it may not be inclusive of the gender type they identify with.
In summary, the question I'd like answered is the following: Is it appropriate to collect data regarding one's gender using only a select few gender types (Male and Female), and group the rest into an 'Other' category?
Please note that this was not designed intentionally to offend anyone, it was something we had not put that much thought into while we were designing the database.
colleagues gender sexism
We have an application that stores data regarding a user's gender. The end user does not see this data, only back-end developers.
Possible values for this grouping are as follows:
Female
Male
Other
I was recently showing my friend the project and she pointed out that other people who see this data might deem this sexist, as it doesn't include many identifiable gender types.
She also brought up the following concerns from a data point of view, that someone reviewing the back-end of this application might notice:
- People might think that the numeric values (0 for female, 1 for male) used to store this data in the database are referencing genitalia.
- In binary
0
stands foroff
and1
stands foron
, meaning there is a possibility that female colleagues and / or programmers might deem this (even more) sexist. - People might deem referring to them as 'Other' as outright rude and / or offensive.
I don't intend to offend anyone, regardless of their race, religion, gender or sexuality and I've realised that this could potentially offend those who see the way that we're grouping this data by gender, as it may not be inclusive of the gender type they identify with.
In summary, the question I'd like answered is the following: Is it appropriate to collect data regarding one's gender using only a select few gender types (Male and Female), and group the rest into an 'Other' category?
Please note that this was not designed intentionally to offend anyone, it was something we had not put that much thought into while we were designing the database.
colleagues gender sexism
edited Mar 29 '17 at 19:15
asked Aug 1 '16 at 5:07
user51020
Edited to bring in-line with the scope of TheWorkplace. Inserted a direct question that asks not for advice on what to do, but whether it was appropriate to group data using only the two types, grouping the rest into an 'other' category (and therefore 'excluding' them as options), which appears to be the OP's main concern.
– schizoid04
Mar 2 '17 at 16:18
suggest improvements |Â
Edited to bring in-line with the scope of TheWorkplace. Inserted a direct question that asks not for advice on what to do, but whether it was appropriate to group data using only the two types, grouping the rest into an 'other' category (and therefore 'excluding' them as options), which appears to be the OP's main concern.
– schizoid04
Mar 2 '17 at 16:18
Edited to bring in-line with the scope of TheWorkplace. Inserted a direct question that asks not for advice on what to do, but whether it was appropriate to group data using only the two types, grouping the rest into an 'other' category (and therefore 'excluding' them as options), which appears to be the OP's main concern.
– schizoid04
Mar 2 '17 at 16:18
Edited to bring in-line with the scope of TheWorkplace. Inserted a direct question that asks not for advice on what to do, but whether it was appropriate to group data using only the two types, grouping the rest into an 'other' category (and therefore 'excluding' them as options), which appears to be the OP's main concern.
– schizoid04
Mar 2 '17 at 16:18
suggest improvements |Â
15 Answers
15
active
oldest
votes
up vote
59
down vote
As a woman who works on the technical side of development, I really don't care what the underlying numeric primary key value is. I wouldn't have even thought about the connotations that you've raised if you hadn't done so (or course, now I can't unsee it). I really, truly think that someone's overthinking this. Put down however many enumerated values if you so desire for gender. If you want to be truly supportive of diverse gender identities, then three is nowhere near enough :)
However, an even better idea is to ask yourselves, "Do we REALLY need to know the gender of this person? Why? What do we plan to do with it?" If if has absolutely no bearing on how the record is utilised in the system, then it's not really worth collecting.
But to answer your question, it doesn't matter what you use for your database numeric keys. Having genders of just male and female is not sufficient, so if you really want to keep it to a minimal set, you could use "Male, Female, Undisclosed". That way you're not referring to gender diverse people as "Other", and you give everyone the option to choose if they wish to disclose their gender.
46
Despite what certain movements may have you believe, gender is the single most important differentiator /driver for behaviour. Nothing else even comes close. Of course it's worth collecting. Let's not start restricting system architecture out of a misplaced sense of propriety. I understand where you're coming from but the fact that you even bring up dropping a field so indisputably critical to a database of personal information is a telling sign that this equality nonsense has gone too far. Acknowledging that gender exists doesn't mean that we can't treat people of different genders equally.
– Lilienthal♦
Aug 1 '16 at 8:16
27
There are plenty of databases that store gender that don't need it. Does it really matter if a meeting planner is female or male? However for certain applications such as medical applications it could be critical . It's up to the business to determine if gender is really needed. I am a woman and a strong feminist, but I would find that interpretation of the numbers as totally ridiculous and off base.
– HLGEM
Aug 1 '16 at 14:24
5
I totally agree with this, although it's one case where, if someone was really making a fuss, I'd just swap the database to use M/F/O rather than 0/1/2. I generally dislike storing strings or characters where an enumeration would do, in case the definition changes, but we're unlikely to change the words "Male" and "Female" anytime soon!
– Jon Story
Aug 5 '16 at 15:27
4
No matter how you encode gender information, it must be represented in the database as some combination of zeros and ones.
– Patricia Shanahan
Aug 5 '16 at 16:01
5
@xDaizu I have no idea if they assign people by genitalia, as I haven't seen the ones of the other guy in the room, nor did I particularly want to. I'm quite certain though, that anyone in the company claiming to be of a less-common gender would get a single room if desired. They certainly would not stick a guy with a girl just because both had a penis.
– Erik
Mar 3 '17 at 13:06
 |Â
show 6 more comments
up vote
46
down vote
These numbers are identifiers in a database. Database record identifiers are, by definition of their purpose, completely meaningless data. Anyone who tries to claim they mean something is almost certainly either not a software engineer or a bad software engineer.
10
To add to that: These numbers aren't even shown to end users. This is literally just an implementation detail of a backend data system. Nobody but the admins will ever see this. For all intents and purposes, it could have been "234239482034023480" for male and "35204238423048203" for female. There is no difference, and assuming that the numbers are sexist because of the order someone chose is ridiculous and absurd.
– Magisch
Aug 5 '16 at 13:13
17
Are you really suggesting that the number for a woman should be higher, and possibly seen as superior, to that of a man?
– Steve Ives
Aug 5 '16 at 13:58
4
I agree with this answer - the questions context is simply absurd. There is and should be no thought on this subject about gender discrimination/bias, it is simply back-end data and should be kept as such.
– Sh4d0wsPlyr
Aug 5 '16 at 15:23
suggest improvements |Â
up vote
42
down vote
What you should do is nothing.
What you're dealing with is someone who is deliberately trying to be offended. I've dealt with this before over a different issue, where someone actually filed a union action over the colors we used in a spreadsheet. We had to dig in to stop that nonsense, and so do you.
If you change anything, then you are tacitly admitting to doing wrong. Once you do that, life at work will become very difficult for you, because there can always be more reasons invented.
Just as an example, I can make every last number offensive for one reason or another.
0 is round and could be offensive to people who are fat.
1 could be offensive because someone decides it's a phallic symbol.- See "South Park" for someone being offended by the number 2
3, 6, and 9 could all be offensive to Christians (if they so choose) because of the number of the beast.
4 because it resembles a knife
7 because it resembles a gun8 because its hour-glass shape promotes a certain body shape.
...which leaves five, and if I thought about it long enough I could make that offensive as well.
It may cause you some short-term discomfort, but if you give into one silly demand, there will be no end of it for you. Again, for emphasis. If you change what you have, you are admitting to wrong doing, whether you realize it or not. Once you've got that label slapped on you the next complaint will have more force because you have a "history of bigoted behavior" or some other nonsense.
Stand your ground and dismiss your coworker's concerns as the trouble-making disruption it is.
13
Problem solved! Use 5 for Female, 55 for Male and 555 for Other.
– Ouroboros
Aug 5 '16 at 14:23
@Ouroboros some are more equal than others.
– user37746
Sep 15 '16 at 11:27
4
+2 for your whole answer, loved it; but -1 for "do nothing". If any number can be offensive and it doesn't matter, you might as well go standard. :D Seriously, any excuse is good for that...
– xDaizu
Mar 2 '17 at 16:28
@xDaizu Great article. Would you mind if I included that in my answer? I'll give you the credit.
– Richard U
Mar 2 '17 at 21:21
@RichardU Sure, go ahead ^^
– xDaizu
Mar 2 '17 at 22:39
suggest improvements |Â
up vote
33
down vote
As it is usually the case in IT, just go standard. Use the ISO/IEC 5218
The four codes specified in ISO/IEC 5218 are:
0 = not known, 1 = male, 2 = female, 9 = not applicable.
The standard specifies that its use may be referred to by the
designator "SEX".
Fun note: Even though the ISO explicitely says that no significance is to be placed on the encoding of male as 1 and female as 2
, since we are not using the problematic 0, males can say that they are number one while females can say they are twice as good, so that should make everyone happy... right? :)
suggest improvements |Â
up vote
13
down vote
It's an enumeration of values to allow it to be stored in the database. No developer is going to notice or care that female is represented by 0 and male by 1, and this fact should never be exposed to the end user.
If possible, it might be better to store it in a char(1)... that way you can query it using something like WHERE gender = 'F'
rather than WHERE gender = 0
. It sorts out your friends issue with it and also provides greater ease of use for future development.
6
Ah but this would still be sexist, because F still has a lower ASCII value (70) than M (77). It might be safer to use M/W (Man/Woman) because W has a value of (87) :) :)
– Jon Story
Aug 5 '16 at 15:30
3
Using a char(1) could have unforseen knockon effects with regard to collation and character sets, whereas ints will not.
– Moo
Aug 5 '16 at 16:05
@Moo Provided the app is designed to handle a char(1) instead of an int, I don't see why it would be an issue. What sort of problem did you have in mind?
– Maybe_Factor
Aug 8 '16 at 2:01
3
@JonStory AnM
has two peaks, while anW
just have one (and, dependent on the font, it's a lower peak). Subtle way you have to remind everyone that there are more men in "top positions", huh? :) :)
– xDaizu
Mar 2 '17 at 16:30
Looking at the W, I see three peaks...
– gnasher729
Aug 1 at 23:27
suggest improvements |Â
up vote
9
down vote
As 2 stands for other (or not sure) people might deem this (somewhat) Transphobic or outright rude and / or offensive.
While the other two points look like someone actively trying to find fault for the sake of finding fault, there's no reason to limit yourself to a tristate with this as the 3rd option. If you want to be more inclusive look at the expansive lists of options sites like Facebook provide beyond male/female and offer the same. Facebook apparently is up to 71 options. I'd provide a direct link; except the only 3rd party sites I can find listing them all have highly negative reactions to the idea.
I would add to this that letting users define their own gender and pronouns would be very inclusive. Having lots of defaults is great, but whatever boxes you make, someone won't feel right in them.
– Andrew Piliser
Aug 5 '16 at 18:04
suggest improvements |Â
up vote
6
down vote
In summary, the question I'd like answered is the following: Is it appropriate to collect data regarding one's gender using only a select few gender types (Male and Female), and group the rest into an 'Other' category?
That depends on why you are collecting that data in the first place. Data models aren't supposed to fulfill political correctness needs, they are supposed to fulfill business needs.
So what exactly is the business need for the gender field?
Do you want to be able to use the correct honorifics and pronouns when communicating with users? Then save the pronouns and honorifics.
Do you need it for some marketing analysis? Then you might indeed have a business case for using a more complicated representation of sex/gender identity, because people with non-standard identities are demographics with non-standard consumer behavior.
Are you building a dating app? Most dating services have a clear binary distinction how the user self-identifies and what partners they are looking for. Dating for people with non-binary gender identity and/or preference is a rather specialized market segment. Ask your management if catering to this segment is part of their business plan. If they do, there are two solutions. Either invent a super-complex system to match people who might be interested in dating each other, or just drop the gender-information altogether and let people decide based on profiles alone.
Is it for reporting to some 3rd party? Then report in the format that 3rd party wants.
2
+1 "Data models aren't supposed to fulfill political correctness needs, they are supposed to fulfill business needs."
– A. I. Breveleri
Mar 3 '17 at 23:10
suggest improvements |Â
up vote
2
down vote
Personally, I think your co-worker is overthinking it, as others have already said. Now, more inline with regards to your classification of genders, I have seen some systems user the following five:
Male, Female, Other Specific, Not Known, Not Specified
This number is not a set rule by any means; in fact, for simplicity, I would go with Not Specified for the third and final option.
suggest improvements |Â
up vote
2
down vote
You have social options and technical options.
Socially, you can just ignore your friend's opinion. She is not on the team and you were just showing her your code and she "went there."
Or, you (and your team) could decide to make a change to (hopefully) avoid the issue. You have a couple of technical options available to you. This assumes your business requirements are not able to be changed with respect to whether and how gender must be tracked.
Use strings instead of ordinal values. Of course if you use this field as a key, or frequently in joins, your queries might be a few milliseconds slower, which can add up.
Change the ordinal values of your enumeration to be large numbers. The actual value probably doesn't matter. It takes no more CPU effort to compare a large number as it does to compare a small one. If you're using a 32-bit integer, you have 4 billion numbers to pick from. Of course, you should take care that your numbers do not differ by only a 1 or a 0, because we just cannot un-see this post!
suggest improvements |Â
up vote
0
down vote
I think you are WAY overthinking this.
Whatever you put into the database for the primary key is going to have to have a unique value. Numbers, characters. The computer is a calculator. It deals with numbers.
Accordingly, having unique numeric values implies that each value will have different properties. Some will be less than others. Some will be greater. Some will be primes. Some will not. Some will have one digit, others will have two. We can go on with this ad infinitum, and if we take the OP's approach then it sorta says it's sane for us to mince how the qualities (as described) of these values somehow "ding" the worth of the genders they're associated with in the data.
It's like the old saying of how some people say "tomaTOE", vs "toMAHto". Remarkable, brow-raising?? Slightly. High in value, in the long term? Hmm, probably not. Epic, long-term, cataclysmic effects with the globe spinning off its axis?? SMH.
suggest improvements |Â
up vote
0
down vote
I was recently showing my friend the project and she pointed out that other people who see this data might deem this sexist, as it doesn't include many identifiable gender types.
That's because your friend is talking about the product, not your technical problem of implementing the product. Your friend is, evidently, of the opinion that your app, website, service, or whatever should be representing gender differently. Your friend probably does not mean to offend your specific job of implementing the 3 options in a database in some way that reflects the decision made by product.
If you have sway in the product, you might consider exercising it. Many businesses have greatly benefited from gender inclusiveness in their product and marketing (source: just watching subway ads reach out to trans people).
If you have 3 gender options you need to implement, then you don't have any social theory problem, just a product you need to implement in the backend, and apply your usual engineering knowledge for naming things with relatively little political implication.
suggest improvements |Â
up vote
0
down vote
You don't change your application (which may have significant cost for development and testing) unless someone complains who is actually affected, gives a reason that actually justifies the cost, and if your boss tells you to make the change.
The somehow justified complaint that someone who isn't male or female would have to choose a category "other" that makes them somehow stand out can be solved: Change "other" to "unknown, undisclosed, or other". And then you can volunteer to not disclose your gender so nobody needs to be the only person in that category.
And change the question from "which are you" to "which describes you best", so someone who sees themselves 60/40 between two genders can pick the 60% case without having to make a compromise.
suggest improvements |Â
up vote
-1
down vote
First, establish she wasn't joking.
Then, roll your eyes and make it
Other = 0,
Male = 1,
Female = 2
And stop showing her your code!
suggest improvements |Â
up vote
-3
down vote
You are writing a piece of software, and your first and foremost priority is making sure it works and is easy for your peers to work with.
When it comes to data analysis, data isn't inherently bigoted. It's only bigoted when you ascribe further meaning than what is present. For example, if your numbers show that there are more men than women who work at your company, there's nothing wrong with that. If you take that and say that women are therefore less qualified than men to work in your field, that's problematic.
If your friend, or some hypothetical future person, sees that a '0' is being used for women and a '1' is for men, and decides that that number is the number of penises that employee has, that is not reflective of your attitude or your codebase's attitude. Your code is just text, it can't have an opinion.
The question you should ask is, can you rewrite your code in such a way that a programmer not familiar with it can still work effectively? Or will your proposed change trade off clarity/convenience with perceived gender neutrality? If it's the former, then go ahead and make the change if it makes you more comfortable.
An easy workaround is maybe to just replace every '0' or '1' using #define and explicitly name each group, so no one will assume any further meaning behind it.
suggest improvements |Â
up vote
-5
down vote
Why waste storage space by having an Integer variable for this purpose? Use a boolean instead - IsMale: true or false. Null valie if neither male nor female.
Problem solved.
5
Some people neither male or female - transgender/intersex for example. Or perhaps they do not wish the company concerted to know there gender
– Ed Heal
Aug 5 '16 at 12:24
Androgynous people exist, and there are arguably a lot more then 2 genders. On a technical node, almost all implementations of SQL relational databases use padding so an integer number is likely to be only minimally less space-consuming then a boolean (unless you have a LOT of booleans in that table). And considering its a person database, its likely not large enough for spacing to matter. You could probably make every field in that table a char(500) and it wouldn't matter.
– Magisch
Aug 5 '16 at 13:05
2
@AndrewPiliser all of those can be compressed into 'other' unless you feel OP should update their tables everytime their tumblr page updates as well...
– easymoden00b
Aug 5 '16 at 18:13
1
@easymoden00b I'd recommend letting people write in whatever they want, with defaults for common choices. Also, way to bring up Tumblr. Are you going to call me an SJW next?
– Andrew Piliser
Aug 5 '16 at 18:33
1
And of course if you use a boolean, why isn't it IsFemale? Or better yet? IsOther.
– HLGEM
Mar 2 '17 at 19:01
 |Â
show 2 more comments
protected by Elysian Fields♦ Mar 2 '17 at 21:57
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
15 Answers
15
active
oldest
votes
15 Answers
15
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
59
down vote
As a woman who works on the technical side of development, I really don't care what the underlying numeric primary key value is. I wouldn't have even thought about the connotations that you've raised if you hadn't done so (or course, now I can't unsee it). I really, truly think that someone's overthinking this. Put down however many enumerated values if you so desire for gender. If you want to be truly supportive of diverse gender identities, then three is nowhere near enough :)
However, an even better idea is to ask yourselves, "Do we REALLY need to know the gender of this person? Why? What do we plan to do with it?" If if has absolutely no bearing on how the record is utilised in the system, then it's not really worth collecting.
But to answer your question, it doesn't matter what you use for your database numeric keys. Having genders of just male and female is not sufficient, so if you really want to keep it to a minimal set, you could use "Male, Female, Undisclosed". That way you're not referring to gender diverse people as "Other", and you give everyone the option to choose if they wish to disclose their gender.
46
Despite what certain movements may have you believe, gender is the single most important differentiator /driver for behaviour. Nothing else even comes close. Of course it's worth collecting. Let's not start restricting system architecture out of a misplaced sense of propriety. I understand where you're coming from but the fact that you even bring up dropping a field so indisputably critical to a database of personal information is a telling sign that this equality nonsense has gone too far. Acknowledging that gender exists doesn't mean that we can't treat people of different genders equally.
– Lilienthal♦
Aug 1 '16 at 8:16
27
There are plenty of databases that store gender that don't need it. Does it really matter if a meeting planner is female or male? However for certain applications such as medical applications it could be critical . It's up to the business to determine if gender is really needed. I am a woman and a strong feminist, but I would find that interpretation of the numbers as totally ridiculous and off base.
– HLGEM
Aug 1 '16 at 14:24
5
I totally agree with this, although it's one case where, if someone was really making a fuss, I'd just swap the database to use M/F/O rather than 0/1/2. I generally dislike storing strings or characters where an enumeration would do, in case the definition changes, but we're unlikely to change the words "Male" and "Female" anytime soon!
– Jon Story
Aug 5 '16 at 15:27
4
No matter how you encode gender information, it must be represented in the database as some combination of zeros and ones.
– Patricia Shanahan
Aug 5 '16 at 16:01
5
@xDaizu I have no idea if they assign people by genitalia, as I haven't seen the ones of the other guy in the room, nor did I particularly want to. I'm quite certain though, that anyone in the company claiming to be of a less-common gender would get a single room if desired. They certainly would not stick a guy with a girl just because both had a penis.
– Erik
Mar 3 '17 at 13:06
 |Â
show 6 more comments
up vote
59
down vote
As a woman who works on the technical side of development, I really don't care what the underlying numeric primary key value is. I wouldn't have even thought about the connotations that you've raised if you hadn't done so (or course, now I can't unsee it). I really, truly think that someone's overthinking this. Put down however many enumerated values if you so desire for gender. If you want to be truly supportive of diverse gender identities, then three is nowhere near enough :)
However, an even better idea is to ask yourselves, "Do we REALLY need to know the gender of this person? Why? What do we plan to do with it?" If if has absolutely no bearing on how the record is utilised in the system, then it's not really worth collecting.
But to answer your question, it doesn't matter what you use for your database numeric keys. Having genders of just male and female is not sufficient, so if you really want to keep it to a minimal set, you could use "Male, Female, Undisclosed". That way you're not referring to gender diverse people as "Other", and you give everyone the option to choose if they wish to disclose their gender.
46
Despite what certain movements may have you believe, gender is the single most important differentiator /driver for behaviour. Nothing else even comes close. Of course it's worth collecting. Let's not start restricting system architecture out of a misplaced sense of propriety. I understand where you're coming from but the fact that you even bring up dropping a field so indisputably critical to a database of personal information is a telling sign that this equality nonsense has gone too far. Acknowledging that gender exists doesn't mean that we can't treat people of different genders equally.
– Lilienthal♦
Aug 1 '16 at 8:16
27
There are plenty of databases that store gender that don't need it. Does it really matter if a meeting planner is female or male? However for certain applications such as medical applications it could be critical . It's up to the business to determine if gender is really needed. I am a woman and a strong feminist, but I would find that interpretation of the numbers as totally ridiculous and off base.
– HLGEM
Aug 1 '16 at 14:24
5
I totally agree with this, although it's one case where, if someone was really making a fuss, I'd just swap the database to use M/F/O rather than 0/1/2. I generally dislike storing strings or characters where an enumeration would do, in case the definition changes, but we're unlikely to change the words "Male" and "Female" anytime soon!
– Jon Story
Aug 5 '16 at 15:27
4
No matter how you encode gender information, it must be represented in the database as some combination of zeros and ones.
– Patricia Shanahan
Aug 5 '16 at 16:01
5
@xDaizu I have no idea if they assign people by genitalia, as I haven't seen the ones of the other guy in the room, nor did I particularly want to. I'm quite certain though, that anyone in the company claiming to be of a less-common gender would get a single room if desired. They certainly would not stick a guy with a girl just because both had a penis.
– Erik
Mar 3 '17 at 13:06
 |Â
show 6 more comments
up vote
59
down vote
up vote
59
down vote
As a woman who works on the technical side of development, I really don't care what the underlying numeric primary key value is. I wouldn't have even thought about the connotations that you've raised if you hadn't done so (or course, now I can't unsee it). I really, truly think that someone's overthinking this. Put down however many enumerated values if you so desire for gender. If you want to be truly supportive of diverse gender identities, then three is nowhere near enough :)
However, an even better idea is to ask yourselves, "Do we REALLY need to know the gender of this person? Why? What do we plan to do with it?" If if has absolutely no bearing on how the record is utilised in the system, then it's not really worth collecting.
But to answer your question, it doesn't matter what you use for your database numeric keys. Having genders of just male and female is not sufficient, so if you really want to keep it to a minimal set, you could use "Male, Female, Undisclosed". That way you're not referring to gender diverse people as "Other", and you give everyone the option to choose if they wish to disclose their gender.
As a woman who works on the technical side of development, I really don't care what the underlying numeric primary key value is. I wouldn't have even thought about the connotations that you've raised if you hadn't done so (or course, now I can't unsee it). I really, truly think that someone's overthinking this. Put down however many enumerated values if you so desire for gender. If you want to be truly supportive of diverse gender identities, then three is nowhere near enough :)
However, an even better idea is to ask yourselves, "Do we REALLY need to know the gender of this person? Why? What do we plan to do with it?" If if has absolutely no bearing on how the record is utilised in the system, then it's not really worth collecting.
But to answer your question, it doesn't matter what you use for your database numeric keys. Having genders of just male and female is not sufficient, so if you really want to keep it to a minimal set, you could use "Male, Female, Undisclosed". That way you're not referring to gender diverse people as "Other", and you give everyone the option to choose if they wish to disclose their gender.
answered Aug 1 '16 at 5:46


Jane S♦
40.8k16125159
40.8k16125159
46
Despite what certain movements may have you believe, gender is the single most important differentiator /driver for behaviour. Nothing else even comes close. Of course it's worth collecting. Let's not start restricting system architecture out of a misplaced sense of propriety. I understand where you're coming from but the fact that you even bring up dropping a field so indisputably critical to a database of personal information is a telling sign that this equality nonsense has gone too far. Acknowledging that gender exists doesn't mean that we can't treat people of different genders equally.
– Lilienthal♦
Aug 1 '16 at 8:16
27
There are plenty of databases that store gender that don't need it. Does it really matter if a meeting planner is female or male? However for certain applications such as medical applications it could be critical . It's up to the business to determine if gender is really needed. I am a woman and a strong feminist, but I would find that interpretation of the numbers as totally ridiculous and off base.
– HLGEM
Aug 1 '16 at 14:24
5
I totally agree with this, although it's one case where, if someone was really making a fuss, I'd just swap the database to use M/F/O rather than 0/1/2. I generally dislike storing strings or characters where an enumeration would do, in case the definition changes, but we're unlikely to change the words "Male" and "Female" anytime soon!
– Jon Story
Aug 5 '16 at 15:27
4
No matter how you encode gender information, it must be represented in the database as some combination of zeros and ones.
– Patricia Shanahan
Aug 5 '16 at 16:01
5
@xDaizu I have no idea if they assign people by genitalia, as I haven't seen the ones of the other guy in the room, nor did I particularly want to. I'm quite certain though, that anyone in the company claiming to be of a less-common gender would get a single room if desired. They certainly would not stick a guy with a girl just because both had a penis.
– Erik
Mar 3 '17 at 13:06
 |Â
show 6 more comments
46
Despite what certain movements may have you believe, gender is the single most important differentiator /driver for behaviour. Nothing else even comes close. Of course it's worth collecting. Let's not start restricting system architecture out of a misplaced sense of propriety. I understand where you're coming from but the fact that you even bring up dropping a field so indisputably critical to a database of personal information is a telling sign that this equality nonsense has gone too far. Acknowledging that gender exists doesn't mean that we can't treat people of different genders equally.
– Lilienthal♦
Aug 1 '16 at 8:16
27
There are plenty of databases that store gender that don't need it. Does it really matter if a meeting planner is female or male? However for certain applications such as medical applications it could be critical . It's up to the business to determine if gender is really needed. I am a woman and a strong feminist, but I would find that interpretation of the numbers as totally ridiculous and off base.
– HLGEM
Aug 1 '16 at 14:24
5
I totally agree with this, although it's one case where, if someone was really making a fuss, I'd just swap the database to use M/F/O rather than 0/1/2. I generally dislike storing strings or characters where an enumeration would do, in case the definition changes, but we're unlikely to change the words "Male" and "Female" anytime soon!
– Jon Story
Aug 5 '16 at 15:27
4
No matter how you encode gender information, it must be represented in the database as some combination of zeros and ones.
– Patricia Shanahan
Aug 5 '16 at 16:01
5
@xDaizu I have no idea if they assign people by genitalia, as I haven't seen the ones of the other guy in the room, nor did I particularly want to. I'm quite certain though, that anyone in the company claiming to be of a less-common gender would get a single room if desired. They certainly would not stick a guy with a girl just because both had a penis.
– Erik
Mar 3 '17 at 13:06
46
46
Despite what certain movements may have you believe, gender is the single most important differentiator /driver for behaviour. Nothing else even comes close. Of course it's worth collecting. Let's not start restricting system architecture out of a misplaced sense of propriety. I understand where you're coming from but the fact that you even bring up dropping a field so indisputably critical to a database of personal information is a telling sign that this equality nonsense has gone too far. Acknowledging that gender exists doesn't mean that we can't treat people of different genders equally.
– Lilienthal♦
Aug 1 '16 at 8:16
Despite what certain movements may have you believe, gender is the single most important differentiator /driver for behaviour. Nothing else even comes close. Of course it's worth collecting. Let's not start restricting system architecture out of a misplaced sense of propriety. I understand where you're coming from but the fact that you even bring up dropping a field so indisputably critical to a database of personal information is a telling sign that this equality nonsense has gone too far. Acknowledging that gender exists doesn't mean that we can't treat people of different genders equally.
– Lilienthal♦
Aug 1 '16 at 8:16
27
27
There are plenty of databases that store gender that don't need it. Does it really matter if a meeting planner is female or male? However for certain applications such as medical applications it could be critical . It's up to the business to determine if gender is really needed. I am a woman and a strong feminist, but I would find that interpretation of the numbers as totally ridiculous and off base.
– HLGEM
Aug 1 '16 at 14:24
There are plenty of databases that store gender that don't need it. Does it really matter if a meeting planner is female or male? However for certain applications such as medical applications it could be critical . It's up to the business to determine if gender is really needed. I am a woman and a strong feminist, but I would find that interpretation of the numbers as totally ridiculous and off base.
– HLGEM
Aug 1 '16 at 14:24
5
5
I totally agree with this, although it's one case where, if someone was really making a fuss, I'd just swap the database to use M/F/O rather than 0/1/2. I generally dislike storing strings or characters where an enumeration would do, in case the definition changes, but we're unlikely to change the words "Male" and "Female" anytime soon!
– Jon Story
Aug 5 '16 at 15:27
I totally agree with this, although it's one case where, if someone was really making a fuss, I'd just swap the database to use M/F/O rather than 0/1/2. I generally dislike storing strings or characters where an enumeration would do, in case the definition changes, but we're unlikely to change the words "Male" and "Female" anytime soon!
– Jon Story
Aug 5 '16 at 15:27
4
4
No matter how you encode gender information, it must be represented in the database as some combination of zeros and ones.
– Patricia Shanahan
Aug 5 '16 at 16:01
No matter how you encode gender information, it must be represented in the database as some combination of zeros and ones.
– Patricia Shanahan
Aug 5 '16 at 16:01
5
5
@xDaizu I have no idea if they assign people by genitalia, as I haven't seen the ones of the other guy in the room, nor did I particularly want to. I'm quite certain though, that anyone in the company claiming to be of a less-common gender would get a single room if desired. They certainly would not stick a guy with a girl just because both had a penis.
– Erik
Mar 3 '17 at 13:06
@xDaizu I have no idea if they assign people by genitalia, as I haven't seen the ones of the other guy in the room, nor did I particularly want to. I'm quite certain though, that anyone in the company claiming to be of a less-common gender would get a single room if desired. They certainly would not stick a guy with a girl just because both had a penis.
– Erik
Mar 3 '17 at 13:06
 |Â
show 6 more comments
up vote
46
down vote
These numbers are identifiers in a database. Database record identifiers are, by definition of their purpose, completely meaningless data. Anyone who tries to claim they mean something is almost certainly either not a software engineer or a bad software engineer.
10
To add to that: These numbers aren't even shown to end users. This is literally just an implementation detail of a backend data system. Nobody but the admins will ever see this. For all intents and purposes, it could have been "234239482034023480" for male and "35204238423048203" for female. There is no difference, and assuming that the numbers are sexist because of the order someone chose is ridiculous and absurd.
– Magisch
Aug 5 '16 at 13:13
17
Are you really suggesting that the number for a woman should be higher, and possibly seen as superior, to that of a man?
– Steve Ives
Aug 5 '16 at 13:58
4
I agree with this answer - the questions context is simply absurd. There is and should be no thought on this subject about gender discrimination/bias, it is simply back-end data and should be kept as such.
– Sh4d0wsPlyr
Aug 5 '16 at 15:23
suggest improvements |Â
up vote
46
down vote
These numbers are identifiers in a database. Database record identifiers are, by definition of their purpose, completely meaningless data. Anyone who tries to claim they mean something is almost certainly either not a software engineer or a bad software engineer.
10
To add to that: These numbers aren't even shown to end users. This is literally just an implementation detail of a backend data system. Nobody but the admins will ever see this. For all intents and purposes, it could have been "234239482034023480" for male and "35204238423048203" for female. There is no difference, and assuming that the numbers are sexist because of the order someone chose is ridiculous and absurd.
– Magisch
Aug 5 '16 at 13:13
17
Are you really suggesting that the number for a woman should be higher, and possibly seen as superior, to that of a man?
– Steve Ives
Aug 5 '16 at 13:58
4
I agree with this answer - the questions context is simply absurd. There is and should be no thought on this subject about gender discrimination/bias, it is simply back-end data and should be kept as such.
– Sh4d0wsPlyr
Aug 5 '16 at 15:23
suggest improvements |Â
up vote
46
down vote
up vote
46
down vote
These numbers are identifiers in a database. Database record identifiers are, by definition of their purpose, completely meaningless data. Anyone who tries to claim they mean something is almost certainly either not a software engineer or a bad software engineer.
These numbers are identifiers in a database. Database record identifiers are, by definition of their purpose, completely meaningless data. Anyone who tries to claim they mean something is almost certainly either not a software engineer or a bad software engineer.
answered Aug 1 '16 at 7:25


Erik
26.2k187199
26.2k187199
10
To add to that: These numbers aren't even shown to end users. This is literally just an implementation detail of a backend data system. Nobody but the admins will ever see this. For all intents and purposes, it could have been "234239482034023480" for male and "35204238423048203" for female. There is no difference, and assuming that the numbers are sexist because of the order someone chose is ridiculous and absurd.
– Magisch
Aug 5 '16 at 13:13
17
Are you really suggesting that the number for a woman should be higher, and possibly seen as superior, to that of a man?
– Steve Ives
Aug 5 '16 at 13:58
4
I agree with this answer - the questions context is simply absurd. There is and should be no thought on this subject about gender discrimination/bias, it is simply back-end data and should be kept as such.
– Sh4d0wsPlyr
Aug 5 '16 at 15:23
suggest improvements |Â
10
To add to that: These numbers aren't even shown to end users. This is literally just an implementation detail of a backend data system. Nobody but the admins will ever see this. For all intents and purposes, it could have been "234239482034023480" for male and "35204238423048203" for female. There is no difference, and assuming that the numbers are sexist because of the order someone chose is ridiculous and absurd.
– Magisch
Aug 5 '16 at 13:13
17
Are you really suggesting that the number for a woman should be higher, and possibly seen as superior, to that of a man?
– Steve Ives
Aug 5 '16 at 13:58
4
I agree with this answer - the questions context is simply absurd. There is and should be no thought on this subject about gender discrimination/bias, it is simply back-end data and should be kept as such.
– Sh4d0wsPlyr
Aug 5 '16 at 15:23
10
10
To add to that: These numbers aren't even shown to end users. This is literally just an implementation detail of a backend data system. Nobody but the admins will ever see this. For all intents and purposes, it could have been "234239482034023480" for male and "35204238423048203" for female. There is no difference, and assuming that the numbers are sexist because of the order someone chose is ridiculous and absurd.
– Magisch
Aug 5 '16 at 13:13
To add to that: These numbers aren't even shown to end users. This is literally just an implementation detail of a backend data system. Nobody but the admins will ever see this. For all intents and purposes, it could have been "234239482034023480" for male and "35204238423048203" for female. There is no difference, and assuming that the numbers are sexist because of the order someone chose is ridiculous and absurd.
– Magisch
Aug 5 '16 at 13:13
17
17
Are you really suggesting that the number for a woman should be higher, and possibly seen as superior, to that of a man?
– Steve Ives
Aug 5 '16 at 13:58
Are you really suggesting that the number for a woman should be higher, and possibly seen as superior, to that of a man?
– Steve Ives
Aug 5 '16 at 13:58
4
4
I agree with this answer - the questions context is simply absurd. There is and should be no thought on this subject about gender discrimination/bias, it is simply back-end data and should be kept as such.
– Sh4d0wsPlyr
Aug 5 '16 at 15:23
I agree with this answer - the questions context is simply absurd. There is and should be no thought on this subject about gender discrimination/bias, it is simply back-end data and should be kept as such.
– Sh4d0wsPlyr
Aug 5 '16 at 15:23
suggest improvements |Â
up vote
42
down vote
What you should do is nothing.
What you're dealing with is someone who is deliberately trying to be offended. I've dealt with this before over a different issue, where someone actually filed a union action over the colors we used in a spreadsheet. We had to dig in to stop that nonsense, and so do you.
If you change anything, then you are tacitly admitting to doing wrong. Once you do that, life at work will become very difficult for you, because there can always be more reasons invented.
Just as an example, I can make every last number offensive for one reason or another.
0 is round and could be offensive to people who are fat.
1 could be offensive because someone decides it's a phallic symbol.- See "South Park" for someone being offended by the number 2
3, 6, and 9 could all be offensive to Christians (if they so choose) because of the number of the beast.
4 because it resembles a knife
7 because it resembles a gun8 because its hour-glass shape promotes a certain body shape.
...which leaves five, and if I thought about it long enough I could make that offensive as well.
It may cause you some short-term discomfort, but if you give into one silly demand, there will be no end of it for you. Again, for emphasis. If you change what you have, you are admitting to wrong doing, whether you realize it or not. Once you've got that label slapped on you the next complaint will have more force because you have a "history of bigoted behavior" or some other nonsense.
Stand your ground and dismiss your coworker's concerns as the trouble-making disruption it is.
13
Problem solved! Use 5 for Female, 55 for Male and 555 for Other.
– Ouroboros
Aug 5 '16 at 14:23
@Ouroboros some are more equal than others.
– user37746
Sep 15 '16 at 11:27
4
+2 for your whole answer, loved it; but -1 for "do nothing". If any number can be offensive and it doesn't matter, you might as well go standard. :D Seriously, any excuse is good for that...
– xDaizu
Mar 2 '17 at 16:28
@xDaizu Great article. Would you mind if I included that in my answer? I'll give you the credit.
– Richard U
Mar 2 '17 at 21:21
@RichardU Sure, go ahead ^^
– xDaizu
Mar 2 '17 at 22:39
suggest improvements |Â
up vote
42
down vote
What you should do is nothing.
What you're dealing with is someone who is deliberately trying to be offended. I've dealt with this before over a different issue, where someone actually filed a union action over the colors we used in a spreadsheet. We had to dig in to stop that nonsense, and so do you.
If you change anything, then you are tacitly admitting to doing wrong. Once you do that, life at work will become very difficult for you, because there can always be more reasons invented.
Just as an example, I can make every last number offensive for one reason or another.
0 is round and could be offensive to people who are fat.
1 could be offensive because someone decides it's a phallic symbol.- See "South Park" for someone being offended by the number 2
3, 6, and 9 could all be offensive to Christians (if they so choose) because of the number of the beast.
4 because it resembles a knife
7 because it resembles a gun8 because its hour-glass shape promotes a certain body shape.
...which leaves five, and if I thought about it long enough I could make that offensive as well.
It may cause you some short-term discomfort, but if you give into one silly demand, there will be no end of it for you. Again, for emphasis. If you change what you have, you are admitting to wrong doing, whether you realize it or not. Once you've got that label slapped on you the next complaint will have more force because you have a "history of bigoted behavior" or some other nonsense.
Stand your ground and dismiss your coworker's concerns as the trouble-making disruption it is.
13
Problem solved! Use 5 for Female, 55 for Male and 555 for Other.
– Ouroboros
Aug 5 '16 at 14:23
@Ouroboros some are more equal than others.
– user37746
Sep 15 '16 at 11:27
4
+2 for your whole answer, loved it; but -1 for "do nothing". If any number can be offensive and it doesn't matter, you might as well go standard. :D Seriously, any excuse is good for that...
– xDaizu
Mar 2 '17 at 16:28
@xDaizu Great article. Would you mind if I included that in my answer? I'll give you the credit.
– Richard U
Mar 2 '17 at 21:21
@RichardU Sure, go ahead ^^
– xDaizu
Mar 2 '17 at 22:39
suggest improvements |Â
up vote
42
down vote
up vote
42
down vote
What you should do is nothing.
What you're dealing with is someone who is deliberately trying to be offended. I've dealt with this before over a different issue, where someone actually filed a union action over the colors we used in a spreadsheet. We had to dig in to stop that nonsense, and so do you.
If you change anything, then you are tacitly admitting to doing wrong. Once you do that, life at work will become very difficult for you, because there can always be more reasons invented.
Just as an example, I can make every last number offensive for one reason or another.
0 is round and could be offensive to people who are fat.
1 could be offensive because someone decides it's a phallic symbol.- See "South Park" for someone being offended by the number 2
3, 6, and 9 could all be offensive to Christians (if they so choose) because of the number of the beast.
4 because it resembles a knife
7 because it resembles a gun8 because its hour-glass shape promotes a certain body shape.
...which leaves five, and if I thought about it long enough I could make that offensive as well.
It may cause you some short-term discomfort, but if you give into one silly demand, there will be no end of it for you. Again, for emphasis. If you change what you have, you are admitting to wrong doing, whether you realize it or not. Once you've got that label slapped on you the next complaint will have more force because you have a "history of bigoted behavior" or some other nonsense.
Stand your ground and dismiss your coworker's concerns as the trouble-making disruption it is.
What you should do is nothing.
What you're dealing with is someone who is deliberately trying to be offended. I've dealt with this before over a different issue, where someone actually filed a union action over the colors we used in a spreadsheet. We had to dig in to stop that nonsense, and so do you.
If you change anything, then you are tacitly admitting to doing wrong. Once you do that, life at work will become very difficult for you, because there can always be more reasons invented.
Just as an example, I can make every last number offensive for one reason or another.
0 is round and could be offensive to people who are fat.
1 could be offensive because someone decides it's a phallic symbol.- See "South Park" for someone being offended by the number 2
3, 6, and 9 could all be offensive to Christians (if they so choose) because of the number of the beast.
4 because it resembles a knife
7 because it resembles a gun8 because its hour-glass shape promotes a certain body shape.
...which leaves five, and if I thought about it long enough I could make that offensive as well.
It may cause you some short-term discomfort, but if you give into one silly demand, there will be no end of it for you. Again, for emphasis. If you change what you have, you are admitting to wrong doing, whether you realize it or not. Once you've got that label slapped on you the next complaint will have more force because you have a "history of bigoted behavior" or some other nonsense.
Stand your ground and dismiss your coworker's concerns as the trouble-making disruption it is.
edited Jul 31 at 12:26
answered Aug 5 '16 at 13:33


Richard U
77.2k56200307
77.2k56200307
13
Problem solved! Use 5 for Female, 55 for Male and 555 for Other.
– Ouroboros
Aug 5 '16 at 14:23
@Ouroboros some are more equal than others.
– user37746
Sep 15 '16 at 11:27
4
+2 for your whole answer, loved it; but -1 for "do nothing". If any number can be offensive and it doesn't matter, you might as well go standard. :D Seriously, any excuse is good for that...
– xDaizu
Mar 2 '17 at 16:28
@xDaizu Great article. Would you mind if I included that in my answer? I'll give you the credit.
– Richard U
Mar 2 '17 at 21:21
@RichardU Sure, go ahead ^^
– xDaizu
Mar 2 '17 at 22:39
suggest improvements |Â
13
Problem solved! Use 5 for Female, 55 for Male and 555 for Other.
– Ouroboros
Aug 5 '16 at 14:23
@Ouroboros some are more equal than others.
– user37746
Sep 15 '16 at 11:27
4
+2 for your whole answer, loved it; but -1 for "do nothing". If any number can be offensive and it doesn't matter, you might as well go standard. :D Seriously, any excuse is good for that...
– xDaizu
Mar 2 '17 at 16:28
@xDaizu Great article. Would you mind if I included that in my answer? I'll give you the credit.
– Richard U
Mar 2 '17 at 21:21
@RichardU Sure, go ahead ^^
– xDaizu
Mar 2 '17 at 22:39
13
13
Problem solved! Use 5 for Female, 55 for Male and 555 for Other.
– Ouroboros
Aug 5 '16 at 14:23
Problem solved! Use 5 for Female, 55 for Male and 555 for Other.
– Ouroboros
Aug 5 '16 at 14:23
@Ouroboros some are more equal than others.
– user37746
Sep 15 '16 at 11:27
@Ouroboros some are more equal than others.
– user37746
Sep 15 '16 at 11:27
4
4
+2 for your whole answer, loved it; but -1 for "do nothing". If any number can be offensive and it doesn't matter, you might as well go standard. :D Seriously, any excuse is good for that...
– xDaizu
Mar 2 '17 at 16:28
+2 for your whole answer, loved it; but -1 for "do nothing". If any number can be offensive and it doesn't matter, you might as well go standard. :D Seriously, any excuse is good for that...
– xDaizu
Mar 2 '17 at 16:28
@xDaizu Great article. Would you mind if I included that in my answer? I'll give you the credit.
– Richard U
Mar 2 '17 at 21:21
@xDaizu Great article. Would you mind if I included that in my answer? I'll give you the credit.
– Richard U
Mar 2 '17 at 21:21
@RichardU Sure, go ahead ^^
– xDaizu
Mar 2 '17 at 22:39
@RichardU Sure, go ahead ^^
– xDaizu
Mar 2 '17 at 22:39
suggest improvements |Â
up vote
33
down vote
As it is usually the case in IT, just go standard. Use the ISO/IEC 5218
The four codes specified in ISO/IEC 5218 are:
0 = not known, 1 = male, 2 = female, 9 = not applicable.
The standard specifies that its use may be referred to by the
designator "SEX".
Fun note: Even though the ISO explicitely says that no significance is to be placed on the encoding of male as 1 and female as 2
, since we are not using the problematic 0, males can say that they are number one while females can say they are twice as good, so that should make everyone happy... right? :)
suggest improvements |Â
up vote
33
down vote
As it is usually the case in IT, just go standard. Use the ISO/IEC 5218
The four codes specified in ISO/IEC 5218 are:
0 = not known, 1 = male, 2 = female, 9 = not applicable.
The standard specifies that its use may be referred to by the
designator "SEX".
Fun note: Even though the ISO explicitely says that no significance is to be placed on the encoding of male as 1 and female as 2
, since we are not using the problematic 0, males can say that they are number one while females can say they are twice as good, so that should make everyone happy... right? :)
suggest improvements |Â
up vote
33
down vote
up vote
33
down vote
As it is usually the case in IT, just go standard. Use the ISO/IEC 5218
The four codes specified in ISO/IEC 5218 are:
0 = not known, 1 = male, 2 = female, 9 = not applicable.
The standard specifies that its use may be referred to by the
designator "SEX".
Fun note: Even though the ISO explicitely says that no significance is to be placed on the encoding of male as 1 and female as 2
, since we are not using the problematic 0, males can say that they are number one while females can say they are twice as good, so that should make everyone happy... right? :)
As it is usually the case in IT, just go standard. Use the ISO/IEC 5218
The four codes specified in ISO/IEC 5218 are:
0 = not known, 1 = male, 2 = female, 9 = not applicable.
The standard specifies that its use may be referred to by the
designator "SEX".
Fun note: Even though the ISO explicitely says that no significance is to be placed on the encoding of male as 1 and female as 2
, since we are not using the problematic 0, males can say that they are number one while females can say they are twice as good, so that should make everyone happy... right? :)
edited Mar 2 '17 at 20:02
answered Mar 2 '17 at 15:12


xDaizu
645611
645611
suggest improvements |Â
suggest improvements |Â
up vote
13
down vote
It's an enumeration of values to allow it to be stored in the database. No developer is going to notice or care that female is represented by 0 and male by 1, and this fact should never be exposed to the end user.
If possible, it might be better to store it in a char(1)... that way you can query it using something like WHERE gender = 'F'
rather than WHERE gender = 0
. It sorts out your friends issue with it and also provides greater ease of use for future development.
6
Ah but this would still be sexist, because F still has a lower ASCII value (70) than M (77). It might be safer to use M/W (Man/Woman) because W has a value of (87) :) :)
– Jon Story
Aug 5 '16 at 15:30
3
Using a char(1) could have unforseen knockon effects with regard to collation and character sets, whereas ints will not.
– Moo
Aug 5 '16 at 16:05
@Moo Provided the app is designed to handle a char(1) instead of an int, I don't see why it would be an issue. What sort of problem did you have in mind?
– Maybe_Factor
Aug 8 '16 at 2:01
3
@JonStory AnM
has two peaks, while anW
just have one (and, dependent on the font, it's a lower peak). Subtle way you have to remind everyone that there are more men in "top positions", huh? :) :)
– xDaizu
Mar 2 '17 at 16:30
Looking at the W, I see three peaks...
– gnasher729
Aug 1 at 23:27
suggest improvements |Â
up vote
13
down vote
It's an enumeration of values to allow it to be stored in the database. No developer is going to notice or care that female is represented by 0 and male by 1, and this fact should never be exposed to the end user.
If possible, it might be better to store it in a char(1)... that way you can query it using something like WHERE gender = 'F'
rather than WHERE gender = 0
. It sorts out your friends issue with it and also provides greater ease of use for future development.
6
Ah but this would still be sexist, because F still has a lower ASCII value (70) than M (77). It might be safer to use M/W (Man/Woman) because W has a value of (87) :) :)
– Jon Story
Aug 5 '16 at 15:30
3
Using a char(1) could have unforseen knockon effects with regard to collation and character sets, whereas ints will not.
– Moo
Aug 5 '16 at 16:05
@Moo Provided the app is designed to handle a char(1) instead of an int, I don't see why it would be an issue. What sort of problem did you have in mind?
– Maybe_Factor
Aug 8 '16 at 2:01
3
@JonStory AnM
has two peaks, while anW
just have one (and, dependent on the font, it's a lower peak). Subtle way you have to remind everyone that there are more men in "top positions", huh? :) :)
– xDaizu
Mar 2 '17 at 16:30
Looking at the W, I see three peaks...
– gnasher729
Aug 1 at 23:27
suggest improvements |Â
up vote
13
down vote
up vote
13
down vote
It's an enumeration of values to allow it to be stored in the database. No developer is going to notice or care that female is represented by 0 and male by 1, and this fact should never be exposed to the end user.
If possible, it might be better to store it in a char(1)... that way you can query it using something like WHERE gender = 'F'
rather than WHERE gender = 0
. It sorts out your friends issue with it and also provides greater ease of use for future development.
It's an enumeration of values to allow it to be stored in the database. No developer is going to notice or care that female is represented by 0 and male by 1, and this fact should never be exposed to the end user.
If possible, it might be better to store it in a char(1)... that way you can query it using something like WHERE gender = 'F'
rather than WHERE gender = 0
. It sorts out your friends issue with it and also provides greater ease of use for future development.
edited Aug 5 '16 at 15:00
Monica Cellio♦
43.6k17114191
43.6k17114191
answered Aug 1 '16 at 5:50
Maybe_Factor
1,221411
1,221411
6
Ah but this would still be sexist, because F still has a lower ASCII value (70) than M (77). It might be safer to use M/W (Man/Woman) because W has a value of (87) :) :)
– Jon Story
Aug 5 '16 at 15:30
3
Using a char(1) could have unforseen knockon effects with regard to collation and character sets, whereas ints will not.
– Moo
Aug 5 '16 at 16:05
@Moo Provided the app is designed to handle a char(1) instead of an int, I don't see why it would be an issue. What sort of problem did you have in mind?
– Maybe_Factor
Aug 8 '16 at 2:01
3
@JonStory AnM
has two peaks, while anW
just have one (and, dependent on the font, it's a lower peak). Subtle way you have to remind everyone that there are more men in "top positions", huh? :) :)
– xDaizu
Mar 2 '17 at 16:30
Looking at the W, I see three peaks...
– gnasher729
Aug 1 at 23:27
suggest improvements |Â
6
Ah but this would still be sexist, because F still has a lower ASCII value (70) than M (77). It might be safer to use M/W (Man/Woman) because W has a value of (87) :) :)
– Jon Story
Aug 5 '16 at 15:30
3
Using a char(1) could have unforseen knockon effects with regard to collation and character sets, whereas ints will not.
– Moo
Aug 5 '16 at 16:05
@Moo Provided the app is designed to handle a char(1) instead of an int, I don't see why it would be an issue. What sort of problem did you have in mind?
– Maybe_Factor
Aug 8 '16 at 2:01
3
@JonStory AnM
has two peaks, while anW
just have one (and, dependent on the font, it's a lower peak). Subtle way you have to remind everyone that there are more men in "top positions", huh? :) :)
– xDaizu
Mar 2 '17 at 16:30
Looking at the W, I see three peaks...
– gnasher729
Aug 1 at 23:27
6
6
Ah but this would still be sexist, because F still has a lower ASCII value (70) than M (77). It might be safer to use M/W (Man/Woman) because W has a value of (87) :) :)
– Jon Story
Aug 5 '16 at 15:30
Ah but this would still be sexist, because F still has a lower ASCII value (70) than M (77). It might be safer to use M/W (Man/Woman) because W has a value of (87) :) :)
– Jon Story
Aug 5 '16 at 15:30
3
3
Using a char(1) could have unforseen knockon effects with regard to collation and character sets, whereas ints will not.
– Moo
Aug 5 '16 at 16:05
Using a char(1) could have unforseen knockon effects with regard to collation and character sets, whereas ints will not.
– Moo
Aug 5 '16 at 16:05
@Moo Provided the app is designed to handle a char(1) instead of an int, I don't see why it would be an issue. What sort of problem did you have in mind?
– Maybe_Factor
Aug 8 '16 at 2:01
@Moo Provided the app is designed to handle a char(1) instead of an int, I don't see why it would be an issue. What sort of problem did you have in mind?
– Maybe_Factor
Aug 8 '16 at 2:01
3
3
@JonStory An
M
has two peaks, while an W
just have one (and, dependent on the font, it's a lower peak). Subtle way you have to remind everyone that there are more men in "top positions", huh? :) :)– xDaizu
Mar 2 '17 at 16:30
@JonStory An
M
has two peaks, while an W
just have one (and, dependent on the font, it's a lower peak). Subtle way you have to remind everyone that there are more men in "top positions", huh? :) :)– xDaizu
Mar 2 '17 at 16:30
Looking at the W, I see three peaks...
– gnasher729
Aug 1 at 23:27
Looking at the W, I see three peaks...
– gnasher729
Aug 1 at 23:27
suggest improvements |Â
up vote
9
down vote
As 2 stands for other (or not sure) people might deem this (somewhat) Transphobic or outright rude and / or offensive.
While the other two points look like someone actively trying to find fault for the sake of finding fault, there's no reason to limit yourself to a tristate with this as the 3rd option. If you want to be more inclusive look at the expansive lists of options sites like Facebook provide beyond male/female and offer the same. Facebook apparently is up to 71 options. I'd provide a direct link; except the only 3rd party sites I can find listing them all have highly negative reactions to the idea.
I would add to this that letting users define their own gender and pronouns would be very inclusive. Having lots of defaults is great, but whatever boxes you make, someone won't feel right in them.
– Andrew Piliser
Aug 5 '16 at 18:04
suggest improvements |Â
up vote
9
down vote
As 2 stands for other (or not sure) people might deem this (somewhat) Transphobic or outright rude and / or offensive.
While the other two points look like someone actively trying to find fault for the sake of finding fault, there's no reason to limit yourself to a tristate with this as the 3rd option. If you want to be more inclusive look at the expansive lists of options sites like Facebook provide beyond male/female and offer the same. Facebook apparently is up to 71 options. I'd provide a direct link; except the only 3rd party sites I can find listing them all have highly negative reactions to the idea.
I would add to this that letting users define their own gender and pronouns would be very inclusive. Having lots of defaults is great, but whatever boxes you make, someone won't feel right in them.
– Andrew Piliser
Aug 5 '16 at 18:04
suggest improvements |Â
up vote
9
down vote
up vote
9
down vote
As 2 stands for other (or not sure) people might deem this (somewhat) Transphobic or outright rude and / or offensive.
While the other two points look like someone actively trying to find fault for the sake of finding fault, there's no reason to limit yourself to a tristate with this as the 3rd option. If you want to be more inclusive look at the expansive lists of options sites like Facebook provide beyond male/female and offer the same. Facebook apparently is up to 71 options. I'd provide a direct link; except the only 3rd party sites I can find listing them all have highly negative reactions to the idea.
As 2 stands for other (or not sure) people might deem this (somewhat) Transphobic or outright rude and / or offensive.
While the other two points look like someone actively trying to find fault for the sake of finding fault, there's no reason to limit yourself to a tristate with this as the 3rd option. If you want to be more inclusive look at the expansive lists of options sites like Facebook provide beyond male/female and offer the same. Facebook apparently is up to 71 options. I'd provide a direct link; except the only 3rd party sites I can find listing them all have highly negative reactions to the idea.
answered Aug 1 '16 at 5:51
Dan Neely
3,08111527
3,08111527
I would add to this that letting users define their own gender and pronouns would be very inclusive. Having lots of defaults is great, but whatever boxes you make, someone won't feel right in them.
– Andrew Piliser
Aug 5 '16 at 18:04
suggest improvements |Â
I would add to this that letting users define their own gender and pronouns would be very inclusive. Having lots of defaults is great, but whatever boxes you make, someone won't feel right in them.
– Andrew Piliser
Aug 5 '16 at 18:04
I would add to this that letting users define their own gender and pronouns would be very inclusive. Having lots of defaults is great, but whatever boxes you make, someone won't feel right in them.
– Andrew Piliser
Aug 5 '16 at 18:04
I would add to this that letting users define their own gender and pronouns would be very inclusive. Having lots of defaults is great, but whatever boxes you make, someone won't feel right in them.
– Andrew Piliser
Aug 5 '16 at 18:04
suggest improvements |Â
up vote
6
down vote
In summary, the question I'd like answered is the following: Is it appropriate to collect data regarding one's gender using only a select few gender types (Male and Female), and group the rest into an 'Other' category?
That depends on why you are collecting that data in the first place. Data models aren't supposed to fulfill political correctness needs, they are supposed to fulfill business needs.
So what exactly is the business need for the gender field?
Do you want to be able to use the correct honorifics and pronouns when communicating with users? Then save the pronouns and honorifics.
Do you need it for some marketing analysis? Then you might indeed have a business case for using a more complicated representation of sex/gender identity, because people with non-standard identities are demographics with non-standard consumer behavior.
Are you building a dating app? Most dating services have a clear binary distinction how the user self-identifies and what partners they are looking for. Dating for people with non-binary gender identity and/or preference is a rather specialized market segment. Ask your management if catering to this segment is part of their business plan. If they do, there are two solutions. Either invent a super-complex system to match people who might be interested in dating each other, or just drop the gender-information altogether and let people decide based on profiles alone.
Is it for reporting to some 3rd party? Then report in the format that 3rd party wants.
2
+1 "Data models aren't supposed to fulfill political correctness needs, they are supposed to fulfill business needs."
– A. I. Breveleri
Mar 3 '17 at 23:10
suggest improvements |Â
up vote
6
down vote
In summary, the question I'd like answered is the following: Is it appropriate to collect data regarding one's gender using only a select few gender types (Male and Female), and group the rest into an 'Other' category?
That depends on why you are collecting that data in the first place. Data models aren't supposed to fulfill political correctness needs, they are supposed to fulfill business needs.
So what exactly is the business need for the gender field?
Do you want to be able to use the correct honorifics and pronouns when communicating with users? Then save the pronouns and honorifics.
Do you need it for some marketing analysis? Then you might indeed have a business case for using a more complicated representation of sex/gender identity, because people with non-standard identities are demographics with non-standard consumer behavior.
Are you building a dating app? Most dating services have a clear binary distinction how the user self-identifies and what partners they are looking for. Dating for people with non-binary gender identity and/or preference is a rather specialized market segment. Ask your management if catering to this segment is part of their business plan. If they do, there are two solutions. Either invent a super-complex system to match people who might be interested in dating each other, or just drop the gender-information altogether and let people decide based on profiles alone.
Is it for reporting to some 3rd party? Then report in the format that 3rd party wants.
2
+1 "Data models aren't supposed to fulfill political correctness needs, they are supposed to fulfill business needs."
– A. I. Breveleri
Mar 3 '17 at 23:10
suggest improvements |Â
up vote
6
down vote
up vote
6
down vote
In summary, the question I'd like answered is the following: Is it appropriate to collect data regarding one's gender using only a select few gender types (Male and Female), and group the rest into an 'Other' category?
That depends on why you are collecting that data in the first place. Data models aren't supposed to fulfill political correctness needs, they are supposed to fulfill business needs.
So what exactly is the business need for the gender field?
Do you want to be able to use the correct honorifics and pronouns when communicating with users? Then save the pronouns and honorifics.
Do you need it for some marketing analysis? Then you might indeed have a business case for using a more complicated representation of sex/gender identity, because people with non-standard identities are demographics with non-standard consumer behavior.
Are you building a dating app? Most dating services have a clear binary distinction how the user self-identifies and what partners they are looking for. Dating for people with non-binary gender identity and/or preference is a rather specialized market segment. Ask your management if catering to this segment is part of their business plan. If they do, there are two solutions. Either invent a super-complex system to match people who might be interested in dating each other, or just drop the gender-information altogether and let people decide based on profiles alone.
Is it for reporting to some 3rd party? Then report in the format that 3rd party wants.
In summary, the question I'd like answered is the following: Is it appropriate to collect data regarding one's gender using only a select few gender types (Male and Female), and group the rest into an 'Other' category?
That depends on why you are collecting that data in the first place. Data models aren't supposed to fulfill political correctness needs, they are supposed to fulfill business needs.
So what exactly is the business need for the gender field?
Do you want to be able to use the correct honorifics and pronouns when communicating with users? Then save the pronouns and honorifics.
Do you need it for some marketing analysis? Then you might indeed have a business case for using a more complicated representation of sex/gender identity, because people with non-standard identities are demographics with non-standard consumer behavior.
Are you building a dating app? Most dating services have a clear binary distinction how the user self-identifies and what partners they are looking for. Dating for people with non-binary gender identity and/or preference is a rather specialized market segment. Ask your management if catering to this segment is part of their business plan. If they do, there are two solutions. Either invent a super-complex system to match people who might be interested in dating each other, or just drop the gender-information altogether and let people decide based on profiles alone.
Is it for reporting to some 3rd party? Then report in the format that 3rd party wants.
edited Mar 3 '17 at 14:52
answered Mar 3 '17 at 14:41
Philipp
20.3k34884
20.3k34884
2
+1 "Data models aren't supposed to fulfill political correctness needs, they are supposed to fulfill business needs."
– A. I. Breveleri
Mar 3 '17 at 23:10
suggest improvements |Â
2
+1 "Data models aren't supposed to fulfill political correctness needs, they are supposed to fulfill business needs."
– A. I. Breveleri
Mar 3 '17 at 23:10
2
2
+1 "Data models aren't supposed to fulfill political correctness needs, they are supposed to fulfill business needs."
– A. I. Breveleri
Mar 3 '17 at 23:10
+1 "Data models aren't supposed to fulfill political correctness needs, they are supposed to fulfill business needs."
– A. I. Breveleri
Mar 3 '17 at 23:10
suggest improvements |Â
up vote
2
down vote
Personally, I think your co-worker is overthinking it, as others have already said. Now, more inline with regards to your classification of genders, I have seen some systems user the following five:
Male, Female, Other Specific, Not Known, Not Specified
This number is not a set rule by any means; in fact, for simplicity, I would go with Not Specified for the third and final option.
suggest improvements |Â
up vote
2
down vote
Personally, I think your co-worker is overthinking it, as others have already said. Now, more inline with regards to your classification of genders, I have seen some systems user the following five:
Male, Female, Other Specific, Not Known, Not Specified
This number is not a set rule by any means; in fact, for simplicity, I would go with Not Specified for the third and final option.
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
Personally, I think your co-worker is overthinking it, as others have already said. Now, more inline with regards to your classification of genders, I have seen some systems user the following five:
Male, Female, Other Specific, Not Known, Not Specified
This number is not a set rule by any means; in fact, for simplicity, I would go with Not Specified for the third and final option.
Personally, I think your co-worker is overthinking it, as others have already said. Now, more inline with regards to your classification of genders, I have seen some systems user the following five:
Male, Female, Other Specific, Not Known, Not Specified
This number is not a set rule by any means; in fact, for simplicity, I would go with Not Specified for the third and final option.
answered Aug 1 '16 at 6:10


Blueshift
372
372
suggest improvements |Â
suggest improvements |Â
up vote
2
down vote
You have social options and technical options.
Socially, you can just ignore your friend's opinion. She is not on the team and you were just showing her your code and she "went there."
Or, you (and your team) could decide to make a change to (hopefully) avoid the issue. You have a couple of technical options available to you. This assumes your business requirements are not able to be changed with respect to whether and how gender must be tracked.
Use strings instead of ordinal values. Of course if you use this field as a key, or frequently in joins, your queries might be a few milliseconds slower, which can add up.
Change the ordinal values of your enumeration to be large numbers. The actual value probably doesn't matter. It takes no more CPU effort to compare a large number as it does to compare a small one. If you're using a 32-bit integer, you have 4 billion numbers to pick from. Of course, you should take care that your numbers do not differ by only a 1 or a 0, because we just cannot un-see this post!
suggest improvements |Â
up vote
2
down vote
You have social options and technical options.
Socially, you can just ignore your friend's opinion. She is not on the team and you were just showing her your code and she "went there."
Or, you (and your team) could decide to make a change to (hopefully) avoid the issue. You have a couple of technical options available to you. This assumes your business requirements are not able to be changed with respect to whether and how gender must be tracked.
Use strings instead of ordinal values. Of course if you use this field as a key, or frequently in joins, your queries might be a few milliseconds slower, which can add up.
Change the ordinal values of your enumeration to be large numbers. The actual value probably doesn't matter. It takes no more CPU effort to compare a large number as it does to compare a small one. If you're using a 32-bit integer, you have 4 billion numbers to pick from. Of course, you should take care that your numbers do not differ by only a 1 or a 0, because we just cannot un-see this post!
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
You have social options and technical options.
Socially, you can just ignore your friend's opinion. She is not on the team and you were just showing her your code and she "went there."
Or, you (and your team) could decide to make a change to (hopefully) avoid the issue. You have a couple of technical options available to you. This assumes your business requirements are not able to be changed with respect to whether and how gender must be tracked.
Use strings instead of ordinal values. Of course if you use this field as a key, or frequently in joins, your queries might be a few milliseconds slower, which can add up.
Change the ordinal values of your enumeration to be large numbers. The actual value probably doesn't matter. It takes no more CPU effort to compare a large number as it does to compare a small one. If you're using a 32-bit integer, you have 4 billion numbers to pick from. Of course, you should take care that your numbers do not differ by only a 1 or a 0, because we just cannot un-see this post!
You have social options and technical options.
Socially, you can just ignore your friend's opinion. She is not on the team and you were just showing her your code and she "went there."
Or, you (and your team) could decide to make a change to (hopefully) avoid the issue. You have a couple of technical options available to you. This assumes your business requirements are not able to be changed with respect to whether and how gender must be tracked.
Use strings instead of ordinal values. Of course if you use this field as a key, or frequently in joins, your queries might be a few milliseconds slower, which can add up.
Change the ordinal values of your enumeration to be large numbers. The actual value probably doesn't matter. It takes no more CPU effort to compare a large number as it does to compare a small one. If you're using a 32-bit integer, you have 4 billion numbers to pick from. Of course, you should take care that your numbers do not differ by only a 1 or a 0, because we just cannot un-see this post!
edited Aug 5 '16 at 12:59
answered Aug 5 '16 at 12:52
Kent A.
18.9k75474
18.9k75474
suggest improvements |Â
suggest improvements |Â
up vote
0
down vote
I think you are WAY overthinking this.
Whatever you put into the database for the primary key is going to have to have a unique value. Numbers, characters. The computer is a calculator. It deals with numbers.
Accordingly, having unique numeric values implies that each value will have different properties. Some will be less than others. Some will be greater. Some will be primes. Some will not. Some will have one digit, others will have two. We can go on with this ad infinitum, and if we take the OP's approach then it sorta says it's sane for us to mince how the qualities (as described) of these values somehow "ding" the worth of the genders they're associated with in the data.
It's like the old saying of how some people say "tomaTOE", vs "toMAHto". Remarkable, brow-raising?? Slightly. High in value, in the long term? Hmm, probably not. Epic, long-term, cataclysmic effects with the globe spinning off its axis?? SMH.
suggest improvements |Â
up vote
0
down vote
I think you are WAY overthinking this.
Whatever you put into the database for the primary key is going to have to have a unique value. Numbers, characters. The computer is a calculator. It deals with numbers.
Accordingly, having unique numeric values implies that each value will have different properties. Some will be less than others. Some will be greater. Some will be primes. Some will not. Some will have one digit, others will have two. We can go on with this ad infinitum, and if we take the OP's approach then it sorta says it's sane for us to mince how the qualities (as described) of these values somehow "ding" the worth of the genders they're associated with in the data.
It's like the old saying of how some people say "tomaTOE", vs "toMAHto". Remarkable, brow-raising?? Slightly. High in value, in the long term? Hmm, probably not. Epic, long-term, cataclysmic effects with the globe spinning off its axis?? SMH.
suggest improvements |Â
up vote
0
down vote
up vote
0
down vote
I think you are WAY overthinking this.
Whatever you put into the database for the primary key is going to have to have a unique value. Numbers, characters. The computer is a calculator. It deals with numbers.
Accordingly, having unique numeric values implies that each value will have different properties. Some will be less than others. Some will be greater. Some will be primes. Some will not. Some will have one digit, others will have two. We can go on with this ad infinitum, and if we take the OP's approach then it sorta says it's sane for us to mince how the qualities (as described) of these values somehow "ding" the worth of the genders they're associated with in the data.
It's like the old saying of how some people say "tomaTOE", vs "toMAHto". Remarkable, brow-raising?? Slightly. High in value, in the long term? Hmm, probably not. Epic, long-term, cataclysmic effects with the globe spinning off its axis?? SMH.
I think you are WAY overthinking this.
Whatever you put into the database for the primary key is going to have to have a unique value. Numbers, characters. The computer is a calculator. It deals with numbers.
Accordingly, having unique numeric values implies that each value will have different properties. Some will be less than others. Some will be greater. Some will be primes. Some will not. Some will have one digit, others will have two. We can go on with this ad infinitum, and if we take the OP's approach then it sorta says it's sane for us to mince how the qualities (as described) of these values somehow "ding" the worth of the genders they're associated with in the data.
It's like the old saying of how some people say "tomaTOE", vs "toMAHto". Remarkable, brow-raising?? Slightly. High in value, in the long term? Hmm, probably not. Epic, long-term, cataclysmic effects with the globe spinning off its axis?? SMH.
answered Aug 5 '16 at 15:57


Xavier J
26.3k104797
26.3k104797
suggest improvements |Â
suggest improvements |Â
up vote
0
down vote
I was recently showing my friend the project and she pointed out that other people who see this data might deem this sexist, as it doesn't include many identifiable gender types.
That's because your friend is talking about the product, not your technical problem of implementing the product. Your friend is, evidently, of the opinion that your app, website, service, or whatever should be representing gender differently. Your friend probably does not mean to offend your specific job of implementing the 3 options in a database in some way that reflects the decision made by product.
If you have sway in the product, you might consider exercising it. Many businesses have greatly benefited from gender inclusiveness in their product and marketing (source: just watching subway ads reach out to trans people).
If you have 3 gender options you need to implement, then you don't have any social theory problem, just a product you need to implement in the backend, and apply your usual engineering knowledge for naming things with relatively little political implication.
suggest improvements |Â
up vote
0
down vote
I was recently showing my friend the project and she pointed out that other people who see this data might deem this sexist, as it doesn't include many identifiable gender types.
That's because your friend is talking about the product, not your technical problem of implementing the product. Your friend is, evidently, of the opinion that your app, website, service, or whatever should be representing gender differently. Your friend probably does not mean to offend your specific job of implementing the 3 options in a database in some way that reflects the decision made by product.
If you have sway in the product, you might consider exercising it. Many businesses have greatly benefited from gender inclusiveness in their product and marketing (source: just watching subway ads reach out to trans people).
If you have 3 gender options you need to implement, then you don't have any social theory problem, just a product you need to implement in the backend, and apply your usual engineering knowledge for naming things with relatively little political implication.
suggest improvements |Â
up vote
0
down vote
up vote
0
down vote
I was recently showing my friend the project and she pointed out that other people who see this data might deem this sexist, as it doesn't include many identifiable gender types.
That's because your friend is talking about the product, not your technical problem of implementing the product. Your friend is, evidently, of the opinion that your app, website, service, or whatever should be representing gender differently. Your friend probably does not mean to offend your specific job of implementing the 3 options in a database in some way that reflects the decision made by product.
If you have sway in the product, you might consider exercising it. Many businesses have greatly benefited from gender inclusiveness in their product and marketing (source: just watching subway ads reach out to trans people).
If you have 3 gender options you need to implement, then you don't have any social theory problem, just a product you need to implement in the backend, and apply your usual engineering knowledge for naming things with relatively little political implication.
I was recently showing my friend the project and she pointed out that other people who see this data might deem this sexist, as it doesn't include many identifiable gender types.
That's because your friend is talking about the product, not your technical problem of implementing the product. Your friend is, evidently, of the opinion that your app, website, service, or whatever should be representing gender differently. Your friend probably does not mean to offend your specific job of implementing the 3 options in a database in some way that reflects the decision made by product.
If you have sway in the product, you might consider exercising it. Many businesses have greatly benefited from gender inclusiveness in their product and marketing (source: just watching subway ads reach out to trans people).
If you have 3 gender options you need to implement, then you don't have any social theory problem, just a product you need to implement in the backend, and apply your usual engineering knowledge for naming things with relatively little political implication.
answered Mar 3 '17 at 15:12
user42272
suggest improvements |Â
suggest improvements |Â
up vote
0
down vote
You don't change your application (which may have significant cost for development and testing) unless someone complains who is actually affected, gives a reason that actually justifies the cost, and if your boss tells you to make the change.
The somehow justified complaint that someone who isn't male or female would have to choose a category "other" that makes them somehow stand out can be solved: Change "other" to "unknown, undisclosed, or other". And then you can volunteer to not disclose your gender so nobody needs to be the only person in that category.
And change the question from "which are you" to "which describes you best", so someone who sees themselves 60/40 between two genders can pick the 60% case without having to make a compromise.
suggest improvements |Â
up vote
0
down vote
You don't change your application (which may have significant cost for development and testing) unless someone complains who is actually affected, gives a reason that actually justifies the cost, and if your boss tells you to make the change.
The somehow justified complaint that someone who isn't male or female would have to choose a category "other" that makes them somehow stand out can be solved: Change "other" to "unknown, undisclosed, or other". And then you can volunteer to not disclose your gender so nobody needs to be the only person in that category.
And change the question from "which are you" to "which describes you best", so someone who sees themselves 60/40 between two genders can pick the 60% case without having to make a compromise.
suggest improvements |Â
up vote
0
down vote
up vote
0
down vote
You don't change your application (which may have significant cost for development and testing) unless someone complains who is actually affected, gives a reason that actually justifies the cost, and if your boss tells you to make the change.
The somehow justified complaint that someone who isn't male or female would have to choose a category "other" that makes them somehow stand out can be solved: Change "other" to "unknown, undisclosed, or other". And then you can volunteer to not disclose your gender so nobody needs to be the only person in that category.
And change the question from "which are you" to "which describes you best", so someone who sees themselves 60/40 between two genders can pick the 60% case without having to make a compromise.
You don't change your application (which may have significant cost for development and testing) unless someone complains who is actually affected, gives a reason that actually justifies the cost, and if your boss tells you to make the change.
The somehow justified complaint that someone who isn't male or female would have to choose a category "other" that makes them somehow stand out can be solved: Change "other" to "unknown, undisclosed, or other". And then you can volunteer to not disclose your gender so nobody needs to be the only person in that category.
And change the question from "which are you" to "which describes you best", so someone who sees themselves 60/40 between two genders can pick the 60% case without having to make a compromise.
answered Mar 3 '17 at 18:05
gnasher729
70.4k31131219
70.4k31131219
suggest improvements |Â
suggest improvements |Â
up vote
-1
down vote
First, establish she wasn't joking.
Then, roll your eyes and make it
Other = 0,
Male = 1,
Female = 2
And stop showing her your code!
suggest improvements |Â
up vote
-1
down vote
First, establish she wasn't joking.
Then, roll your eyes and make it
Other = 0,
Male = 1,
Female = 2
And stop showing her your code!
suggest improvements |Â
up vote
-1
down vote
up vote
-1
down vote
First, establish she wasn't joking.
Then, roll your eyes and make it
Other = 0,
Male = 1,
Female = 2
And stop showing her your code!
First, establish she wasn't joking.
Then, roll your eyes and make it
Other = 0,
Male = 1,
Female = 2
And stop showing her your code!
answered Mar 2 '17 at 15:43
colmde
4,078921
4,078921
suggest improvements |Â
suggest improvements |Â
up vote
-3
down vote
You are writing a piece of software, and your first and foremost priority is making sure it works and is easy for your peers to work with.
When it comes to data analysis, data isn't inherently bigoted. It's only bigoted when you ascribe further meaning than what is present. For example, if your numbers show that there are more men than women who work at your company, there's nothing wrong with that. If you take that and say that women are therefore less qualified than men to work in your field, that's problematic.
If your friend, or some hypothetical future person, sees that a '0' is being used for women and a '1' is for men, and decides that that number is the number of penises that employee has, that is not reflective of your attitude or your codebase's attitude. Your code is just text, it can't have an opinion.
The question you should ask is, can you rewrite your code in such a way that a programmer not familiar with it can still work effectively? Or will your proposed change trade off clarity/convenience with perceived gender neutrality? If it's the former, then go ahead and make the change if it makes you more comfortable.
An easy workaround is maybe to just replace every '0' or '1' using #define and explicitly name each group, so no one will assume any further meaning behind it.
suggest improvements |Â
up vote
-3
down vote
You are writing a piece of software, and your first and foremost priority is making sure it works and is easy for your peers to work with.
When it comes to data analysis, data isn't inherently bigoted. It's only bigoted when you ascribe further meaning than what is present. For example, if your numbers show that there are more men than women who work at your company, there's nothing wrong with that. If you take that and say that women are therefore less qualified than men to work in your field, that's problematic.
If your friend, or some hypothetical future person, sees that a '0' is being used for women and a '1' is for men, and decides that that number is the number of penises that employee has, that is not reflective of your attitude or your codebase's attitude. Your code is just text, it can't have an opinion.
The question you should ask is, can you rewrite your code in such a way that a programmer not familiar with it can still work effectively? Or will your proposed change trade off clarity/convenience with perceived gender neutrality? If it's the former, then go ahead and make the change if it makes you more comfortable.
An easy workaround is maybe to just replace every '0' or '1' using #define and explicitly name each group, so no one will assume any further meaning behind it.
suggest improvements |Â
up vote
-3
down vote
up vote
-3
down vote
You are writing a piece of software, and your first and foremost priority is making sure it works and is easy for your peers to work with.
When it comes to data analysis, data isn't inherently bigoted. It's only bigoted when you ascribe further meaning than what is present. For example, if your numbers show that there are more men than women who work at your company, there's nothing wrong with that. If you take that and say that women are therefore less qualified than men to work in your field, that's problematic.
If your friend, or some hypothetical future person, sees that a '0' is being used for women and a '1' is for men, and decides that that number is the number of penises that employee has, that is not reflective of your attitude or your codebase's attitude. Your code is just text, it can't have an opinion.
The question you should ask is, can you rewrite your code in such a way that a programmer not familiar with it can still work effectively? Or will your proposed change trade off clarity/convenience with perceived gender neutrality? If it's the former, then go ahead and make the change if it makes you more comfortable.
An easy workaround is maybe to just replace every '0' or '1' using #define and explicitly name each group, so no one will assume any further meaning behind it.
You are writing a piece of software, and your first and foremost priority is making sure it works and is easy for your peers to work with.
When it comes to data analysis, data isn't inherently bigoted. It's only bigoted when you ascribe further meaning than what is present. For example, if your numbers show that there are more men than women who work at your company, there's nothing wrong with that. If you take that and say that women are therefore less qualified than men to work in your field, that's problematic.
If your friend, or some hypothetical future person, sees that a '0' is being used for women and a '1' is for men, and decides that that number is the number of penises that employee has, that is not reflective of your attitude or your codebase's attitude. Your code is just text, it can't have an opinion.
The question you should ask is, can you rewrite your code in such a way that a programmer not familiar with it can still work effectively? Or will your proposed change trade off clarity/convenience with perceived gender neutrality? If it's the former, then go ahead and make the change if it makes you more comfortable.
An easy workaround is maybe to just replace every '0' or '1' using #define and explicitly name each group, so no one will assume any further meaning behind it.
answered Mar 2 '17 at 20:32
Zephyr
30914
30914
suggest improvements |Â
suggest improvements |Â
up vote
-5
down vote
Why waste storage space by having an Integer variable for this purpose? Use a boolean instead - IsMale: true or false. Null valie if neither male nor female.
Problem solved.
5
Some people neither male or female - transgender/intersex for example. Or perhaps they do not wish the company concerted to know there gender
– Ed Heal
Aug 5 '16 at 12:24
Androgynous people exist, and there are arguably a lot more then 2 genders. On a technical node, almost all implementations of SQL relational databases use padding so an integer number is likely to be only minimally less space-consuming then a boolean (unless you have a LOT of booleans in that table). And considering its a person database, its likely not large enough for spacing to matter. You could probably make every field in that table a char(500) and it wouldn't matter.
– Magisch
Aug 5 '16 at 13:05
2
@AndrewPiliser all of those can be compressed into 'other' unless you feel OP should update their tables everytime their tumblr page updates as well...
– easymoden00b
Aug 5 '16 at 18:13
1
@easymoden00b I'd recommend letting people write in whatever they want, with defaults for common choices. Also, way to bring up Tumblr. Are you going to call me an SJW next?
– Andrew Piliser
Aug 5 '16 at 18:33
1
And of course if you use a boolean, why isn't it IsFemale? Or better yet? IsOther.
– HLGEM
Mar 2 '17 at 19:01
 |Â
show 2 more comments
up vote
-5
down vote
Why waste storage space by having an Integer variable for this purpose? Use a boolean instead - IsMale: true or false. Null valie if neither male nor female.
Problem solved.
5
Some people neither male or female - transgender/intersex for example. Or perhaps they do not wish the company concerted to know there gender
– Ed Heal
Aug 5 '16 at 12:24
Androgynous people exist, and there are arguably a lot more then 2 genders. On a technical node, almost all implementations of SQL relational databases use padding so an integer number is likely to be only minimally less space-consuming then a boolean (unless you have a LOT of booleans in that table). And considering its a person database, its likely not large enough for spacing to matter. You could probably make every field in that table a char(500) and it wouldn't matter.
– Magisch
Aug 5 '16 at 13:05
2
@AndrewPiliser all of those can be compressed into 'other' unless you feel OP should update their tables everytime their tumblr page updates as well...
– easymoden00b
Aug 5 '16 at 18:13
1
@easymoden00b I'd recommend letting people write in whatever they want, with defaults for common choices. Also, way to bring up Tumblr. Are you going to call me an SJW next?
– Andrew Piliser
Aug 5 '16 at 18:33
1
And of course if you use a boolean, why isn't it IsFemale? Or better yet? IsOther.
– HLGEM
Mar 2 '17 at 19:01
 |Â
show 2 more comments
up vote
-5
down vote
up vote
-5
down vote
Why waste storage space by having an Integer variable for this purpose? Use a boolean instead - IsMale: true or false. Null valie if neither male nor female.
Problem solved.
Why waste storage space by having an Integer variable for this purpose? Use a boolean instead - IsMale: true or false. Null valie if neither male nor female.
Problem solved.
edited Aug 5 '16 at 13:54
answered Aug 5 '16 at 12:05
Acroneos
1,0242814
1,0242814
5
Some people neither male or female - transgender/intersex for example. Or perhaps they do not wish the company concerted to know there gender
– Ed Heal
Aug 5 '16 at 12:24
Androgynous people exist, and there are arguably a lot more then 2 genders. On a technical node, almost all implementations of SQL relational databases use padding so an integer number is likely to be only minimally less space-consuming then a boolean (unless you have a LOT of booleans in that table). And considering its a person database, its likely not large enough for spacing to matter. You could probably make every field in that table a char(500) and it wouldn't matter.
– Magisch
Aug 5 '16 at 13:05
2
@AndrewPiliser all of those can be compressed into 'other' unless you feel OP should update their tables everytime their tumblr page updates as well...
– easymoden00b
Aug 5 '16 at 18:13
1
@easymoden00b I'd recommend letting people write in whatever they want, with defaults for common choices. Also, way to bring up Tumblr. Are you going to call me an SJW next?
– Andrew Piliser
Aug 5 '16 at 18:33
1
And of course if you use a boolean, why isn't it IsFemale? Or better yet? IsOther.
– HLGEM
Mar 2 '17 at 19:01
 |Â
show 2 more comments
5
Some people neither male or female - transgender/intersex for example. Or perhaps they do not wish the company concerted to know there gender
– Ed Heal
Aug 5 '16 at 12:24
Androgynous people exist, and there are arguably a lot more then 2 genders. On a technical node, almost all implementations of SQL relational databases use padding so an integer number is likely to be only minimally less space-consuming then a boolean (unless you have a LOT of booleans in that table). And considering its a person database, its likely not large enough for spacing to matter. You could probably make every field in that table a char(500) and it wouldn't matter.
– Magisch
Aug 5 '16 at 13:05
2
@AndrewPiliser all of those can be compressed into 'other' unless you feel OP should update their tables everytime their tumblr page updates as well...
– easymoden00b
Aug 5 '16 at 18:13
1
@easymoden00b I'd recommend letting people write in whatever they want, with defaults for common choices. Also, way to bring up Tumblr. Are you going to call me an SJW next?
– Andrew Piliser
Aug 5 '16 at 18:33
1
And of course if you use a boolean, why isn't it IsFemale? Or better yet? IsOther.
– HLGEM
Mar 2 '17 at 19:01
5
5
Some people neither male or female - transgender/intersex for example. Or perhaps they do not wish the company concerted to know there gender
– Ed Heal
Aug 5 '16 at 12:24
Some people neither male or female - transgender/intersex for example. Or perhaps they do not wish the company concerted to know there gender
– Ed Heal
Aug 5 '16 at 12:24
Androgynous people exist, and there are arguably a lot more then 2 genders. On a technical node, almost all implementations of SQL relational databases use padding so an integer number is likely to be only minimally less space-consuming then a boolean (unless you have a LOT of booleans in that table). And considering its a person database, its likely not large enough for spacing to matter. You could probably make every field in that table a char(500) and it wouldn't matter.
– Magisch
Aug 5 '16 at 13:05
Androgynous people exist, and there are arguably a lot more then 2 genders. On a technical node, almost all implementations of SQL relational databases use padding so an integer number is likely to be only minimally less space-consuming then a boolean (unless you have a LOT of booleans in that table). And considering its a person database, its likely not large enough for spacing to matter. You could probably make every field in that table a char(500) and it wouldn't matter.
– Magisch
Aug 5 '16 at 13:05
2
2
@AndrewPiliser all of those can be compressed into 'other' unless you feel OP should update their tables everytime their tumblr page updates as well...
– easymoden00b
Aug 5 '16 at 18:13
@AndrewPiliser all of those can be compressed into 'other' unless you feel OP should update their tables everytime their tumblr page updates as well...
– easymoden00b
Aug 5 '16 at 18:13
1
1
@easymoden00b I'd recommend letting people write in whatever they want, with defaults for common choices. Also, way to bring up Tumblr. Are you going to call me an SJW next?
– Andrew Piliser
Aug 5 '16 at 18:33
@easymoden00b I'd recommend letting people write in whatever they want, with defaults for common choices. Also, way to bring up Tumblr. Are you going to call me an SJW next?
– Andrew Piliser
Aug 5 '16 at 18:33
1
1
And of course if you use a boolean, why isn't it IsFemale? Or better yet? IsOther.
– HLGEM
Mar 2 '17 at 19:01
And of course if you use a boolean, why isn't it IsFemale? Or better yet? IsOther.
– HLGEM
Mar 2 '17 at 19:01
 |Â
show 2 more comments
protected by Elysian Fields♦ Mar 2 '17 at 21:57
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
Edited to bring in-line with the scope of TheWorkplace. Inserted a direct question that asks not for advice on what to do, but whether it was appropriate to group data using only the two types, grouping the rest into an 'other' category (and therefore 'excluding' them as options), which appears to be the OP's main concern.
– schizoid04
Mar 2 '17 at 16:18