3 ms·

I find this category of posts ("falsehoods programmers believe about X") to be patronizing and unhelpful. Most of these lists (this one included) don't give goo

I find this category of posts ("falsehoods programmers believe about X") to be patronizing and unhelpful. Most of these lists (this one included) don't give good explanations and don't have guidelines for how to avoid the problems that are highlighted. It's usually just a list of condescending gotchas.

robertAngst 8y ago
Isnt every language unique? I feel like this teaches a way of thinking.
jm__87 8y ago
Really? While I personally don't need to work with phone numbers for my job, I found this list to be incredibly interesting. For many, this type of knowledge is often attained by making incorrect assumptions in your code/system design and having them proven wrong over time. Having a list like this which lays it all out for you in one shot is amazing.
nomel 8y ago
I think you're being a bit harsh in this case. I don't think many of these have a useful explanation that would stay within the useful scope of a list like this. Knowing the local implementation details of Argentina dialing requirements, and why the 9 needs to be dropped, most likely involves long-gone phone carries, organic implementations, and local politics. Expecting guidelines for most all of these is not realistic since many are just "how it is". For most, the guideline is an obvious "don't do/expect this". If your list is mostly comprised of unexpected behavior, then "falsehoods x believe" is probably ok. As for avoiding the problem, you can't always avoid reality; sometimes you have to accommodate its weirdness, especially when dealing with > 100 year old systems with massive interoperability problems.
nerdile 8y ago
I find these helpful when my team is designing a feature that intersects with this kind of "gotcha" area, and it sets off warnings in my mind, "I know there's something tricky about this business requirement but I can't put my finger on it...", these type of lists at least help me identify particular pitfalls, even if they don't provide solutions, so I can provide specific and scoped concerns to push back on or clarify the business requirements. Some people just also really find these fun to think about.
- sneak 8y ago
  Yup! There are lots of things like this, where I don’t have the list memorized, but I remember that there is a non-trivial, non-obvious list of considerations to take into account when doing a certain thing in a non-fragile (and non-discriminatory) way. A list of these lists might be useful.

robertAngst 8y ago

Isnt every language unique? I feel like this teaches a way of thinking.

jm__87 8y ago

Really? While I personally don't need to work with phone numbers for my job, I found this list to be incredibly interesting. For many, this type of knowledge is often attained by making incorrect assumptions in your code/system design and having them proven wrong over time. Having a list like this which lays it all out for you in one shot is amazing.

nomel 8y ago

I think you're being a bit harsh in this case. I don't think many of these have a useful explanation that would stay within the useful scope of a list like this. Knowing the local implementation details of Argentina dialing requirements, and why the 9 needs to be dropped, most likely involves long-gone phone carries, organic implementations, and local politics. Expecting guidelines for most all of these is not realistic since many are just "how it is". For most, the guideline is an obvious "don't do/expect this". If your list is mostly comprised of unexpected behavior, then "falsehoods x believe" is probably ok. As for avoiding the problem, you can't always avoid reality; sometimes you have to accommodate its weirdness, especially when dealing with > 100 year old systems with massive interoperability problems.

nerdile 8y ago

I find these helpful when my team is designing a feature that intersects with this kind of "gotcha" area, and it sets off warnings in my mind, "I know there's something tricky about this business requirement but I can't put my finger on it...", these type of lists at least help me identify particular pitfalls, even if they don't provide solutions, so I can provide specific and scoped concerns to push back on or clarify the business requirements. Some people just also really find these fun to think about.

sneak 8y ago
Yup! There are lots of things like this, where I don’t have the list memorized, but I remember that there is a non-trivial, non-obvious list of considerations to take into account when doing a certain thing in a non-fragile (and non-discriminatory) way. A list of these lists might be useful.