11–20 of 128 posts
[1]: https://medium.com/gender-2-0/falsehoods-programmers-believe...
> 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 t…
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?
> 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.
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 don…
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.
> 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 t…
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…
> 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 t…
Can you provide us with an example?
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.
"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.
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.
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.
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 don…