Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A curated list of falsehoods programmers believe

github.com

Post reply on HN
Print view View original

121–128 of 128 posts

Re: A curated list of falsehoods programmers believe

#121

Post by slg »

lostcolony wrote: post #118
slg wrote: post #112

Earlier quoted context omitted.

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 incompl…

Not sure if "for the parent" was directed at me or the parent of my comment, but you and I are in complete agreement.

Re: A curated list of falsehoods programmers believe

#122

Post by boredumb »

ajford wrote: post #106
boredumb wrote: post #32

Earlier quoted context omitted.

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 ge…

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

Re: A curated list of falsehoods programmers believe

#123

Post by ajford »

boredumb wrote: post #122
ajford wrote: post #106

Earlier quoted context omitted.

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 ge…

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

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.

Re: A curated list of falsehoods programmers believe

#124

Post by RobertRoberts »

silvestrov wrote: post #96
RobertRoberts wrote: post #67

Earlier quoted context omitted.

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.

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.

Re: A curated list of falsehoods programmers believe

#125

Post by remram »

NateEag wrote: post #120
remram wrote: post #89

Earlier quoted context omitted.

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.

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

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.

Re: A curated list of falsehoods programmers believe

#126

Post by alam2000 »

remram wrote: post #89
NateEag wrote: post #12

Earlier quoted context omitted.

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…

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.

No post body was provided.

Re: A curated list of falsehoods programmers believe

#127

Post by NateEag »

remram wrote: post #125
NateEag wrote: post #120

Earlier quoted context omitted.

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

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.

Re: A curated list of falsehoods programmers believe

#128

Post by ziml77 »

themadturk wrote: post #108
ziml77 wrote: post #101

Earlier quoted context omitted.

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

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…

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.
Post reply on HN