A curated list of falsehoods programmers believe(github.com)
github.com
A curated list of falsehoods programmers believe
https://github.com/kdeldycke/awesome-falsehood
127 comments
In regards to your last line, I feel like we do need to give people some leeway and not assume bigoted intent. Most of the things we can gig people for not implementing nowadays are only recently important in our cultural consciousness. English has traditionally shied away from using accents and one can reasonably assume that if a person signs up for my English language website, they won't be using Chinese characters in their name. As for the boolean determining pronouns thing, I can easily see someone thinking that was a clever implementation before people adopted the idea that there are more than two to be cognizant of. I also think using they/them is only recently considered grammatically acceptable. Going forward, we do want to support the things you mentioned.
Bias isn't the same as being bigoted. If when you find out you missed it you go "Oh, crap, you're right! We should fix that" you had a bias. If when you find out you missed it you start to defend why it's fine to not include it (not to admit you should, but maybe you don't have time/it isn't worth the cost), that's the point it's bigoted.
It's the difference between making a mistake, and getting defensive that it wasn't a mistake. Per old systems, they all fall under bias; it's only with how do the existing support personnel deal with it that you start looking at bigotry, a "I'm sorry, I know, it's just an old system and we don't have the money to update it" is totally understandable and I would argue okay. Digging in that it's not the system that is at fault but the individual wanting a different pronoun, or the person refusing to pick an anglicized name and start using it everywhere, is bigoted.
It's the difference between making a mistake, and getting defensive that it wasn't a mistake. Per old systems, they all fall under bias; it's only with how do the existing support personnel deal with it that you start looking at bigotry, a "I'm sorry, I know, it's just an old system and we don't have the money to update it" is totally understandable and I would argue okay. Digging in that it's not the system that is at fault but the individual wanting a different pronoun, or the person refusing to pick an anglicized name and start using it everywhere, is bigoted.
> If when you find out you missed it you start to defend why it's fine to not include it (not to admit you should, but maybe you don't have time/it isn't worth the cost), that's the point it's bigoted.
>
> It's the difference between making a mistake, and getting defensive that it wasn't a mistake.
I think that definition is pretty good, but it also reveals something about the popular usage of the term "bigot".
IIUC, an underlying assumption in the parent comment is a person is at fault for not accommodating the offended party's preferred taxonomy / categories / terminology. That a person is a "bigot" if they see their system's current taxonomy as better or more appropriate.
Merriam-Webster's definition is somewhat different [0]: "a person who is obstinately or intolerantly devoted to his or her own opinions and prejudices".
Note that with MW's definition, either or both persons in that "you missed it" conversation could be labelled a bigot, depending on how obstinately they held onto their views.
[0] https://www.merriam-webster.com/dictionary/bigot
I think that definition is pretty good, but it also reveals something about the popular usage of the term "bigot".
IIUC, an underlying assumption in the parent comment is a person is at fault for not accommodating the offended party's preferred taxonomy / categories / terminology. That a person is a "bigot" if they see their system's current taxonomy as better or more appropriate.
Merriam-Webster's definition is somewhat different [0]: "a person who is obstinately or intolerantly devoted to his or her own opinions and prejudices".
Note that with MW's definition, either or both persons in that "you missed it" conversation could be labelled a bigot, depending on how obstinately they held onto their views.
[0] https://www.merriam-webster.com/dictionary/bigot
You are skipping over the last two words in the definition. It isn't just holding to their own opinions. It is holding to their "opinions and prejudices". Of the two stances "I want to be referred to by the pronouns of my choosing" and "I want to refer to you be the pronouns I dictate for you" only one of those would qualify as prejudice and therfore that is the stance that qualifies as bigoted.
I wonder if we're assuming different definitions of "prejudices".
What I mean is having reached a conclusion without consideration of all the relevant details. I.e., deciding a matter prematurely. I think this lines up pretty well with the MW definition [0].
I don't see how that's related to the particular opposing stances in your example. Can you elaborate?
[0] https://www.merriam-webster.com/dictionary/prejudice
What I mean is having reached a conclusion without consideration of all the relevant details. I.e., deciding a matter prematurely. I think this lines up pretty well with the MW definition [0].
I don't see how that's related to the particular opposing stances in your example. Can you elaborate?
[0] https://www.merriam-webster.com/dictionary/prejudice
The person who refuses to use another person's preferred pronouns is obvious dictionary definition prejudice. It is someone prejudging the proper pronouns without the relevant details from the individual they are referencing. It is almost literally the person saying "I am deciding your gender without consulting you."
What are the relevant details when choosing your own preferred pronouns? Wouldn't all the relevant details be known by the person making the decision? I don't see how that can be prejudice.
What are the relevant details when choosing your own preferred pronouns? Wouldn't all the relevant details be known by the person making the decision? I don't see how that can be prejudice.
Thanks for clarifying! I can see now how that could be an example of prejudice.
I had a different scenario in mind: person A indicates their preferred pronouns to person B, but person B refuses to use those pronouns for well-considered reasons and with a full understanding of the situation. It's this scenario that I was arguing to not be a case of bigotry nor prejudice.
I had a different scenario in mind: person A indicates their preferred pronouns to person B, but person B refuses to use those pronouns for well-considered reasons and with a full understanding of the situation. It's this scenario that I was arguing to not be a case of bigotry nor prejudice.
Oh, I thought lostcolony had already eliminated that specific scenario as not being bigoted. It can be biased, but it wouldn't be bigoted if there are justifiable reasons for not making the switch. That isn't prejudice as it is a decision made after the relevant details are known.
Just to be clear, for the parent, 'person B refuses to use those pronouns for well-considered reasons and with a full understanding of the situation' may apply when we're talking about systems, but there are plenty of people who would use that sort of reasoning to be why they refuse to use someone's pronouns in conversation. No one doing so believes their reasons are poorly considered and/or that they have an incomplete understanding of the situation, after all.
So, yes, "justifiable", as in, "to change that in the system would be a lot of cost and risk and we simply can't justify it, but I agree it sucks that it's that way", not as in "You were assigned male at birth and I refuse to use anything other than he/him when referring to you, because I believe I understand the science, and your personal situation, better than you".
So, yes, "justifiable", as in, "to change that in the system would be a lot of cost and risk and we simply can't justify it, but I agree it sucks that it's that way", not as in "You were assigned male at birth and I refuse to use anything other than he/him when referring to you, because I believe I understand the science, and your personal situation, better than you".
Not sure if "for the parent" was directed at me or the parent of my comment, but you and I are in complete agreement.
> I also think using they/them is only recently considered grammatically acceptable.
In general, as a singular gender neutral third person pronoun for a person of unknown, unclear, or unspecified gender, they/them is approximately as old as modern english itself, having been clearly used by one of the earliest practitioners of the language, Shakespeare.
What's modern is the idea that it's somehow incorrect to have a pronoun that is both plural and singular, which is funny because 'you' is both singular and plural and people use it every day without incident or confusion.
Use for a person of known but not-binary gender is newer than that, but probably older than you think, and neopronouns are actually probably also quite a bit older than you think too.
In general, as a singular gender neutral third person pronoun for a person of unknown, unclear, or unspecified gender, they/them is approximately as old as modern english itself, having been clearly used by one of the earliest practitioners of the language, Shakespeare.
What's modern is the idea that it's somehow incorrect to have a pronoun that is both plural and singular, which is funny because 'you' is both singular and plural and people use it every day without incident or confusion.
Use for a person of known but not-binary gender is newer than that, but probably older than you think, and neopronouns are actually probably also quite a bit older than you think too.
For what it's worth, I'm glad they/them is catching on and I use it all the time.
Growing up, though, I was taught to use "he or she" / "she or he" in English class and they/them was always used in the context of third person plural. I don't consider it a newfangled thing, but the embrace of it feels new.
Growing up, though, I was taught to use "he or she" / "she or he" in English class and they/them was always used in the context of third person plural. I don't consider it a newfangled thing, but the embrace of it feels new.
"They" comes off impersonal though. As if you're using it because you don't know their gender. That's why I would much prefer a new word. Something that indicates that you know they are neither he nor she. (In a similar vein I'd also prefer a distinct singular "they" and plural "you")
I do know that realistically something like that would never catch on, but I can dream...
I do know that realistically something like that would never catch on, but I can dream...
It certainly could; look how quickly the term "Ms." as an alternative to "Miss" or "Mrs." caught on. Though it has antecedents long before the 20th century, the term caught fire in the early 1970s with the first publication of "Ms." magazine and was in widespread usage within ten years.
I think the bigger problem is coming up with an accepted alternative; there are several floating around, none of which have had a Ms. magazine moment.
I think the bigger problem is coming up with an accepted alternative; there are several floating around, none of which have had a Ms. magazine moment.
I hadn't thought before of how recent Ms. is. You've given me some hope now. Not holding my breath but keeping my fingers crossed at the very least.
Definitely old software that's obviously not getting updated can be forgiven. There's still 16-bit DOS software used in production that harkens from the time when ASCII was all that could be supported. I get it, it sucks when a legacy airline system written in the '70 removes the accent characters from your name but them's the breaks. But if you're designing new software nowadays and your requirements don't include the "new cultural consciousness," you're probably making a big mistake. I've seen software built within the last 5 years fail QA due to not displaying emoji.
Yeah, it's probably wrong to assume much about a lack of support for Chinese-character names on an English-language website, so I removed that. (But if you don't have a good reason not to, you should support it.)
Accents and punctuation are different. There are a lot of English-speaking people whose names don't fit in ASCII. A system that doesn't support them is at the "95% for no effort" stage, if even that.
Accents and punctuation are different. There are a lot of English-speaking people whose names don't fit in ASCII. A system that doesn't support them is at the "95% for no effort" stage, if even that.
> That said, it is incredibly revealing of your personal biases...if you implement gender as a boolean that also determines the user's pronouns.
It is probably revealing of your personal biases that you cannot imagine systems in languages other than English that need to do some of this since multiple parts of the language, including verbs, are necessarily gendered, with a neutral gender usually only reserved for inanimate things. Reference: I happen to speak one such language.
Problems like this are just hard due to generations of built-up cultural context and the associated effects. We can and should do better, but there is no need to get overly enthusiastic about accusing people of biases while we are at it.
It is probably revealing of your personal biases that you cannot imagine systems in languages other than English that need to do some of this since multiple parts of the language, including verbs, are necessarily gendered, with a neutral gender usually only reserved for inanimate things. Reference: I happen to speak one such language.
Problems like this are just hard due to generations of built-up cultural context and the associated effects. We can and should do better, but there is no need to get overly enthusiastic about accusing people of biases while we are at it.
There's a world of difference between "Which of these two options defines your gender identity and sex organs?" and "Which grammatical gender form should we use for words when we talk about you?". The former is a deeply personal question with unclear benefit; the latter is a specific question about how you want the site to do a specific thing it needs to do. (Does it really need to do that? Why exactly are you asking about gender?)
I have an anecdote that I think fits your assumption. It comes from my years in the Danish public sector where some of the systems are many decades old. In Denmark we’re all issued a social security number that is designed in such a way that the last number of it, is odd for males and even for females.
To make things short and somewhat anonymous, we had several systems that couldn’t handle people changing the “gender” of their social security number. They could handle you getting a new social security number, but it had to be of the same “gender” as your previous.
This makes no real sense, as it’s just a number and all these systems handle both types of numbers. But there we were, and it took us several years to get to a point where we could accommodate an employee changing the “gender” of their social security number.
So sometimes, developers do weird things because of their assumptions.
Ps. I’ve put “gender” in “”s because I’m unsure what the right word is in English.
To make things short and somewhat anonymous, we had several systems that couldn’t handle people changing the “gender” of their social security number. They could handle you getting a new social security number, but it had to be of the same “gender” as your previous.
This makes no real sense, as it’s just a number and all these systems handle both types of numbers. But there we were, and it took us several years to get to a point where we could accommodate an employee changing the “gender” of their social security number.
So sometimes, developers do weird things because of their assumptions.
Ps. I’ve put “gender” in “”s because I’m unsure what the right word is in English.
It could help an e-commerce site predict what kind of clothes to recommend, or otherwise segment you for marketing
Everyone has biases, that's just a fact. Something can only be unbiased in comparison to something else that has the same biases. Having biases doesn't make you evil.
Yeah, I only considered English language sites, not other languages that don't support gender-neutrality as easily. I think I should add something about them, though. I don't see how any language could possibly require gender to be implemented as a boolean. If you've got an English-language site you're translating to another language, and you've implemented a selector for "he", "she", and "they" pronouns without direct reference to gender in the English version, you could just re-use the same implementation in your language with different options.
(Also, I can guarantee that there's someone who speaks your language that prefers to be referred to in the neutral/inanimate form. Doesn't matter which language. It's fine not to support that on the site, just wanted to point it out.)
Yeah, I only considered English language sites, not other languages that don't support gender-neutrality as easily. I think I should add something about them, though. I don't see how any language could possibly require gender to be implemented as a boolean. If you've got an English-language site you're translating to another language, and you've implemented a selector for "he", "she", and "they" pronouns without direct reference to gender in the English version, you could just re-use the same implementation in your language with different options.
(Also, I can guarantee that there's someone who speaks your language that prefers to be referred to in the neutral/inanimate form. Doesn't matter which language. It's fine not to support that on the site, just wanted to point it out.)
> It gets thornier when it comes to personal things like names and gender. If you tell a group of people that their identity isn't supported by your system, some people will accept that and work around it, some people will be mad at you, and you'll just have to accept that the latter have a good point. You have to stop developing it at some point, so all you can do is try to cover as many people as possible.
That’s a pretty big if, which itself reveals a bias. While it’s certainly not going to cover every single identity, the following will likely cover vastly more than added effort:
1. Do you need to ask for the data at all?
2. If 1, do you need to require the data?
3. If 1, unless you have to comply with arbitrary external requirements (eg law), use a free form text field.
4. Test that the text field and accompanying information is accessible to assistive tools. This usually comes for free if you use built in tools.
5. If not 2, affirmatively indicate that entering anything is optional.
6. Ask for feedback on how you can do it better, again making this obviously optional. If the feedback is meaningful (i.e. “I cannot use this”, rather than “I would prefer this be less inclusive”), accommodate it.
That’s a pretty big if, which itself reveals a bias. While it’s certainly not going to cover every single identity, the following will likely cover vastly more than added effort:
1. Do you need to ask for the data at all?
2. If 1, do you need to require the data?
3. If 1, unless you have to comply with arbitrary external requirements (eg law), use a free form text field.
4. Test that the text field and accompanying information is accessible to assistive tools. This usually comes for free if you use built in tools.
5. If not 2, affirmatively indicate that entering anything is optional.
6. Ask for feedback on how you can do it better, again making this obviously optional. If the feedback is meaningful (i.e. “I cannot use this”, rather than “I would prefer this be less inclusive”), accommodate it.
> ...it is incredibly revealing of your personal biases.
People make mistakes. I think you're opening a can of worms if you try to conflate a lack of robustness in user experience accessibility with some underlying anti-inclusivity bias.
People make mistakes. I think you're opening a can of worms if you try to conflate a lack of robustness in user experience accessibility with some underlying anti-inclusivity bias.
> It gets thornier when it comes to personal things like names and gender.
In the case of name, I read an article sometime back that mentioned the problem of getting people's fullname right. Not everyone has a "first name" and a "last name" distinction. So it is better to just have one field of "fullname" and let people enter it as per their locale and tradition instead of having "first name" and "last name" fields. I think gender also falls in the same category.
In the case of name, I read an article sometime back that mentioned the problem of getting people's fullname right. Not everyone has a "first name" and a "last name" distinction. So it is better to just have one field of "fullname" and let people enter it as per their locale and tradition instead of having "first name" and "last name" fields. I think gender also falls in the same category.
This is the first "falsehoods programmers believe about X" article I read and what I think kicked off the trend. In fact this GitHub page references the same as "the article that started it all".
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
> ...it is incredibly revealing of your personal biases...
I think that is an unfair accusation.
I've been coding for over 20 years, and I have only had to enable UTF8 to cover all corners of use cases (web based data/content) to special characters. I work with companies in multiple foreign countries, and my biases are irrelevant to technically working systems.
I think that is an unfair accusation.
I've been coding for over 20 years, and I have only had to enable UTF8 to cover all corners of use cases (web based data/content) to special characters. I work with companies in multiple foreign countries, and my biases are irrelevant to technically working systems.
Sounds like you have never tried sorting or searching.
Where in the alphabet does "ö" or "aa" go? Well, it depends on the language AND the word.
Is ø the same as ø? Unicode can encode it in 2 different ways, so you need to normalize all encoding before comparing.
Is ø the same as o when searching? For Americans it is, for others not.
Where in the alphabet does "ö" or "aa" go? Well, it depends on the language AND the word.
Is ø the same as ø? Unicode can encode it in 2 different ways, so you need to normalize all encoding before comparing.
Is ø the same as o when searching? For Americans it is, for others not.
But how is it a personal bias if I never run into these technical issues to deal with in the first place?
You have never sorted any texts? Never made a list of names?
Never implemented a search function?
These aspects can easily creep into an app without you even noticing. Saying "I haven't seem them" is not proof for them not being there.
E.g. web servers had some surprise security bugs because they didn't think about overly long utf-8 codes.
Never implemented a search function?
These aspects can easily creep into an app without you even noticing. Saying "I haven't seem them" is not proof for them not being there.
E.g. web servers had some surprise security bugs because they didn't think about overly long utf-8 codes.
The default Android keyboard (Google keyboard) had/has an issue like this. It really likes to auto-complete a to å and ä even though the keys are at opposite ends of the (Swedish) keyboard. If I wanted to write "här" (here) instead of "har" (have/has) I would've used ä...
I have done all of those things. But my customers simply were not affected negatively by the technical choices I made. (and I have great relationships and very open communication with the people I've served)
I implemented single fields for personal names, single textareas for addresses and some very basic content format selections and collation and my simple solutions have solved _all_ of my customers needs in these areas.
It seems to be some bizarre assumption that _everyone_ has a bad experience because some code wasn't done they way they would do it. It's absurd to be accused of something that has simply not been a problem for my users.
I implemented single fields for personal names, single textareas for addresses and some very basic content format selections and collation and my simple solutions have solved _all_ of my customers needs in these areas.
It seems to be some bizarre assumption that _everyone_ has a bad experience because some code wasn't done they way they would do it. It's absurd to be accused of something that has simply not been a problem for my users.
The bias in this is whatever belief system one might have to say "ASCII is good enough". Or whatever level of ignorance to believe that ASCII is good enough without understanding that it cannot be. Etc.
But what if ASCII is completely sufficient for all the customers I work with?
This is where the accusation crosses into unreasonable for me.
This is where the accusation crosses into unreasonable for me.
> The bias in this is whatever belief system one might have to say "ASCII is good enough".
Could there also be bias in the statement "ASCII is not good enough."?
Could there also be bias in the statement "ASCII is not good enough."?
I wouldn't call it bias. You can make a claim "I know my use-cases so well that I can guarantee that ASCII will cover it". I'd call that foolishness, not bias.
Are you sure most systems even need to record gender or pronouns? Outside of medicine sex is rarely significant, and if by gender you mean masculine or feminine traits then again (other to the person themselves) it’s largely irrelevant I’d have thought.
Pronouns can be useful in any system that generates text that refers to people in the third person, so makes sense to ask -- but it also makes sense to just let people put in whatever they want unless you are trying to aggregate data from it for marketing purposes, in which case imo you should stop doing that.
> Outside of medicine sex is rarely significant
Frankly, even inside of medicine it's usually not terribly relevant, and is often a poor proxy for the information they really want out of it. Half the time a medical form asks you that it's literally just so that cis men won't get mad at you for asking if they're pregnant on a later step.
I won't be at all surprised if I get some kind of kneejerk reaction to this statement suggesting that it might be important in an emergency or something, but for the most part that's not really the case, and even where it is, if it's that important (ie. allergy level), it's not sufficient to avoid harm because you will have situations where neither "sex" or "gender" as commonly formulated on these forms will tell you what you really need to know (hormone balance, organ configuration, medical history). Any one of those could be out of alignment with whichever social construct of sexed traits you pick.
> Outside of medicine sex is rarely significant
Frankly, even inside of medicine it's usually not terribly relevant, and is often a poor proxy for the information they really want out of it. Half the time a medical form asks you that it's literally just so that cis men won't get mad at you for asking if they're pregnant on a later step.
I won't be at all surprised if I get some kind of kneejerk reaction to this statement suggesting that it might be important in an emergency or something, but for the most part that's not really the case, and even where it is, if it's that important (ie. allergy level), it's not sufficient to avoid harm because you will have situations where neither "sex" or "gender" as commonly formulated on these forms will tell you what you really need to know (hormone balance, organ configuration, medical history). Any one of those could be out of alignment with whichever social construct of sexed traits you pick.
> Frankly, even inside of medicine it's usually not terribly relevant, and is often a poor proxy for the information they really want out of it.
Sex is incredibly important inside medicine. It's probably the most important distinguishing characteristic when determining how to diagnose and treat someone (maybe weight is more).
Here are a few examples:
- 99% of breast cancer occurs in women
- any diseases affecting the female[male] reproductive systems can only impact women[men]
- 4x as many women suffer from osteoporosis
- Roughly 70% of those living with autoimmune diseases are female
- stomach cancer (2:1 men) oesophageal cancer (3:1 men) liver cancer (2:1 to 4:1 men)
https://en.wikipedia.org/wiki/Sex_differences_in_medicine
Sex is incredibly important inside medicine. It's probably the most important distinguishing characteristic when determining how to diagnose and treat someone (maybe weight is more).
Here are a few examples:
- 99% of breast cancer occurs in women
- any diseases affecting the female[male] reproductive systems can only impact women[men]
- 4x as many women suffer from osteoporosis
- Roughly 70% of those living with autoimmune diseases are female
- stomach cancer (2:1 men) oesophageal cancer (3:1 men) liver cancer (2:1 to 4:1 men)
https://en.wikipedia.org/wiki/Sex_differences_in_medicine
Yep, called the kneejerk.
These are statistical differences. If you want to know if they apply to an individual you need to know more. A checkbox on a form is not sufficient.
If you're usefully aggregating data for some purpose, say for a study, then go off ask all the relevant indicators you want.
If it's an intake form for an eye doctor appointment, it won't tell you dick all. If a patient came in for a breast exam, you already know they're at risk of cancer. If you're their family doctor figuring out risk factors, you already know their medical history.
And if they're trans or intersex, and you're assuming that either their assigned sex or their self-declared gender tells you which bucket they fall in, you know a lot more than anyone else about how those traits affect those things because they are woefully understudied, and almost certainly complicated by literally everything in their medical history.
These are statistical differences. If you want to know if they apply to an individual you need to know more. A checkbox on a form is not sufficient.
If you're usefully aggregating data for some purpose, say for a study, then go off ask all the relevant indicators you want.
If it's an intake form for an eye doctor appointment, it won't tell you dick all. If a patient came in for a breast exam, you already know they're at risk of cancer. If you're their family doctor figuring out risk factors, you already know their medical history.
And if they're trans or intersex, and you're assuming that either their assigned sex or their self-declared gender tells you which bucket they fall in, you know a lot more than anyone else about how those traits affect those things because they are woefully understudied, and almost certainly complicated by literally everything in their medical history.
> If it's an intake form for an eye doctor appointment, it won't tell you dick all.
Where are you getting your information?
Results: Sex and sex hormones influence the lacrimal system, eyelids and blinking, corneal anatomy and disease, aqueous humor dynamics and glaucoma, crystalline lens and cataract, uveitis and retinal disease, ocular circulation, and optic nerve anatomy and disease. Systemic conditions, particularly autoimmune disease, and conditions that are unique to women, such as pregnancy and menopause, further illustrate the effects of sex hormones on the eye. Gender-based differences in ocular conditions and disease should be considered within the context of the underlying physical and social environment.
[0] https://pubmed.ncbi.nlm.nih.gov/19811761/
Where are you getting your information?
Results: Sex and sex hormones influence the lacrimal system, eyelids and blinking, corneal anatomy and disease, aqueous humor dynamics and glaucoma, crystalline lens and cataract, uveitis and retinal disease, ocular circulation, and optic nerve anatomy and disease. Systemic conditions, particularly autoimmune disease, and conditions that are unique to women, such as pregnancy and menopause, further illustrate the effects of sex hormones on the eye. Gender-based differences in ocular conditions and disease should be considered within the context of the underlying physical and social environment.
[0] https://pubmed.ncbi.nlm.nih.gov/19811761/
Skimmed the paper on Scihub. It looks like it's mostly a review of other studies that either show statistical correlations or are about hormone levels. I.e. it directly supports their point that sex is just being used as a proxy for the thing that you really want to know. (And most of it seems irrelevant for someone with healthy eyes getting a new pair of glasses.)
Proxies for the thing you really want to know are pretty useful when you can check the proxy cheaply and the thing you really want to know is (comparatively) expensive to test.
Like, I don't think the world would be better if we routinely gave cismen pregnancy tests, would it?
Like, I don't think the world would be better if we routinely gave cismen pregnancy tests, would it?
Again, we're talking about forms here. If you have a reason to want to know if someone has a uterus or might be or become pregnant, you can just ask that. Forms for things where this is important usually do anyways. Sometimes gated on an "if you answered female to the above..." which actually compounds the problem for some people who are not neatly categorized that way.
Likewise, asking a cis man if he is or might be pregnant should not be a horrible thing to do, nor a problem for record keeping, though like I alluded to in my initial reply here, it does sometimes cause confusion or even confrontation to ask them.
Likewise, asking a cis man if he is or might be pregnant should not be a horrible thing to do, nor a problem for record keeping, though like I alluded to in my initial reply here, it does sometimes cause confusion or even confrontation to ask them.
Those statistical differences are used to more quickly reduce the search space of symptoms when the cause is unknown. So yeah, they are still important, even for individuals.
In the marketing world, it's vastly predictive of behavior, similar to income level or political party. Men and women tend to have highly significant differences in shopping and purchasing behavior.
So, whether they 'need' gender or not, many places 'want' gender.
So, whether they 'need' gender or not, many places 'want' gender.
Looking back at this, yeah, I agree with the criticism that the last line is overly harsh. I try to be lenient to people with unconscious bias, and this doesn't help with that.
> A curated list of falsehoods programmers believe in.
No, these "awesome" lists are seldom curated. They are just dumps of hundreds or thousands of links.
No, these "awesome" lists are seldom curated. They are just dumps of hundreds or thousands of links.
I guess they really meant "slightly categorized because otherwise the list would be too long".
Some of them are, or try to be.
This is in no way a list of falsehoods, there is not a single one in the repository. It is a dump of links to other people's articles about falsehoods (or other people's dumps of links to others). I am surprised why they would claim that, maybe they copied another "awesome list" template?
This is in no way a list of falsehoods, there is not a single one in the repository. It is a dump of links to other people's articles about falsehoods (or other people's dumps of links to others). I am surprised why they would claim that, maybe they copied another "awesome list" template?
[deleted]
[deleted]
Better title would be, "list of common simplifying assumptions programmers and designers make."
Avoiding all these assumptions will introduce unacceptable complexity for many projects. In many of the listed cases, making the assumption will require a tiny fraction of your addressable market to use a workaround, which they are likely already used to using with other products.
So there is a cost-benefit study to be done here. You have finite engineering time. Which of these assumptions can you avoid with little net increase in complexity? Which ones are actually simplifying? Which ones will cause critical problems for your users? And which ones are too expensive to fix given the return on investment?
I think the content of lists like this are decently useful, but the tone is condescending and unwarranted. I don't "believe" that everyone has a first middle and last name. I do believe that people with fifteen names are capable of leaving out some of the ones in the middle, and it makes my job a lot easier to require them to do so.
Avoiding all these assumptions will introduce unacceptable complexity for many projects. In many of the listed cases, making the assumption will require a tiny fraction of your addressable market to use a workaround, which they are likely already used to using with other products.
So there is a cost-benefit study to be done here. You have finite engineering time. Which of these assumptions can you avoid with little net increase in complexity? Which ones are actually simplifying? Which ones will cause critical problems for your users? And which ones are too expensive to fix given the return on investment?
I think the content of lists like this are decently useful, but the tone is condescending and unwarranted. I don't "believe" that everyone has a first middle and last name. I do believe that people with fifteen names are capable of leaving out some of the ones in the middle, and it makes my job a lot easier to require them to do so.
People who have the wrong kinds of names pay a heavy price for this kind of thing. You gave an absurd example (15 names), but much more common cases tend to break. For example, my wife's legal name has a hyphen in it. It is astounding how many web sites cannot cope with this. Or worse, accept the correct name in one place and not in another, or accept the entry and then report a name mismatch later when they "sanitize the input".
By modelling culture, we as programmers are also defining it.
Everytime you assume something about a standard, you are making it a tiny bit more true. Before boarding the enterprise together, we will have agreed on a more concise version of what a name/address/email/time is.
Everytime you assume something about a standard, you are making it a tiny bit more true. Before boarding the enterprise together, we will have agreed on a more concise version of what a name/address/email/time is.
> I do believe that people with fifteen names are capable of leaving out some of the ones in the middle, and it makes my job a lot easier to require them to do so.
Sure, if you handle it gracefully and give them ample space to squeeze their names onto one field and your system not making fuss about it. People that tend to have fiften names also tend to come from areas that may use accented characters, have suffixes and thus spaces in their names and have other weird combinations:
Cristina Fernández de Kirchner, Manuela Maria Lopez Sanchez de Chacon, Juan Carlos Vargas Blanco (given name is Juan Carlos, not Juan), Carla Rodriguez y Calderón (both Rodriguez and Calderón are last names)
In my anecdotal experience from having lots of friends with non-ascii letters in their names there are surprisingly many websites and software that will fail to take into account some or all of those things. And then there are cultures where surname is not necessarily a thing. If you're adamant that users "can leave out" or butcher (because you don't accept Ü or Ł) their names because it's convenient to you then you're creating hard to predict problems for the user. Quite common is to accept all characters but then silently converting them for "convenience" before storing and then use those names next time instead of what the user entered, so that poor Łukasz would have to know to use Lukasz next time without nobody telling him.
Sure, if you handle it gracefully and give them ample space to squeeze their names onto one field and your system not making fuss about it. People that tend to have fiften names also tend to come from areas that may use accented characters, have suffixes and thus spaces in their names and have other weird combinations:
Cristina Fernández de Kirchner, Manuela Maria Lopez Sanchez de Chacon, Juan Carlos Vargas Blanco (given name is Juan Carlos, not Juan), Carla Rodriguez y Calderón (both Rodriguez and Calderón are last names)
In my anecdotal experience from having lots of friends with non-ascii letters in their names there are surprisingly many websites and software that will fail to take into account some or all of those things. And then there are cultures where surname is not necessarily a thing. If you're adamant that users "can leave out" or butcher (because you don't accept Ü or Ł) their names because it's convenient to you then you're creating hard to predict problems for the user. Quite common is to accept all characters but then silently converting them for "convenience" before storing and then use those names next time instead of what the user entered, so that poor Łukasz would have to know to use Lukasz next time without nobody telling him.
> Carla Rodriguez y Calderón (both Rodriguez and Calderón are last names)
I was not aware of this form until I moved to New Mexico several years ago. I had a hyphenated name earlier in life, and have come to think of this as a (roughly) Spanish equivalent of that.
If you can't/don't handle Ortiz y Pino in New Mexico, several fairly powerful people are going to be pretty pissed off! And that's still within the borders of the USA.
I was not aware of this form until I moved to New Mexico several years ago. I had a hyphenated name earlier in life, and have come to think of this as a (roughly) Spanish equivalent of that.
If you can't/don't handle Ortiz y Pino in New Mexico, several fairly powerful people are going to be pretty pissed off! And that's still within the borders of the USA.
> valid email address exactly has one @ character
A normal email address exactly has one @ character. There is an infinite number of possible weird things everyone has little though non-zero chance to encounter on every corner of their life.
> therefore your implementation should allow this
I wouldn't be sure it should. Implementing support for this has direct and indirect, explicit and implicit costs one will have to consider and decide if that's worth it.
In fact, whatever a human can believe about the world, it won't equal what actually is. So we just take decisions about how precise our models have to be to be practical.
You can never finish a program if you insist it has to be perfect and unbreakable. The only reasonable objective is to make sure it does the job 99.9 % of real-life times.
A normal email address exactly has one @ character. There is an infinite number of possible weird things everyone has little though non-zero chance to encounter on every corner of their life.
> therefore your implementation should allow this
I wouldn't be sure it should. Implementing support for this has direct and indirect, explicit and implicit costs one will have to consider and decide if that's worth it.
In fact, whatever a human can believe about the world, it won't equal what actually is. So we just take decisions about how precise our models have to be to be practical.
You can never finish a program if you insist it has to be perfect and unbreakable. The only reasonable objective is to make sure it does the job 99.9 % of real-life times.
All that said, there are a number of really good email validators out there in the wild.
One of the oldest can be found at http://isemail.info/about, (along with a test suite to write your own implementation and some sage advice about the basic approaches it's reasonable to take when validating email addresses).
Yes, dependencies aren't completely free conceptually, even when they're distributed free of charge, but why write a crappy validator of your own when there are really good ones available?
One of the oldest can be found at http://isemail.info/about, (along with a test suite to write your own implementation and some sage advice about the basic approaches it's reasonable to take when validating email addresses).
Yes, dependencies aren't completely free conceptually, even when they're distributed free of charge, but why write a crappy validator of your own when there are really good ones available?
Because I really don't want to accept a string with more (or less) than one @ symbol for an e-mail address. Such an address can be valid theoretically but chances are it is incorrect. If somebody submits such a string for their email, 99 in 100 cases it's a typo and the remaining 1 is a person testing you. Not even one real person in a million will use an e-mail address which doesn't have exactly one @ symbol in it.
People can also incorrectly type in their email in a way that looks fine, so I'm skeptical of intentionally not allowing valid email addresses just to cut out a small fraction of those. The isemail.info site recommends a warning if it doesn't look right, but allowing the user to override and use anyway, which seems sensible to me.
(I say this as the proud owner of a lastname.email domain, where the .email TLD was made explicitly for this 8 years, and I still have problems with bad validation.)
(I say this as the proud owner of a lastname.email domain, where the .email TLD was made explicitly for this 8 years, and I still have problems with bad validation.)
[deleted]
You can ask for confirmation if it’s an unusual construction, but denying it outright is user hostile.
Also, how many users are actually manually typing their e-mail address into a form, instead of using autofill?
As the referenced page says, a valid email address is one that can receive email. If you really care about the e-mail address being correct, then you need to validate it by sending a verification e-mail.
Also, how many users are actually manually typing their e-mail address into a form, instead of using autofill?
As the referenced page says, a valid email address is one that can receive email. If you really care about the e-mail address being correct, then you need to validate it by sending a verification e-mail.
If somebody wants to register and use an email address with a bang path, that unix beard is out of luck.
Is there a reason to validate an email address? Even if it is valid, you can't use it for anything until you check that the right person owns it and is able to read mail you send there.
I personally accept any string that is between 3 bytes and 1 kilobyte, if they click the link in it then it's good.
I personally accept any string that is between 3 bytes and 1 kilobyte, if they click the link in it then it's good.
Yes - you validate the email address to improve your UX.
It reduces the odds of the user giving you a wrong email address then having to either jump through more hoops to get signed up or give up.
You're absolutely right that the acid test is "can they receive email to it?"
It reduces the odds of the user giving you a wrong email address then having to either jump through more hoops to get signed up or give up.
You're absolutely right that the acid test is "can they receive email to it?"
For UX purposes you would use a warning/extra confirmation. If you make the decision to block the user from registering, you are doing something else.
Yeah, precisely.
As that website I linked says, if the email looks suspicious but is technically valid, ask them "Are you sure you didn't mean this?", but let them choose what they put in.
However, if the address as given is definitely invalid, then you can reject it and explain why. You can offer suggestions here too if any seem reasonable.
As that website I linked says, if the email looks suspicious but is technically valid, ask them "Are you sure you didn't mean this?", but let them choose what they put in.
However, if the address as given is definitely invalid, then you can reject it and explain why. You can offer suggestions here too if any seem reasonable.
> A normal email address exactly has one @ character
I've been using <[email protected]@myemaildomain> to respond to people for ages, and this is a completely normal and supported email flow. Who are you to tell other people what is normal? It is not some possible weird thing that other people can use emails that follow the spec and aren't even all that out there.
I've been using <[email protected]@myemaildomain> to respond to people for ages, and this is a completely normal and supported email flow. Who are you to tell other people what is normal? It is not some possible weird thing that other people can use emails that follow the spec and aren't even all that out there.
I have never seen an email address with more than one @.
Can you provide us with an example?
Can you provide us with an example?
[email protected]@otherperson.net
"The only reasonable objective is to make sure it does the job 99.9 % of real-life times."
If you would be writing software for airplanes, or cars, that would mean lots of crashes per day, with millions x 99.9% being still a lot. If it is financial software, people might loose millions regulary.
But if you make a casual game ... who cares (except the person who lost his highscore achievements).
Obviously there are different standards.
If you would be writing software for airplanes, or cars, that would mean lots of crashes per day, with millions x 99.9% being still a lot. If it is financial software, people might loose millions regulary.
But if you make a casual game ... who cares (except the person who lost his highscore achievements).
Obviously there are different standards.
The main falsehood is that the programmer must adopt, as requirements, all edge cases of every imaginable instance and interpretation of a problem domain.
Even if the programmer wanted to do that, his boss, and boss's boss would disagree.
It is a falsehood, of course, that "I don't have to handle cases outside of the specification we committed to". Though not always, and not for all cases.
Say that my reuqirements are to write a music engraving program for western notation. Of course, I take it for granted that (that type of) music can be written down; my program is not an expression of my personal belief that all music can be written down, or that it has a composer.
Even if the programmer wanted to do that, his boss, and boss's boss would disagree.
It is a falsehood, of course, that "I don't have to handle cases outside of the specification we committed to". Though not always, and not for all cases.
Say that my reuqirements are to write a music engraving program for western notation. Of course, I take it for granted that (that type of) music can be written down; my program is not an expression of my personal belief that all music can be written down, or that it has a composer.
[deleted]
"Falsehoods programmers believe about geography: Street adresses contain street names.
In many remote places in Europe, the hamlet name is considered a sufficient address."
Yup, I used to spend my summers on an island where my address would be: farmstead name, island, country. Zip code was optional. Had to find creative ways to satisfy various web forms.
Yup, I used to spend my summers on an island where my address would be: farmstead name, island, country. Zip code was optional. Had to find creative ways to satisfy various web forms.
Another that list misses is that houses must be reachable by street at all. My girlfriend 20 years ago had an address on a canal (though the back of her house was reachable by unnamed alleyways).
The thing about postal databases bit me many times being the first owner of a new home, too. So many times some software system didn't believe my address was valid because my builder filed the original deed incorrectly. Actually, this was worse because I couldn't even pay property tax for three years until it was fixed, but believe me software service X that told me my address didn't exist, my house is real and every delivery service I have ever tried to use managed to find it.
The thing about postal databases bit me many times being the first owner of a new home, too. So many times some software system didn't believe my address was valid because my builder filed the original deed incorrectly. Actually, this was worse because I couldn't even pay property tax for three years until it was fixed, but believe me software service X that told me my address didn't exist, my house is real and every delivery service I have ever tried to use managed to find it.
Lived in Puerto Rico for a while a few years back, and stuff off the beaten path (and plenty of things in town as well) wouldn't have an "address number", but instead would have a "position" based off kilometer markers.
For a good year, my address was something like "KM 5.4 Carr. 635", which was effectively "Kilometer 5.4 Highway 635". And then the put out new kilometer markers and my address changed by 0.2km in one way according to the power company and the other way according to the water company.
And IIRC, the power company had "yellow house in the back" as part of my address, since there were three houses on this lot. Don't know what would've happened if I painted the house!
Edit: Ha! Looks like a few things have changed in Google Maps and a number of things now have addresses showing up with their km marker numbers, which didn't use to be the case. For example, the Caribbean Cinemas location in Arecibo, Puerto Rico [0] has the address "Carr. #2, Km. 81.0 Barrio Hato Abajo, Arecibo, PR 00612"
[0] https://caribbeancinemas.com/theater/arecibo/
For a good year, my address was something like "KM 5.4 Carr. 635", which was effectively "Kilometer 5.4 Highway 635". And then the put out new kilometer markers and my address changed by 0.2km in one way according to the power company and the other way according to the water company.
And IIRC, the power company had "yellow house in the back" as part of my address, since there were three houses on this lot. Don't know what would've happened if I painted the house!
Edit: Ha! Looks like a few things have changed in Google Maps and a number of things now have addresses showing up with their km marker numbers, which didn't use to be the case. For example, the Caribbean Cinemas location in Arecibo, Puerto Rico [0] has the address "Carr. #2, Km. 81.0 Barrio Hato Abajo, Arecibo, PR 00612"
[0] https://caribbeancinemas.com/theater/arecibo/
One that's repeatedly tripping me up while I'm living on in the Caribbean is "all addresses have ZIP codes". They've started adding postal codes here but not many places have them. It's easy enough to enter 00000 but before moving here I wouldn't have known there are places without some form of post code.
In puerto rico up until very recently (with some lagging behind) it is the condominium building name, apt # and a zip code.
Hell, getting things to understand barrios when I lived in PR.... Yes, this address looks like it has two cities on the address. Nope, that's how it's supposed to be.
Or the hassle of trying to figure out whether a website was gonna list PR under State or Country or just not have it at all. I got really good at modifying web forms with Chrome devtools to inject Puerto Rico into the State drop-downs so I could just get shit shipped.
And for a while I didn't have any way to receive mail at the house I was renting, so I had stuff shipped to work, but they only had a rural box addr, so the addr was "Box 1234....". Anything shipping via UPS/FedEx didn't wanna touch it, so we had an alternate address for each of them (since UPS's system couldn't find one address form and FedEx couldn't find the other) and I'd have to find out who the seller was shipping with.
Or the hassle of trying to figure out whether a website was gonna list PR under State or Country or just not have it at all. I got really good at modifying web forms with Chrome devtools to inject Puerto Rico into the State drop-downs so I could just get shit shipped.
And for a while I didn't have any way to receive mail at the house I was renting, so I had stuff shipped to work, but they only had a rural box addr, so the addr was "Box 1234....". Anything shipping via UPS/FedEx didn't wanna touch it, so we had an alternate address for each of them (since UPS's system couldn't find one address form and FedEx couldn't find the other) and I'd have to find out who the seller was shipping with.
>I got really good at modifying web forms with Chrome devtools to inject Puerto Rico into the State drop-downs so I could just get shit shipped.
Wow. I've never thought of this... I can think of three places I've reached out to in order to have a company manually update my address because of this just in the last two months.
Wow. I've never thought of this... I can think of three places I've reached out to in order to have a company manually update my address because of this just in the last two months.
Doesn't always work, but when it does, makes you feel like a hacker!
I always tried it first, and if needed would reach out to the company afterwards.
Had one company call me after tweaking the form in Chrome and ask how I managed to place the order with that address. After playing dumb for a bit, I sheepishly admitted to altering the form. They were upset at first, but after explaining that they used USPS and USPS handled mail to PR just fine and required no export papers, they actually thanked me and updated their site themselves to handle shipping to PR.
I always tried it first, and if needed would reach out to the company afterwards.
Had one company call me after tweaking the form in Chrome and ask how I managed to place the order with that address. After playing dumb for a bit, I sheepishly admitted to altering the form. They were upset at first, but after explaining that they used USPS and USPS handled mail to PR just fine and required no export papers, they actually thanked me and updated their site themselves to handle shipping to PR.
Here's one I haven't seen on a list:
When you onboard to a new company, they will automatically give you access to whatever systems you need to do your job.
or
It will be automatic or easy to get access to all the systems you need to do your job.
When you onboard to a new company, they will automatically give you access to whatever systems you need to do your job.
or
It will be automatic or easy to get access to all the systems you need to do your job.
When you onboard to a new company, they will automatically give you access to whatever systems you need to do your job.
Related: When you're hired to be a computer programmer, the company will have a computer for you on your first day of work.
This happened to me twice. The first time at a low-rent startup where people were expected to bring their own machines. (Company folded months later amid an unrelated government investigation.) The second time was when the previous programmer did something unpleasant to the computer on his way out, and the company's procurement process for getting replacement gear required lots of approvals because dev machines are higher-spec and more expensive than an ordinary office computer.
Related: When you're hired to be a computer programmer, the company will have a computer for you on your first day of work.
This happened to me twice. The first time at a low-rent startup where people were expected to bring their own machines. (Company folded months later amid an unrelated government investigation.) The second time was when the previous programmer did something unpleasant to the computer on his way out, and the company's procurement process for getting replacement gear required lots of approvals because dev machines are higher-spec and more expensive than an ordinary office computer.
Also related:
When you onboard to a new company, there will be a list of the systems you'll need to do your job.
Once you know what tools you need, you'll have training, and documentation on them. This is especially true for internally written tools.
When you onboard to a new company, there will be a list of the systems you'll need to do your job.
Once you know what tools you need, you'll have training, and documentation on them. This is especially true for internally written tools.
I would go one step further with the first one, because I was completely forgotten about for the first two weeks of my first job:
You will be onboarded to your new company.
You will be onboarded to your new company.
I would say the main takeaway from these lists is: Use a library where the library author has a much bigger vested interest in the edge cases than you do.
Don't implement date and time calculations yourself, just use the library, even for things like "add a day".
Don't parse addresses yourself, use a library. Don't validate email yourself, use a library. Don't validate input yourself, use a library.
Unless the runtime or memory space is absolutely critical to your application, using a library won't make things noticeably worse.
Don't implement date and time calculations yourself, just use the library, even for things like "add a day".
Don't parse addresses yourself, use a library. Don't validate email yourself, use a library. Don't validate input yourself, use a library.
Unless the runtime or memory space is absolutely critical to your application, using a library won't make things noticeably worse.
Boss: Why is it taking so long to implement this feature?
Programmer: Well, you see Boss, I found this really cool list of falsehoods that only dumb, less-holy programmers believe on a random Github. It's really cool because it lists every edg...Boss? Where are you going?
Most of these lists (at least the ones I scanned through) are simply assertions, with no explanations, examples, or links. This is less than useful, and makes me doubt their veracity.
Most of them read more like things you might imagine someone to have thought, once.
I really enjoyed this - several LOL's. I loved the sequence of falsehoods about compilers:
- The compiler won’t have bugs.
- The compiler won’t have show-stopping bugs.
- The compiler’s bugs will be fixed quickly.
- The compiler’s bugs can be fixed.
But I think they should have added:
- My code does not work because of bugs in the compiler..
- The compiler won’t have bugs.
- The compiler won’t have show-stopping bugs.
- The compiler’s bugs will be fixed quickly.
- The compiler’s bugs can be fixed.
But I think they should have added:
- My code does not work because of bugs in the compiler..
It's a little further:
> Because the bugs are in their code, not mine.
> Because the bugs are in their code, not mine.
falsehood n+1: it is a good idea to compile a long lists of falsehoods, based on information from random websites.
I think the falsehood is:
Bookmarking poorly organized lists will make you avoid all their pitfalls.
Also:
Lists from the Internet are correct.
Bookmarking poorly organized lists will make you avoid all their pitfalls.
Also:
Lists from the Internet are correct.
Got this covered at: https://kevin.deldycke.com/2016/12/falsehoods-programmers-be...
Well, it's a good start and it contains, so it seems, valid sources. So at least its a little entertaining to browse through and learn a little.
I checked a few random lists and their "falsehoods" weren't very informative when it's just a list without any explanation. Maybe they're just supposed to be amusing or contrarian.
(Following my own advice...) For example: https://chiselapp.com/user/ttmrichter/repository/gng/doc/tru...
> 10× programmers exist.
(i.e. saying they don't exist) Maybe a writing prompt for a blog post, but there's nothing else there about it.
(Following my own advice...) For example: https://chiselapp.com/user/ttmrichter/repository/gng/doc/tru...
> 10× programmers exist.
(i.e. saying they don't exist) Maybe a writing prompt for a blog post, but there's nothing else there about it.
#1 Falsehood Programmers Believe
- Programming skill is all you need to build great software.
About the only case where I would say this might be true is when your users are other programmers. If the plan is to target a non-technical market, good design and in-depth understanding of the problem space are just as important if not more so.
My favorite example of this is the world's most popular accounting software. Good design and marketing --- mediocre programming.
- Programming skill is all you need to build great software.
About the only case where I would say this might be true is when your users are other programmers. If the plan is to target a non-technical market, good design and in-depth understanding of the problem space are just as important if not more so.
My favorite example of this is the world's most popular accounting software. Good design and marketing --- mediocre programming.
How timely on St. Patrick's Day. How about people's names that contain an apostrophe? I married O'Keefe. It is just so aggravating.
Is there an easy way to display a diff which shows all the new links since the last time this was on HN? (Sept. 8th, 2020)
Partial list:
Falsehoods about Airline Seat Maps https://duffel.com/blog/falsehoods-about-seat-maps
Falsehoods about Biometrics https://shkspr.mobi/blog/2021/01/falsehoods-programmers-beli...
Falsehoods about Plain Text https://jeremyhussell.blogspot.com/2017/11/falsehoods-progra...
Partial list:
Falsehoods about Airline Seat Maps https://duffel.com/blog/falsehoods-about-seat-maps
Falsehoods about Biometrics https://shkspr.mobi/blog/2021/01/falsehoods-programmers-beli...
Falsehoods about Plain Text https://jeremyhussell.blogspot.com/2017/11/falsehoods-progra...
For those who haven't seen this before, the ones you should look at first are:
Falsehoods about Names https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
Falsehoods about Time https://infiniteundo.com/post/25326999628/falsehoods-program...
Falsehoods about Addresses https://www.mjt.me.uk/posts/falsehoods-programmers-believe-a...
Falsehoods about Names https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
Falsehoods about Time https://infiniteundo.com/post/25326999628/falsehoods-program...
Falsehoods about Addresses https://www.mjt.me.uk/posts/falsehoods-programmers-believe-a...
It feels like many of these speak to poorly defined requirements.
Bold of you to assume that requirements are properly defined.
Not on the 'email' list, but I'll add "A .org domain extension should be the sole criteria for whether a customer can be classified as a nonprofit".
I tried to create a nonprofit account at Box.com a few years ago with a .net address. It took almost 3 weeks of back-and-forth with customer support and multiple interactions with higher-ups in their legal dept. to resolve. No one there had ever considered the possibility.
I tried to create a nonprofit account at Box.com a few years ago with a .net address. It took almost 3 weeks of back-and-forth with customer support and multiple interactions with higher-ups in their legal dept. to resolve. No one there had ever considered the possibility.
This kind of thing scares me about the current state of AI. Language models are trained to produce text that looks like the training data, but if the training data has falsehoods they will happily repeat those falsehoods.
I just put the example into GPT3: Prompt: Can an email address contain more than one @ sign? Answer: No, an email address can only contain one @ sign.
I'm on my phone so it's a bit laborious to test more
I just put the example into GPT3: Prompt: Can an email address contain more than one @ sign? Answer: No, an email address can only contain one @ sign.
I'm on my phone so it's a bit laborious to test more
This is a fantastic read.
> "Time passes at the same speed on top of a mountain and at the bottom of a valley".
Just curious, does this kind of gravitational time dilation bear any consequence in our systems, given that we are building systems with the assumption that system clocks are not always accurate and there is no global time?
> "Time passes at the same speed on top of a mountain and at the bottom of a valley".
Just curious, does this kind of gravitational time dilation bear any consequence in our systems, given that we are building systems with the assumption that system clocks are not always accurate and there is no global time?
Satellites have to account for their clocks moving at a slightly different rate - it is significant at that scale.
[deleted]
The one about CS students is very poignant https://www.netmeister.org/blog/cs-falsehoods.html
I would love an annotated falsehoods. For instance, one of the falsehoods programmers believe about programming:
Most processors in active use are 32-bit or larger.
16-bit or larger?
8-bit or larger?
OH COME ON!
Most processors in active use are 32-bit or larger.
16-bit or larger?
8-bit or larger?
OH COME ON!
It is interesting to think that there are smaller than 8-bit processors around, but I think the author might have forgotten that they started the section with "most processors are..."
The original one about names was about exposing people to different culture's perspective (like how Icelanders have last names based on their father's first name), but this expands into nonsensical territory like "people can change genders multiple times a day"[1]. It just feels like being a rebel for rebellion's sake.
[1]: https://medium.com/gender-2-0/falsehoods-programmers-believe...
[1]: https://medium.com/gender-2-0/falsehoods-programmers-believe...
The reason I like "people can change genders multiple times per day" is not because it suggests your implementation of gender should support that, but rather that you should not try to implement gender at all. One of the main messages from these is to stop mindlessly asking for "Last Name" or "Gender" when your system has no need for that information to do its job. Get your system to do its main job, and if there is still a free variable (e.g. what gender do we use for verbs when talking about you in German?) then ask only that, specifically. The people who change genders multiple times per day are doing it because they see their different genders as applying to different situations, and you should be clear about what situations you're asking about.
"Eddie Izzard, why do you wear women's clothes?"
Eddie Izzard: "I don't. These are my clothes. I bought them."
"Eddie Izzard, why do you wear women's clothes?"
Eddie Izzard: "I don't. These are my clothes. I bought them."
Some systems do require some form of gender identification, specifically any type of system dealing with naturally generated text in languages where conjugation and other semantic elements can change based on the speaker.
"They" and "their" are in fact words computers can use.
It has a name. "Gender fluid."
And just because you don't understand it doesn't mean that it isn't some peoples' life experience.
Reference: I know a child who is not at all rebellious or attention-seeking but who expresses this as their inner experience.
Dismissing that experience is rude.
And just because you don't understand it doesn't mean that it isn't some peoples' life experience.
Reference: I know a child who is not at all rebellious or attention-seeking but who expresses this as their inner experience.
Dismissing that experience is rude.
I've always said you can identify as whatever you want, just don't expect me to try to constantly keep up with it.
Who is a programmer to prevent others from being rebels because they enjoy it? There's freedom and creativity in nonsense, and that might be worth preserving, especially when not crucial to fulfilling the task at hand (which gender rarely is).
[deleted]
You can get 95% with no effort at all, 99% with a bit of thought, 99.9% with some effort, 99.99% with a smart design, some research, and a lot of effort, and anything further requires making it your full-time job indefinitely.
It gets thornier when it comes to personal things like names and gender. If you tell a group of people that their identity isn't supported by your system, some people will accept that and work around it, some people will be mad at you, and you'll just have to accept that the latter have a good point. You have to stop developing it at some point, so all you can do is try to cover as many people as possible.
That said, it is incredibly revealing of your personal biases if you design a system that breaks on things like names with "é", or "ñ", or punctuation; or if you implement gender as a boolean that also determines the user's pronouns.