I think the lesson to take from these lists is that covering every edge case for many real-world situations becomes asymptotically difficult.<p>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.<p>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.<p>That said, it is <i>incredibly</i> 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.
> <i>A curated list of falsehoods programmers believe in.</i><p>No, these "awesome" lists are seldom <i>curated</i>. They are just dumps of hundreds or thousands of links.
Better title would be, "list of common simplifying assumptions programmers and designers make."<p>Avoiding <i>all</i> 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.<p>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?<p>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.
> valid email address exactly has one @ character<p>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.<p>> therefore your implementation should allow this<p>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.<p>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.<p>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.
The main falsehood is that the programmer must adopt, as requirements, all edge cases of every imaginable instance and interpretation of a problem domain.<p>Even if the programmer wanted to do that, his boss, and boss's boss would disagree.<p>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.<p>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.
"Falsehoods programmers believe about geography: Street adresses contain street names.
In many remote places in Europe, the hamlet name is considered a sufficient address."<p>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.
Here's one I haven't seen on a list:<p>When you onboard to a new company, they will automatically give you access to whatever systems you need to do your job.<p>or<p>It will be automatic or easy to get access to all the systems you need to do your job.
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.<p>Don't implement date and time calculations yourself, just use the library, even for things like "add a day".<p>Don't parse addresses yourself, use a library. Don't validate email yourself, use a library. Don't validate input yourself, use a library.<p>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.
I really enjoyed this - several LOL's. I loved the sequence of falsehoods about compilers:<p>- The compiler won’t have bugs.<p>- The compiler won’t have show-stopping bugs.<p>- The compiler’s bugs will be fixed quickly.<p>- The compiler’s bugs can be fixed.<p>But I think they should have added:<p>- My code does not work because of bugs in the compiler..
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.<p>(Following my own advice...) For example: <a href="https://chiselapp.com/user/ttmrichter/repository/gng/doc/trunk/output/falsehoods.html" rel="nofollow">https://chiselapp.com/user/ttmrichter/repository/gng/doc/tru...</a><p>> 10× programmers exist.<p>(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<p>- Programming skill is all you need to build great software.<p>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.<p>My favorite example of this is the world's most popular accounting software. Good design and marketing --- mediocre programming.
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)<p>Partial list:<p>Falsehoods about Airline Seat Maps <a href="https://duffel.com/blog/falsehoods-about-seat-maps" rel="nofollow">https://duffel.com/blog/falsehoods-about-seat-maps</a><p>Falsehoods about Biometrics <a href="https://shkspr.mobi/blog/2021/01/falsehoods-programmers-believe-about-biometrics/" rel="nofollow">https://shkspr.mobi/blog/2021/01/falsehoods-programmers-beli...</a><p>Falsehoods about Plain Text <a href="https://jeremyhussell.blogspot.com/2017/11/falsehoods-programmers-believe-about.html#main" rel="nofollow">https://jeremyhussell.blogspot.com/2017/11/falsehoods-progra...</a>
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".<p>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.<p>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.<p>I'm on my phone so it's a bit laborious to test more
This is a fantastic read.<p>> "Time passes at the same speed on top of a mountain and at the bottom of a valley".<p>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?
The one about CS students is very poignant <a href="https://www.netmeister.org/blog/cs-falsehoods.html" rel="nofollow">https://www.netmeister.org/blog/cs-falsehoods.html</a>
I would love an annotated falsehoods. For instance, one of the falsehoods programmers believe about programming:<p>Most processors in active use are 32-bit or larger.<p>16-bit or larger?<p>8-bit or larger?<p>OH COME ON!
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.<p>[1]: <a href="https://medium.com/gender-2-0/falsehoods-programmers-believe-about-gender-f9a3512b4c9c" rel="nofollow">https://medium.com/gender-2-0/falsehoods-programmers-believe...</a>