16 ms·

A curated list of falsehoods programmers believe

119 points by andersonmvd 5y ago

matsemann 5y ago
> 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.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- layer8 5y ago
  I guess they really meant "slightly categorized because otherwise the list would be too long".
- remram 5y ago
  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?
glitchc 5y ago
It feels like many of these speak to poorly defined requirements.
- throwaway889900 5y ago
  Bold of you to assume that requirements are properly defined.
biasedestimate 5y ago
falsehood n+1: it is a good idea to compile a long lists of falsehoods, based on information from random websites.
- allendoerfer 5y ago
  I think the falsehood is: Bookmarking poorly organized lists will make you avoid all their pitfalls. Also: Lists from the Internet are correct.
  - kdeldycke 5y ago
    Got this covered at: https://kevin.deldycke.com/2016/12/falsehoods-programmers-believe-about-falsehoods-lists/ https://kevin.deldycke.com/2016/12/falsehoods-programmers-be...
- y42 5y ago
  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.
ihateolives 5y ago
"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.
- nonameiguess 5y ago
  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.
- boredumb 5y ago
  In puerto rico up until very recently (with some lagging behind) it is the condominium building name, apt # and a zip code.
  - ajford 5y ago
    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.
qwerty456127 5y ago
> 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.
- NateEag 5y ago
  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 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?
  - qwerty456127 5y ago
    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.
    - miloignis 5y ago
      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.)
asdfasgasdgasdg 5y ago
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.
- allendoerfer 5y ago
  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.
- not2b 5y ago
  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".
- ihateolives 5y ago
  > 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.
xdennis 5y ago
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-about-gender-f9a3512b4c9c https://medium.com/gender-2-0/falsehoods-programmers-believe...
- lllt 5y ago
- rhn_mk1 5y ago
  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).
- feoren 5y ago
  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."
  - trono 5y ago
  - throwaway675309 5y ago
ballenf 5y ago
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.
- reaperducer 5y ago
  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.
- throwaway889900 5y ago
  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.
- michaelcampbell 5y ago
  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.
a_shovel 5y ago
I think the lesson to take from these lists is that covering every edge case for many real-world situations becomes asymptotically difficult. 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.
- BitwiseFool 5y ago
  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.
  - ryandrake 5y ago
    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.
Hussell 5y ago
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 https://duffel.com/blog/falsehoods-about-seat-maps Falsehoods about Biometrics https://shkspr.mobi/blog/2021/01/falsehoods-programmers-believe-about-biometrics/ https://shkspr.mobi/blog/2021/01/falsehoods-programmers-beli... Falsehoods about Plain Text https://jeremyhussell.blogspot.com/2017/11/falsehoods-programmers-believe-about.html#main https://jeremyhussell.blogspot.com/2017/11/falsehoods-progra...
- Hussell 5y ago
  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-believe-about-names/ https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-... Falsehoods about Time https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program... Falsehoods about Addresses https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/ https://www.mjt.me.uk/posts/falsehoods-programmers-believe-a...
drivers99 5y ago
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/trunk/output/falsehoods.html 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.
allears 5y ago
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.
- michaelcampbell 5y ago
  Most of them read more like things you might imagine someone to have thought, once.
hintymad 5y ago
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?
- SuperCuber 5y ago
  Satellites have to account for their clocks moving at a slightly different rate - it is significant at that scale.
nofunsir 5y ago
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?
jqpabc123 5y ago
#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.
raverbashing 5y ago
The one about CS students is very poignant https://www.netmeister.org/blog/cs-falsehoods.html https://www.netmeister.org/blog/cs-falsehoods.html
kazinator 5y ago
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.
- deleted 5y ago
  [deleted]
bko 5y ago
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!
- feoren 5y ago
  Don't leave us hanging! What is the <8-bit processor in common-enough use to not fit into (1 - Most)?
  - bko 5y ago
    That's my question! We need a falsehoods explained page
- remram 5y ago
  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..."
gregfjohnson 5y ago
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..
- remram 5y ago
  It's a little further: > Because the bugs are in their code, not mine.
daphneokeefe 5y ago
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.
deleted 5y ago
[deleted]
kmod 5y ago
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
jedberg 5y ago
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.
abortionlover69 5y ago
Optimal_Persona 5y ago
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.

119 points by andersonmvd 5y ago

> 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.

deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
layer8 5y ago
I guess they really meant "slightly categorized because otherwise the list would be too long".
remram 5y ago
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?

glitchc 5y ago

It feels like many of these speak to poorly defined requirements.

throwaway889900 5y ago
Bold of you to assume that requirements are properly defined.

biasedestimate 5y ago

falsehood n+1: it is a good idea to compile a long lists of falsehoods, based on information from random websites.

allendoerfer 5y ago
I think the falsehood is: Bookmarking poorly organized lists will make you avoid all their pitfalls. Also: Lists from the Internet are correct.
- kdeldycke 5y ago
  Got this covered at: https://kevin.deldycke.com/2016/12/falsehoods-programmers-believe-about-falsehoods-lists/ https://kevin.deldycke.com/2016/12/falsehoods-programmers-be...
y42 5y ago
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.

ihateolives 5y ago

"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.

nonameiguess 5y ago
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.
boredumb 5y ago
In puerto rico up until very recently (with some lagging behind) it is the condominium building name, apt # and a zip code.
- ajford 5y ago
  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.

qwerty456127 5y ago

> 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.

NateEag 5y ago
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 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?
- qwerty456127 5y ago
  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.
  - miloignis 5y ago
    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.)

asdfasgasdgasdg 5y ago

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.

allendoerfer 5y ago
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.
not2b 5y ago
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".
ihateolives 5y ago
> 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.

xdennis 5y ago

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-about-gender-f9a3512b4c9c https://medium.com/gender-2-0/falsehoods-programmers-believe...

lllt 5y ago
rhn_mk1 5y ago
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).
feoren 5y ago
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."
- trono 5y ago
- throwaway675309 5y ago

ballenf 5y ago

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.

reaperducer 5y ago
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.
throwaway889900 5y ago
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.
michaelcampbell 5y ago
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.

a_shovel 5y ago

I think the lesson to take from these lists is that covering every edge case for many real-world situations becomes asymptotically difficult. 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.

BitwiseFool 5y ago
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.
- ryandrake 5y ago
  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.

Hussell 5y ago

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 https://duffel.com/blog/falsehoods-about-seat-maps Falsehoods about Biometrics https://shkspr.mobi/blog/2021/01/falsehoods-programmers-believe-about-biometrics/ https://shkspr.mobi/blog/2021/01/falsehoods-programmers-beli... Falsehoods about Plain Text https://jeremyhussell.blogspot.com/2017/11/falsehoods-programmers-believe-about.html#main https://jeremyhussell.blogspot.com/2017/11/falsehoods-progra...

Hussell 5y ago
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-believe-about-names/ https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-... Falsehoods about Time https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program... Falsehoods about Addresses https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/ https://www.mjt.me.uk/posts/falsehoods-programmers-believe-a...

drivers99 5y ago

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/trunk/output/falsehoods.html 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.

allears 5y ago

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.

michaelcampbell 5y ago
Most of them read more like things you might imagine someone to have thought, once.

hintymad 5y ago

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?

SuperCuber 5y ago
Satellites have to account for their clocks moving at a slightly different rate - it is significant at that scale.

nofunsir 5y ago

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?

jqpabc123 5y ago

#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.

raverbashing 5y ago

The one about CS students is very poignant https://www.netmeister.org/blog/cs-falsehoods.html https://www.netmeister.org/blog/cs-falsehoods.html

kazinator 5y ago

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.

deleted 5y ago
[deleted]

bko 5y ago

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!

feoren 5y ago
Don't leave us hanging! What is the <8-bit processor in common-enough use to not fit into (1 - Most)?
- bko 5y ago
  That's my question! We need a falsehoods explained page
remram 5y ago
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..."

gregfjohnson 5y ago

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..

remram 5y ago
It's a little further: > Because the bugs are in their code, not mine.

daphneokeefe 5y ago

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.

deleted 5y ago

[deleted]

kmod 5y ago

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

jedberg 5y ago

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.

abortionlover69 5y ago

Optimal_Persona 5y ago

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.