Shibboleths that get you past the initial script stage - <AUTHOR> https://twitter.com/patio11/status/1201003855770607618 <comment><USER2> I've found that pretending to know someone's profession, or one related to it, is generally a _very bad_ approach. It's easily seen through, at which point you're worse off than before. Instead, what I do with members of other professions is try to impress on them that I do _not_ know their business but respect its complexity and our roles within the scenario. Whether it's a doctor or a plumber or even a computer technician (a field which I probably _do_ know better than they do), I explicitly steer away from diagnoses even when I have a pretty clear idea what the problem is. Instead I describe as clearly as possible symptoms, timing/frequency, possibly related changes, things I've tried and results I've gotten, etc. This has generally worked much better for me than deceptive or manipulative hacks. Often I get thanks or compliments for having made their job easier, which makes me happy. YMMV

<comment><USER3> This method works wonders for corporate tech support. They're pretty used to the "my monitor won't turn on (it's not plugged in)" type users so when you try to tell them you know what's wrong, they assume you're there former type and you have no idea what you're talking about. Instead I very clearly tell them the specific symptoms and relevant information that they would look up anyway.

Recently I had a corporate installed process maxing out my CPU so I went to the help desk to see the techs (the triager at the front desk thought it might be a fan issue and that I didn't know what was wrong). Since I was able to tell them the exact process and other details, they immediately recognized it as a specific issue they had seen before and we skipped the whole diagnosis back and forth. If I had gone in there and said, "the fan is running really high" I'd probably still be there.

<comment><USER4> I do support along with my usual dev work and interface with users daily. I can't count the amount of times I've heard "I'm pretty sure it's because of..." followed by something completely unrelated, along with a stubborn resolve to not try the professional's recommended solution

<comment><USER5> I think I'm about 50/50 on thinking their solution is absolute bull and being right, and having made a retarded mistake and their solution solving everything.

<comment><USER6> This seems like a very scalable sane default presumption, in any case.

</comment></comment></comment></comment></comment><comment><USER7> Many of these are equivalent to demanding to speak to the manager in order to get what you want. That can backfire quickly if you're not careful.

> Present as if you are collecting a paper trail. Prominent indicia of this > include notebooks, organized files, and repeatedly asking for specific > names, dates, and citations for authority "for my notes."

I worked at a smaller company where any semi-threatening support requests were escalated up the chain to me. The "I'm taking notes to use against you" trick was a sure-fire way to get your ticket escalated, but it had the reverse effect of what customers expected. Our front-line support was empowered to diagnose customer problems, issue refunds, replace product, and even give customers free upgrades as a token of apology.

However, once the customer threatened us with the note-taking act, we had to be extremely careful about anything that would admit fault, lest they try to use it against us later. Or worse, try to take our statements out of context and tweet them to the world. Once the customer escalated the request, they got slower responses (support wasn't my primary job), more limited options (minimize potential admissions of fault), and narrowly constrained communications (assume every response will be retweeted out of context to make us look bad).

Before you try these "Dangerous Professional" tricks, please just try to be a decent human with the front-line support staff. They deal with difficult customers all day, and the last thing they want to do is encourage another person to play the difficult customer role to get what they want. The opening example (Xcode visible in dock creating mutual understanding) is very different than sending your demands directly to the company's general counsel or threatening to take notes for future retaliation. Please don't use that as option 1 in your communication toolbox.

<comment><USER8> > However, once the customer threatened us with the note-taking act, we had to > be extremely careful about anything that would admit fault, lest they try to > use it against us later.

That is hardly fair as the whole "this conversation may be recorded for training purposes" puts the caller on edge right from the start. Are they allowed to record the call too? Is that legal?

Obviously, the caller should just record the call and tell the other side they are doing that. I guess most people don't know how to record calls.

<comment><USER9> Maybe not in larger organizations, but in smaller ones those recordings really do get used for training purposes. And to verify claims about what _agents_ say. I don't think the intent is to intimidate callers, but to let them know that something an agent says to them can be verified. I know it saved me before when someone claimed I was threatening them and using inappropriate language.

>Is that legal?

For the most part yes.

>Obviously, the caller should just record the call and tell the other side they are doing that. I guess most people don't know how to record calls.

Yes they should. It's even better to take notes on things you miss by listening to the recording.

From experience, though, the people acting like "Dangerous Professionals" are just dangerous to my psychological well-being because it's almost impossible to distinguish them from any run-of-the-mill ass hole.

<comment><USER10> As a customer I would have zero expectation that the company would use one of their recordings to verify something in my favor.

</comment></comment></comment></comment><comment><USER11> Find the accounting department at work and make as many friends as possible.

These people see the "numbers" (and that is the heart of any business). They can get your checks expedited (reimbursement or for vendors). They can tell you when a lay off is coming, or when the company blew out the numbers. Most of them keep booze at their desks. All of this will come at the price of coffee and doughnuts/pastries/baglels at the end of the fiscal year, or during an audit.

<comment><USER12> Or when they close out the quarter. Don't skimp!

<comment><USER13> I made a friend in the accounts department when we had to reconcile our credit cards. He was manually copying and pasting stuff into excel for reports for his boss.

Needless to say I whipped up some easy to use scripts that did the job for him. It changed my relationship with that department.

You become visible and friendly. You're not just someone making work for them.

</comment></comment></comment><comment><USER14> I've given thought in the past to some sort of 'support reputation system'. After calling tech support, they'd rate your manner and how capable you seemed, and this would feed through into your future calls (e.g. calling an ISP with a genuine + very technical question might mean you go straight to the highest tier of tech support next time you call).

It would save time for tech support workers too; no need to vet very tech capable callers for things like 'have you tried turning it off and on again'. So theoretically, the call wait time might even reduce for callers with simple/obvious questions.

There are probably some details to iron out and problems to solve, but the basic idea seems pretty feasible to me.

<comment><USER15> Over the years, the people who were technically capable were the ones who made the most unnecessary work for me. I trained myself to ignore everything they tried to do to solve the problem. If I have a technical problem, my colleagues should do the same with my input.

<comment><USER16> I had issues before were I was 100% convinced to know the issue and gave the supporter a really hard time walking me through the script. Wasn't as pretentious of an asshole anymore after the "this won't work, it has nothing to do with my issue" actually worked.

Nowadays I'm always trying to walk through the steps posted in the self help manuals before I actually call. If you tell them that you already did everything in this manual, they also move on quickly after a couple of questions to double check.

</comment></comment></comment><comment><USER17> > Any bureaucracy: Present as if you are collecting a paper trail. Prominent > indicia of this include notebooks, organized files, and repeatedly asking > for specific names, dates, and citations for authority "for my notes."

This is my wife. A survivor of over three decades in the corporate world.

<comment><USER17> Edit: I wasn't clear that I respect her hugely for this.

</comment></comment><comment><USER18> Another article from the same author on how to be a Dangerous Professional: [https://www.kalzumeus.com/2017/09/09/identity-theft- credit-r...](https://www.kalzumeus.com/2017/09/09/identity-theft-credit- reports/)

(HN discussion: [https://news.ycombinator.com/item?id=15206926](https://news.ycombinator.com/item?id=15206926))

<comment><USER19> > "But I'm not a shareholder!" A surprising amount of Americans are > shareholders in large financial institutions. Do you have an IRA? Does it > invest in e.g. mutual funds? If you own a mutual fund or index fund, you are > highly likely to beneficially own fractional shares of US financial > institutions. Someone who owns 0.01 shares is a shareholder; welcome to the > magic of capitalism.

I like this guy. He has great insight, this is very well put :D

<comment><USER20> > _I like this guy. He has great insight_

I'm sure customer service people and healthcare professionals _love_ people coming on premises and throwing their weight around with exaggerations and half-truths.

The people I know would put you on the bottom of the list.

<comment><USER21> You're lacking context. It says that when you don't know where to send correspondence at big banks you could try and address investor relations because they are usually bored and will gladly forward your complaint to the right department. This is where the investor part comes in. And only there. Other suggestions are that you could address the legal department because they are diligent by law. Or the CEO, because if it gets handed down from their office it will have more weight.

Note that the cases talked about involve legal deadlines so knowingly delaying to handle them is not a good option.

<comment><USER20> > _Note that the cases talked about involve legal deadlines so knowingly > delaying to handle them is not a good option._

Are we reading the same thread? The cases talked about are mundane customer service interactions.

My significant other works in consumer facing healthcare. Every day customers come in proclaiming they "know the owner" or "are a lawyer" or "will take their business elsewhere", expecting to be prioritized. This isn't some clever life-hack; the people who do it are, in my opinion, jerks.

<comment><USER21> I'm talking about the article linked in the comment upthread which is about identity theft. Where in that article or the thread was it suggested to refer to yourself as a shareholder to customer service? It's only ever mentioned as a reason to contact investor relations.

The author specifically recommends against grandstanding exactly because it signals "not a professional". So I really don't get your complaint.

</comment></comment></comment></comment></comment></comment><comment><USER22> Interesting USG shibboleths are using the correct acronyms, especially for insider stuff (TDY, "allowances", "authorities", and referring to NSA as NSA and not "the NSA", CIA as CIA and not "the CIA", State for "the State Department", etc.)

<comment><USER23> Is that good grammar? If you expand out the acronym you get "I work at National Security Administration," and if you remove the adjectives you get "I work at administration." Administration isn't a proper noun so that's why you would want to use "the."

In electrical engineering you are supposed to say "DIP" which stands for dual inline package, but laymen tend to say "DIP Package" which expands out to "Dual inline package package." In that case, having the wrong words adjacent to the acronym means you don't know what it stands for. That's in contrast to "the NSA" vs. "NSA," where the public (might?) have it right.

<comment><USER24> The more common ones I hear are "PCB board" and "MCU microcontroller". "CAD design" used to bother me too, but I think it's become its own legitimate term for the sub-genre of CAD, since we're used to also using Solidworks for stress analysis or simulations.

</comment></comment></comment><comment><USER25> This is (hopefully not) obnoxiously off-topic...

As a Hebrew speaker, I wish the "shibboleth" idiom (which is a good one) was translated, rather than transliterated. laoned idioms are inherently exotic, and this one is worth demystifying

It means any choice of word (or pronunciation, in the literal example) that clearly identifies the speaker's group affiliations.

A good modern example is "LondonDerry/Derry. This'd be my my choice for an English translation of shibboleth.

These tweets are about hacking shibboleths, which is advanced mode. Basic mode would be just noticing shibboleths, and also why and how they so clearly identify speakers.

Shiboleths can have serious weight, can be used to disarm/arm. They're probably interesting to text analysis as a classifier. You can use them to reliably imply things about you, like patio does

One hack among many possibles. I'm looking forward to Mackenzie's modern Machiavelli YouTube series using Derries.

<comment><USER26> > _I wish the "shibboleth" idiom (which is a good one) was translated, rather > than transliterated. [...] A good modern example is "LondonDerry/Derry. > This'd be my choice for an English translation of shibboleth._

Well, the thing is, I'm not an Englishman so have no idea what's the deal with 'Derry' is, but I know what a shibboleth is. It has become an English term—and btw not an idiom in English since it has no other meaning in that language.

<comment><USER25> I agree. Terms become terms and we can't change it.

I just meant that idioms tend to be richer when the source is material.

Point taken on finding an example that everyone understands.

Any political context creates shibboleths by the dozen. The UK is good for making ones that stick around. "Nationist" and "National" political movements, for example, are apposite (and opposing).

<comment><USER26> Yeah no, don't do that. After reading about the Derry thing, I realized I better forget all about it and never mention it in the presence of an Irishman, a Northern-Irishman or anyone else from GB, and especially not botch my reference to any one side. 'Shibboleth' has the nice quality that no Ephraimites recently had, or are likely to soon have, misfortunes because of the phenomenon, and the whole affair was three thousand years ago.

Where I'm from, some people, having nothing better to do, occasionally raise noise saying that 'to each his own' is offensive because it happened to be written by Nazis on a concentration camp. I don't think I need any more unnecessarily politically aroused stubborn people around than there already are.

<comment><USER27> > never mention it in the presence of an Irishman, a Northern-Irishman or > anyone else from GB, and especially not botch my reference to any one side

It's really only an issue in written form.

In spoken form, the London part is silent so they're both just pronounced Derry..

Signed,

An Irish person.

</comment></comment></comment></comment></comment><comment><USER28> This is not always fair but saying "500mg of acetaminophen" is more likely to get you labeled a kook or someone with illness anxiety disorder, at best someone trying too hard, rather than a pro. Doctors in the US say Tylenol.. like most brand names it's easier to say than the generic.

<comment><USER29> Exactly this. It's mostly just the ivory-tower kind of docs that say "acetaminophen" over "Tylenol." If you use the generic of something like Zosyn "Pipercillin/Tazobactam" you'll firmly go in the weird category. Same with most (but not all) antibiotics. The normal parlance changes from generic to trade with each drug and even region of the country.

The actual medical shibboleth is knowing your dose and dosing interval, total doses over time period X, dose adjustments, that gives doctors the information they need about your drug. Basically just know your history down cold. You'll be forgiven for mispronouncing med names, using the trade or generic name when the other one is more common, etc. Nobody cares. _All (yes, all) doctors have a specific framework when it comes to history taking, and it 's easy to get. And it's easy to tell when people don't get it._ It goes something like, "I (or pt Y) have med problem x, y, z. Recently, I noticed u happening. I tried a, and then b but neither worked." Boom. You're now miles ahead of everyone else seeking care, you're not wasting time while the doc tries to organize and digest everything you're saying, it's that simple.

</comment></comment><comment><USER30> For health insurance claims in the US, apparently you want to say "I want to file a grievance", at least in Massachusetts (magically fixed $5000 bill where health insurance company was obviously lying). I'm told "I want to talk to the ombudsman" also works.

<comment><USER31> Doing this for regulated utility companies (e.g. electric, natural gas, etc.) generally also works.

NYC's electric utility, Con Ed, was giving me a massive run around [0] until I filed a complaint with the New York State utility regulator. After that, Con Ed fixed my problem within a week.

[0]: Long story short, Con Ed installed new electric meters that were supposed to automatically send readings to themselves but they never "provisioned" it (to this day, I don't know what "provisioning" means). But since they had installed those new meters, they stopped sending out meter readers to my apartment building despite the building manager repeatedly making appointments that the meter readers never showed up to. Consequently, my apartment building of ~400 units got estimated bills for three consecutive months.

</comment></comment><comment><USER32> >it isn't a state secret that "500mg of acetaminophen" and "a Tylenol" are the same thing

I always make a habit of specifying the chemical name anyway since certain drugs have different names in different regions. For example, if you were to order Benadryl in the USA, you'd get diphenhydramine, but in the UK, you'd get cetirizine. Also sometimes if you specify the brand name, they'll give you the brand, rather than the generic.

<comment><USER22> Another pharmacy one is just saying "brand" vs. "generic", generally.

</comment></comment><comment><USER33> Had something similar at the Apple Store as well the other day. I had the wifi turned off on my laptop while waiting, and when the genius came over and turned it on, it wouldn't connect. After about a minute we came to the fact that I used (google|cloudfare)'s DNS (apparently Apple's wifi doesn't like that), which was enough of a signal that we likewise skipped a few steps.

</comment><comment><USER34> The misuse of slang is probably the most common indicator that a person is not really a member of the group. Or not even slang, but just using the wrong word. For example of both, I know a businessman who retired recently and decided in retirement to present himself as a laid back ex-hippie (I live in Santa Cruz - a good choice of persona for this area) He grew his hair long and started wearing tie-die. Except, he referred to himself as a "hipster" back in the 60's who did a lot of "psychotropics" instead of psychedelics. It was obvious to me at least that he was never a hippie in the 60's and this was borne out later

<comment><USER35> Note that the word "hippie" actually comes from an older usage of the word "hipster" ([https://www.etymonline.com/word/hippie#etymonline_v_12029](https://www.etymonline.com/word/hippie#etymonline_v_12029)).

<comment><USER34> Right, but hipster usually meant cool cat beatniks, not flower child hippies

</comment></comment></comment><comment><USER36> >A bank: a) Do it only on paper. b) Address to any of Office of the President, Chief Compliance Pfficer, General Counsel, or Investor Relations.

My dad speaks English as a second language and asks my family to proofread things. I have no idea where he got this from, but there was a period of time when he'd write letters addressed to the President of JP Morgan, or, The Comptroller of Maryland, etc. At first we all thought he was just being kooky, but lo and behold these letters were effective for all sorts of issues.

<comment><USER37> This is my dad too. I thought he was nuts, but it was very effective.

Looking at your name I am going to assume that like me you are from the former USSR.

The explanation my dad said is the following: a lifetime of dealing with soviet bureaucracy informed him that orders always flow down, and each worker tries to prevent complaints from flowing up. Therefore, to get a problem resolved, your request has to come from up high in the bureaucratic hierarchy.

The easiest way to do it? Write to the very top and hope they forward it down with a note saying "fix it". Then it will get fixed.

<comment><USER38> Soviet Life Lessons needs to be its own site or at least video series. I'm being serious as someone who lately has been reading up on the Soviet and realizing that its people developed amazing survival skills to deal with the trauma of daily life.

<comment><USER36> This isn't quite what you're describing, but [https://www.youtube.com/channel/UClXTAMdHwvWdmFyOlQmEtpQ](https://www.youtube.com/channel/UClXTAMdHwvWdmFyOlQmEtpQ)

</comment></comment></comment></comment><comment><USER39> Somewhat related, but when working with new clients for freelance work, I usually ask them if they can write complex Excel functions, make their own website with HTML and if they know any programming languages. After that, I adjust my level of jargon and what analogies I use to explain stuff to match what they know.

</comment><comment><USER40> Technical support would go more smoothly if they asked about the submitter's technical level.

Dreamhost's support form used to have a field on how technical are you. The options went something like "I know nothing" to ""not being funny, but I probably know than you".

<comment><USER41> I wonder why they dob't do this - it would be a win-win for every ne. I've done this for years, describe in the initial ticket your environment, and say that you're reinstalled several times. Stuck for weeks with Microsoft and Adobe on the part where they just keep parroting the script and asking to reinstall no matter how many times you say you're done it. It's infuriating!

<comment><USER42> I imagine a lot of people would oversell their capabilities. And to be fair, as annoying as it is to run through a script of basic things, _sometimes_ it will work, even for experts.

</comment></comment></comment><comment><USER43> Relatedly, when on an automated phone line "press 1 for accounts" etc I just mash the keypad and/or make random noise down the phone until it sends me through. Otherwise try staying quiet after being presented with options.

</comment><comment><USER44> I have found when speaking to police officers, that they find it soothing if I spell names in the phonetic alphabet (alpha, bravo, charlie) and describe people and events in a structured way, as if I am intending to assist their note taking. (a Caucasian female, approximately five' nine, professional appearance, mid forties, dyed red hair cut shoulder length, in a grey coat driving a silver mercedes convertible ALPHA WHISKY NOVEMBER SEVEN SEVEN NINE')

</comment><comment><USER45> The one example with regards to doctors has worked for me in the past. I am sure the doctor didn't get the impression that I was a doctor also (I'm not), but when in my initial meeting with a new doctor the fact that I knew the non- brand names of OTC medications and mentioned only asking for antibiotics after having a fever that wouldn't break for more than 48 hours she basically said "oh you know what you're talking about, if you ever need antibiotics just call me and I will call in a prescription for you." I'm not a medical professional, I'm just technical and value precision and knowledge, and doctors seem to appreciate that. It helps if they can relax and not worry about overwhelming the patient by suddenly dropping chemical names or the real names for disorders, diseases, etc. If you show that you're actually interested in that stuff and not an 'alternative medicine' type that they have to pick and choose their words with like tip-toeing through a minefield, they can relax and do their job.

<comment><USER46> I'm very skeptical that any doctors think you are a doctor because you know Acetaminophen and Tylenol are the same thing (the example from the tweets) in general.

I know doctors and they are typically very used to people 'knowing' random bits from their googling before they came in, and would rarely act like the patient has an actionable expertise even if they do.

In this example I suspect the doctor would've ended up giving you the option to just call in for antibiotics at some point, regardless of your knowledge of the names of OTC medications.

<comment><USER47> > I'm very skeptical that any doctors think you are a doctor because you know > Acetaminophen and Tylenol are the same thing (the example from the tweets) > in general.

That's what I thought too, but at the same time I don't doubt the rest of what otakucode described. Being well prepared and honestly interested gets you often a long way. More importantly the expert (the doctor in this case) does - in my experience - almost never care if you are a _real_ doctor, your wife is a doctor, you abandoned med school, etc. All they care is that there is an individual that seems to speak their language and that they can at least try to skip the translation layer and explain the problem in their own language - which I think is relief to them.

Being well prepared and honestly interested instead of trying to leave the impression to be the expert is the key here I think. With that being said I wouldn't advise stressing not being an expert in the field either. This only puts up a barrier and puts the real expert under pressure to switch on the translation layer again.

</comment></comment></comment><comment><USER48> > (This is partly about demeanor, above all not looking confused about the > process, and partly judicious use of shibboleths. I'm occasionally surprised > how few are required; it isn't a state secret that "500mg of acetaminophen" > and "a Tylenol" are the same thing.)

I can't think of a single situation in which it's a good idea to make it appear as if your medical knowledge is greater than it is. When the conversation shifts to whether your child is allergic to diphenhydramine, you'll wish you had taken a different approach.

Try honesty and interrogative-led questions instead.

<comment><USER49> It would be remarkable if one could be allergic to a general antihistamine such as diphenhydramine. If anything I would suspect an allergy to an adjunct or inactive component.

</comment></comment><comment><USER50> I had never seen the word "shibboleth" before reading the article about "The Real Class War" this week, and now I'm seeing it in the title of a submission days later.

It's not spiking in google trends[1], but I wonder if the usage of this word spiking in this community? Or did this twitter user read that article? Or is it just coincidence?

[1] [https://trends.google.com/trends/explore?date=today%201-m&q=...](https://trends.google.com/trends/explore?date=today%201-m&q=shibboleth)

<comment><USER51> Might be the Baader-Meinhof effect.

[https://en.wikipedia.org/wiki/List_of_cognitive_biases#Frequ...](https://en.wikipedia.org/wiki/List_of_cognitive_biases#Frequency_illusion)

</comment></comment><comment><USER52> How about 'lollapalooza' this word was similarly used to distinguish friend and foe

<comment><USER53> Likewise for Scheveningen (Dutch/German)

<comment><USER54> There is an even nicer word for dutch/german. slechtstschrijvende/schlechtstschreibende. Yes, 9 consonants in a row and you have to pronounce all of them like you are a beatboxer.

<comment><USER52> Yet I'm downvoted as usual the whole point of these shibboleths is that they're hard to pronounce but the LondonDerry/Derry example set forth is not hard to pronounce but based on cultural context anyone can call San Francisco "Frisco"

</comment></comment></comment></comment><comment><USER55> Of course if you take this to it's logical conclusion you end up with Masonic handshakes...

</comment><comment><USER56> Today, Jews who attend synagogue know the bible, because it's read, chapter by chapter, out loud, every Shabbat, Monday, and Thursday, and continuously studied in yearly and multi-year cycles. Yesterday, Jews everywhere heard the story of Esau and Jacob, read in Hebrew.

I don't think any Christian denomination does this, so unless you attend a specfic religious school you'll never learn the Christian bible (which includes parts appropriated from the Jews)

<comment><USER57> Sorry, but this is a completely inaccurate generalization of both Jews and Christians, both of which are incredibly diverse populations with practices that vary incredibly widely by denomination, country/region and social group.

Bible study groups are a common Christian thing in many, many churches, for one. Also, it's fairly loaded to suggest that Christians "appropriated" the Old Testament. Perhaps you could choose less divisive language.

<comment><USER56> It is in poor taste to refer to the Hebrew Bible as the "old Testament."

<comment><USER58> It's common usage within the Christian community to refer to it as such. Christianity's roots are in Judaism - and that fact doesn't constitute poor taste. So neither does using the Christian term for the Tanakh within a Christian context.

Now, knowingly calling it that to a Jew might possibly be interpreted as a form of disrespect, but in my experience most Jews don't mind at all. It's a shared scripture, so there's common ground there regardless of the terms we use.

<comment><USER56> Saying that the bible of a certain religion is obsolete and has been superseded (which is what "old" means in this sense) can't be interpreted kindly to say the least. You have every right to feel that it is obsolete, of course, but you should at least realize that this is not going to be considered well by the people whose holy books you appropriated, modified, and replaced.

<comment><USER58> > which is what "old" means in this sense

You're very mistaken. "Old" in the term "Old Testament" does not mean obsolete and superceded, at least not in the way you mean. To think so would be considered heresy from most mainstream Christian schools of thought.

"Old" and "new" are, with regard to the sections of the Christian bible, temporal designations delineating the law and the prophets that were written _before_ Messiah and the writings that came _afterward_. But all of it is considered to be the holy word of God.

As any Jew knows, the coming of Messiah heralds major changes in religious life and practice. As Moshe said, "you shall listen to him". If some believe that has happened, that's no slight on the former scriptures. In fact, if such a Messiah were to declare them no longer the word of God, any Jew would know and be right to say that such a person is a false messiah.

So there are _aspects_ of the Tanakh that the coming of Messiah causes to be obsolete — like certain temple practices, or the first covenant at Sinai. Jeremiah 31 speaks of a "new covenant" God will make with the house of Israel and Judah. That doesn't mean the first covenant is no longer God's word.

It's like when David gave directions for the construction of the temple and Solomon built it, that didn't mean Moshe's directions regarding the tabernacle were no longer God's holy word — even though there never again was a tabernacle.

</comment></comment></comment></comment></comment></comment><comment><USER59> So when this guy is dealing with a doctor. He pretends to be a doctor himself? I assume the doctor would notice the guy is acting like a weird asshole for some reason but not mention it.

I guess the tweeter thinks hes being cool and 'hacking' his interactions with people, but I reckon he's just acting like a weird asshole and people are having to deal with it.

This is just quite funny imo.

<comment><USER60> Completely agree. The guy should look at his own profession first and realise how easily he could spot people who learnt a few phrases or facts then look again at himself.

<comment><USER59> Yes, exactly.</comment></comment></comment>


WHO Panel: 'Limited Evidence' Suggests Cell Phones 'Possibly Carcinogenic' - <AUTHOR> http://www.webmd.com/cancer/news/20110531/expert-panel-cell-phones-might-cause-brain-cancer

<comment><AUTHOR> What I don't get is this: With more than 5 Billion people using mobile phones, according to the article, wouldn't we have already seen the first waves of a tumor epidemic?

I understand that children are particularly susceptible and the trend in children getting phones is a recent one. But mobile phones have been available en masse for over 20 years -- (I've had one for 15 years) -- so you would think that adults who have had phones for most of that time would have been exposed enough for there to be some obvious effect.</comment>


Functional Javascript - <AUTHOR> http://www.hunlock.com/blogs/Functional_Javascript

<comment><USER2> jquery ftw

<comment><AUTHOR> Frameworks are great, but they're not a substitute for knowing the actual language well.</comment></comment>


The Rust compiler isn't slow; we are - <AUTHOR> https://blog.kodewerx.org/2020/06/the-rust-compiler-isnt-slow-we-are.html <comment><USER2> I seriously hope the Rust community won't get used to these slow compile times the way the C++ community got used to it. C++ has some really big flaws that can cause compilation time to become unbearable but for some reason boost really loves to abuse these flawed features. Boost is almost as bad as npm. You include a single header and then you end up including thousands of other boost headers. When I looked at the include hierarchy of a single cpp file 99% of the includes were from boost and maybe 30 includes were actually from the C++ project itself. I'm sure you could cut down 80% of the compilation time simply by removing boost and replacing it with different libraries.

I even found a reddit submission that shows how absurd boost is: [https://www.reddit.com/r/cpp_questions/comments/2hzobl/reduc...](https://www.reddit.com/r/cpp_questions/comments/2hzobl/reducing_compile_time_should_i_drop_boost/)

<comment><USER3> In my experience, Rust compiles orders of magnitude faster than similar C++ code for initial compiles. For incremental compiles, Rust is infinitely faster. C++, even if you use Modules, needs to re-compile, re-instantiate, re- check all the templates all the time. I speculate that this alone is what probably is responsible for the largest difference in compile-times.

Comparing Rust with C here is hard. As others have mentioned, with C, you typically only use libraries that are installed in your system. Rust does not have a global system cache for libraries, and I don't think there is any package manager installing pre-compiled Rust libraries, so at least for the initial compiles, Rust needs to do much more work than C, for Rust dependencies at least. If your Rust project only depends on C libraries, then there is no work to be done of course.

For incremental compiles with C, it is hit or miss. If your C project is properly "modularized" (split into a lot of small enough TUs), then when you change a TU, C only needs to recompile that one TU. In our benchmarks, Rust is faster for that situation, and speculating, this is because the Rust compiler only recompiles the parts of a TU that actually changed.

In practice, however, Rust is much slower than C, because people do not write small Rust TUs, but absurdly huge ones, at least, by C standards. A Rust TU (crate) usually is mapped 1:1 to a C library, which often contains dozens or hundreds of TUs. Just the cost of testing what changed in a Rust crate is often larger than the cost of blindly recompiling the C TU that has a newer timestamp.

If people would split Rust code like they do with C, then this wouldn't happen. But Rust people are too optimistic in that one day the compiler will be able to somehow auto-magically split a crate into multiple TUs as good or even better than what people do for C manually. And do that determination + the incremental compile faster than what takes a C compiler to blindly recompile a tiny amount of code.

<comment><USER4> > Rust compiles orders of magnitude faster than similar C++ code for initial > compiles

Please avoid misleading statements like "orders of magnitude faster". If that were true, even super-complex projects would compile in a few seconds, given it would be at least 100x faster than compiling C++.

> For incremental compiles, Rust is infinitely faster.

Please avoid obvious exaggerations...

Incremental compiles of C++ take as low as modular is the code. Same for Rust. If you make huge TUs, you get huge incremental compile times.

> C++, even if you use Modules

Modules are not even used yet by any big project nor properly supported yet, and they are not expected to speed up compilation much anyway.

> Comparing Rust with C here is hard.

It isn't hard: C can be compiled _way_ faster than either C++ or Rust because the code and type system is much simpler.

> As others have mentioned, with C, you typically only use libraries that are > installed in your system

C code can be anything. C++ libraries are also included with the system.

> Rust does not have a global system cache for libraries

It does have a cache per user/project/etc., which is basically the same and without it the speed would be atrocious.

<comment><USER5> This type of comment is the worst. What did you add to the conversation besides a bunch of useless "well ackshually"? If you want to respond to a comment, respond to it in full, not only conveniently out of context sentences.

<comment><USER6> The comment makes good points that need to be considered and helps mitigate the unrealistic exaggerations of the parent comment.

This does not fit the "well akshually" trope at all.

</comment></comment></comment></comment></comment><comment><USER7> The article does a good job explaining why a certain project might have a long compile time: dependencies.

But it fails to address how this compares to go or clang of gcc. It mentions those (they take 1/5th the time to compile a similar project), then goes off to explain how it was possible to shave over 75% off the compile time of Rust project, but not if that same trick would shave 75% off a similar go- or c project.

In other words: very good to show us, how, by choosing the correct dependencies compile time decreases. But that does not prove that the Rust compiler isn't slow.

<comment><USER8> > but not if that same trick would shave 75% off a similar go- or c project.

The question does apply to Go, but not C — because the way to reduce compile time for C projects is to just not compile libraries & modules when you don't need to. That's the return from having a stable ABI.

(C++ might be the most interesting in this regard because there's both things - linked / ABI'd libraries as well as header-only "libraries")

[edit: "has" as in "is actually actively used" \- of course you can create C-ABI libraries with Go and Rust too, but it's a rather rare practice]

<comment><USER9> uh what, go does exactly what you applaud C for, but better.

go is extremely aggressive about not recompiling dependencies.

you only pay a long compilation phase the first time you build something. after that its partial compilations all the way.

<comment><USER8> > you only pay a long compilation phase the first time you build something

I'm referring to the fact that there is no "first time build" using a library in C, since C libraries are installed as binaries.

</comment></comment></comment></comment><comment><USER10> I have been tinkering with Rust lately and compile times have been an issue since almost the beginning. After searching around for a bit, I discovered that a significant amount of time is spent in the linker, not in the _actual_ compiler.

By switching from the default GNU gold linker to LLVM LLD, I have managed to shave off a few seconds on every build. There's an open issue [0] about switching to LLD. It still has some compatibility issues but it works fine on my machine and albeit tiny project.

I would be curious to see how compile times improve for other people just by linking with LLD. You of course need to install LLD first and then you can tell the chain to use it:

      time RUSTFLAGS="-C link-arg=-fuse-ld=lld" cargo build

[0] [https://github.com/rust-lang/rust/issues/39915](https://github.com/rust- lang/rust/issues/39915)

<comment><USER11> Most of the stuff your linker has to churn through is actually debug info. If you turn it off, you'll speed up linking whether it's with LLD, gold, or ld.bfd. Do this in Cargo.toml:

        [profile.dev]
        debug = false

<comment><USER10> Thanks, I will test it out when I get home.

<comment><USER4> Note that disabling debug info means way, way harder debugging!

<comment><USER11> As the sibling comment says, you can always turn it back on when you want to do debugging. Personally, I mainly do printf debugging so I don't miss it much. Also there is the option of only turning it off for dependencies like:

        [profile.dev.package."*"]
        debug = false

I haven't tested how big the impact of that is, but it should be pretty large for projects with a larger number of dependencies.

Edit: I've tested it now on cargo-udeps [1], which has a large crate graph but only little code of its own and there is only a small difference between turning off debuginfo for all crates vs only for dependencies, but a sizeable improvement over compiling in debuginfo of dependencies.

[1]: [https://gist.github.com/est31/1bb6e7d6f4be2a23701b8c7c1c678b...](https://gist.github.com/est31/1bb6e7d6f4be2a23701b8c7c1c678b6e#file- comparison-md)

</comment></comment></comment></comment></comment><comment><USER12> Quote: "There is plenty of evidence that suggests rustc is slow relative to compilers for other languages; Go can compile applications with similar complexity in 1/5 the time, and clang or gcc can do the same for applications written in C"

Wait until the author tries Delphi. Then will realize compile times for Go or C are slower then a snail

<comment><USER13> Try V[0] . See [https://fast.vlang.io/](https://fast.vlang.io/) .

[0]: [https://vlang.io/](https://vlang.io/) .

<comment><USER12> I have a project for a client. Nothing much, just your ordinary database driven application, customized for his needs. I use some external libraries from DevExpress (for showing data), from ReportBuilder (german one) to show different reports, etc etc. All in all, since I have sources for all as well, it's around 1 million lines of code. The application itself is just a measly 10k lines of code written by me in past month. So, when I do a "build all" in Delphi, it will go and compile all external libraries and it shows me the lines of code they compiled. Mind you, real lines of code, not empty lines, and it does not include interface/types declarations, just actual code lines - you know, the ones where you can actually put a breakpoint if you want to also debug it. Since my style is to have for each project its own virtual machine, this compiling runs inside the virtual machine, and the files that said virtual machine consist of are sitting on a HDD with 5000 rpm (old cheap style HDD, not an SDD mind you). Takes 45 seconds to do that "build all". Do you have an equivalent V project size to tell me your compile time? For a real application?

<comment><USER13> V at pre-alpha stage. The only real application in V is V itself. See link above for compilation speed of V in V.

<comment><USER12> So another programming language the type "dozens for a dime", that somebody in the middle of their tenure at Uni, out of boring thought "you know what this world is lacking? another programming language".

And after it was done you're like "hey look, V can slingshot a stone up to the hill real fast, hence it can be really fast and really cheap to reach the moon too". Tell you what, when you "reach the moon" using V, same as what Delphi does it, and it's going to be faster then come and talk to me, ok?

</comment></comment></comment></comment></comment><comment><USER14> You could say that Rusts great dependency management is both a blessing and a problem at the same time. C programmers, often motivated by resource constraints, are much less likely to use third party dependencies - not just to save resources but also because it is just much harder to do it and to do it well. They end up just rewriting the parts they need themselves. Because those parts are likely a small subset of a full-featured library, binary size and compile times are smaller at the expense of actual time spent writing code.

<comment><USER15> Also add the time maintaining that code.

<comment><USER16> Do we also need to add the time tracking down issues and dealing with all the licensing and churn issues in mostly unstable third party rust dependencies?

<comment><USER17> I'm about to ship my first Rust project for a client that actually cares about licensing stuff. It's trivial to add a new line to Cargo.toml, but can you legally redistribute it? What MIT-style copyright lines do I need to ship in our License file? Well, let's list the project dependencies and find out how many packages I need to go examine:

        $ ~/.cargo/bin/cargo-tree tree --no-indent | cut -f1 -d' ' | sort | uniq | wc -l
        61

Oi. I'm not sure this language dependency management thing is such a good idea.

<comment><USER18> You might like [https://github.com/embarkstudios/cargo- about](https://github.com/embarkstudios/cargo-about)

<comment><USER17> That looks fantastic, thank you.

</comment></comment></comment></comment></comment></comment><comment><USER19> I had the same experience going from C++ back to C. I was surprised how fast my C code compiled, and how small the resulting executables were, even though I already tried to avoid the worst offenders in my C++ code.

The problem isn't that C compilers are "fast" or C++ compilers are "slow". C++ compilers are very fast, but typical C++ projects just throw way too much work at the compiler (by having too much implementation code in headers, while C headers are typically only declarations).

The underlying problem is that C++ makes it easy (and even encourages through bad practices in the stdlib) to add complexity and hide it under "fancy" interfaces, which indirectly leads to code that's slow to compile and results in a bloated compiler output.

It's possible to create C++ projects which compile just as fast, and result in just as small binary code as C projects (basically "embedded C++", but this means giving up most high-level features that C++ added on top of C (such as most of the C++ stdlib).

In short: C makes it hard to add accidental complexity under the hood, while C++ makes it easy. Add a cargo-style dependency manager to the mix, and the "accidental complexity" problem grows exponentially.

<comment><USER20> Agreed. Especially the stdlib part. In embedded environments I start by removing that. Pretty much cures the bloat issues.

</comment></comment><comment><USER21> The way I read it, the conclusion is that Rust compiler _is_ indeed slow when there are dependencies, even as "simple" as argument parsing?

Now I would like to read why is that, and is it only about the "rebuild time" or also about "make time", once the dependency is built and hasn't been changed. If it's about the rebuild time, I agree that it's not important. If it's a penalty for every use of dependency, then for my tastes it does reduce the number of iterations one can do during the fixed development time.

<comment><USER22> Clap (the argument parser in discussion) does a little more: parsing to correct types, colorful output, generation of shell completions and man pages, fuzzy matching (did you mean X?) and so on.

That aside, I don't know why clap in particular was the problem.

<comment><USER23> Oh, I see. I was wondering how an argument parsing library could be as big as a bytecode interpreter like Lua.

</comment></comment></comment><comment><USER24> I consider clap is a different type of dependency from lalrpop and regex. Clap is part of the application interface and most likely does not change that often. Lalrpop and regex are part of the domain logic and probably change fairly often.

Today, we can separate a Rust application into "app" and "lib". Most of the change would happen inside lib and app would only need to be compiled for infrequent changes and releases. This allows one to use all the fancy features of clap and mostly ignore the compile time cost.

It is annoying to separate a Rust application into "app" and "lib" though, so most people do not do it. They instead opt to replace clap with gumdrop. I think both approaches are valid.

</comment><comment><USER25> Every time you make a compiler faster, I add extra dependencies to all of your projects. I am Wirth's Demon - the enforcer of Wirth's Law!

</comment><comment><USER26> To make fair comparison, you could translate C code very literally to Rust code, not using any "advanced" features or different libs (meaning no_std). Then you could see apples to apples how it'd compare to clang. Probably slower still, but at least you'd know that the slowness wouldn't be due complex generics or macros or something.

</comment><comment><USER27> There is an experiment that anyone interested in compiler speed and the joy of fast iteration programming should do : trying a real fast C compiler: TCC (from Fabrice Bellard)

On my computer, most of the time the compilation is finished before I have time to release the return key...

And the generated code, while not highly optimized, is largely fast enough to test/iterate.

</comment><comment><USER28> Yes.

But "we" also include the c/c++/rust developers here.

This is a puzzle that is hard to crack.

WHY "system language" developers near always produce the MOST slow languages on earth (C, C++, Rust, ....).

And given time, CONTINUE to keep everything wrong with them?

C/C++/rust are among the slowest languages in actual use today. Is kinda ironic them claim to build "fast" stuff and the tool, itself, is slow like hell.

Is even more sad considering that Pascal mop the floor with everything, decades ago, and still do.

> I believe there is more to it than that. I believe it's more of a human > problem than an algorithmic one.

Totally. Somehow, the C/C++ mindset can't build fast languages, not matter how many decades of wasted compile times are behind us.

Is uber funny that you read how certain dude spend A LOT of effort optimizing his code to get a few nanoseconds here and there for the project is building, but somehow, the same love is not give for our core tools.

Is funny that that guy is also me. I waste DAYS trying to cut the build times of my pipeline. DAYS.

Rust is the ONLY lang in this 20 years that make me do busy work of that kind. BTW, I have used more than other +12

\--

Before get angry, remember that Pascal, ADA, Go, exist. And them are orders of magnitude faster than C/C++/Rust. This is not a problem of "but c/rust do that stuff and must be slow", no... is because them, BY DESIGN, are suboptimal tools.

\--

Then why you use rust? Because, in contrast with C/C++, at least give a lot of extra benefits that are not present elsewhere (with the exception of ADA).

We can love AND hate something, at the same time. Funny humans.

<comment><USER29> The systems languages you reference have to do memory management by design. It's very difficult to write a scalable, maintainable, performant operating system or high-performance application in Pasca, ADA, or Golang. While they are all decent, I'm referring to "low-level" as in device drivers or "high- performance" as in game engines. Aside from some toy microcontrollers running go or some userland fuchsia stuff, there's a reason serious stuff still uses those languages. They're slow because they intentionally trade compile time for run-time performance. If I write in such a language, I've got a pretty good idea of how it will run; I don't have to worry about "Oh no, what's the GC gonna do now."

<comment><USER28> Pascal, ADA not have GC.

And C/C++/Rust not have GC... and still ARE slow to compile.

</comment></comment></comment><comment><USER30> > ...this is a dissent to a common criticism that the compiler is slow. In > this discussion, I will argue that these claims are misleading at best.

I think the author failed here.

The article shows the rust compiler is slow but you might be able to mitigate the issue by switching to lighter-weight dependencies or removing dependencies and instead write the parts you need yourself.

These actions are expensive in time spent, involve tradeoffs, and are available only in some cases, so don't generally address the issue of compile times. That is, these are potential mitigations for slow compile times.

</comment><comment><USER31> Compare this to .net and expect to reduce it by another order of magnitude

</comment><comment><USER32> I was talking to my wife about why something around the house was slow to get done. Well, Rust wasn't having that. For a full 30-mins I was on full defense trying to figure out how Rust got into the house. It's everywhere. And it likes to talk! I'm gonna have to get to know it better, because it seems I have no choice. Ok, satire out of the way, let's get to the real points.

The article was a let down at the end. Yes, less code and less dependencies equals quicker builds. No kidding. It does not deal with Rust itself, however.

But at commercial scale this is a real concern. We're a big C++ shop ... but for reasons that cannot be blamed solely on C++ itself, I quit C++ for the last 18 months for GO weary of the 4-day long build times, the huge executable sizes, and fighting the C++ compiler. The only thing worse than a C++ compiler in a bad mood is Oracle's PL-SQL parser (dumb and silent) or when your wife is mad at you.

Problems committed by programmers:

\- builds do not use PCH so C++ builds are indeed slow

\- very old legacy libraries have circular dependencies and sorting that out is annoying

\- certain important, hard to avoid legacy calls hit into a library chain of dependencies that quickly lead to very large executable sizes

\- linking depends on .a files because having tasks link .so files is unreliable in production. Too many tasks, too many libraries, too many versions, too many deployments just too much lead to dependency mismatches leading to cores ... We still link archive libraries not shared but over the last years build teams have taken making the archive files so compiling is usually limited to app code plus whatever self-owned library code was modified. (Not talking language or OS libraries here; that's disciplined. Talking app libraries & tasks for which there are 10000s).

Thus on the whole we can blame the organization not C++ for not being as good as it should at commercial level, very large scale software management. Getting rid of legacy code or refactoring it is another weakness: for the above reasons the effort is often big, and there's always so much new work to do making management of resources tough.

We can blame C++ for other things however:

\- the language is far too complicated

\- the language involves some duplication of effort between headers and source files

\- C++ inherits C's problems with #defines, macros, and other nasty things that break builds at scale with bad things in global scope. Just having a pre- processor is bad. C++ maybe should have been link compatible with C but it dragged in the whole edifice. Other OOP languages were smarter.

\- C++ errors arising out of templates or certain other STL areas produce messages which are 2K+ each. It takes time to see what the hell when wrong. C++ often confuses you with the details. I hope GO generics does NOT do that.

\- Making code allocator aware and capable i.e. to make things behave properly for performance, memory testing when everything should use a non-default allocator, debugging, and so on is real effort. Memory errors are not that easy to track down in C++ for something that _appears_ to care about safety.

\- C++ language complexity drifts into design complexity immediately. If you're <5yrs in C++ you can't really attack a serious project without having Meyer's C++ books side by side.

\- A lot of what makes a C++ class or method "good" i.e. narrow contract, assertion checking, unit testing comes, if it comes at all, from the organization's engineering culture not from C++ itself. In other languages it's more baked into the language.

Of course GO avoids many of these problems by design to say nothing of quick build times. But GO built on 20 years of industrial experience while others created it along the way.

Other OOP languages may be better, but sorry the die has been cast. Ditching C/C++ for something better will still likely need a back door to C because there's too much of it to drop it entirely. Those working close to the kernel will need a C backdoor as well.</comment>


Show HN: An easier way to do Twitter Advanced Search - <AUTHOR> https://twish.xyz/ <comment><USER2> A few suggestions. Please include some links to who the maker is, whether you store searches or not etc.

The tool is great. I love it. was going to build something similar myself, but the website contains no info, have an about section or something, more info signals trusts in the product.

btw, while writing this comment, decided to dig around, clicked on the Tweet button, and got to know the source/creator.

But, seriously a lot of twitter power users use advanced search a lot, including me, so including links to your profile/work would be beneficial to you.

<comment><AUTHOR> Thanks a lot for your feedback. Will get to it asap!</comment></comment>


Yours vs. Mine - <AUTHOR> http://dcurt.is/yours-vs-mine <comment><USER2> Interfaces and marketing that use "my" always irk me by, for lack of a better phrase, _coming on too strong_. I'm all too aware of the human hands that typed out that button label - it seems damned impudent of them to be assuming my voice. It implies a certain intimacy. _My cart_ sounds like an appropriate label for something I've filled, but so long as it's empty trying to foist it off as _mine_ just comes across as a desperate plea for emotional investment.

I think marketeers leveraging "my" tend to envision that we will come to think of their product as like some treasured childhood teddy bear that we hug firmly to our bosoms each night. In life though, when we talk about owning things - my this, my that - it's often in order to identity ourselves with them. For most services, that's a lot to assume. Treading the HN path of avoiding possessive determiners at all may be the wiser path.

<comment><USER3> > I think marketeers leveraging "my" tend to envision that we will come to > think of their product as like some treasured childhood teddy bear that we > hug firmly to our bosoms each night.

I'm not sure if it is as pronounced anywhere else, but my area has a lot of shops that use the prefix in their name.

My Chemist

My Hairdresser

My Bookstore

My House

All places I walk past regularly, and they're all equally as awkward. Same goes for interfaces trying to emulate the same thing.

<comment><USER4> Interesting. I don't think this is a thing at all where I live. Where do you live?

<comment><USER3> Australia. I suspect it's a localised thing.

</comment></comment></comment></comment><comment><USER5> Ready? This is going to blow your mind...

NEITHER.

Just say "Purchases" or "Bookmarks." Not yours, not mine, not his, not hers. Just "it."

Now, get back to writing code!

<comment><USER6> This is a really dismissive comment that could be used to trivialize just about any article and debate here on HN. While it isn't a big issue, this topic is something designer's do think about and a discussion about its effects on user experience seems reasonable. Plus I doubt anyone's losing hours of productivity over this.

<comment><USER7> I disagree, I think if the OP was attempting to make a fair analysis, he should have acknowledged the third option. My immediate thought was the same expressed in this comment, as My & Your add wordiness. I suppose it depends on the overall tone & genre of the software you're (I'm?) designing, but it's an obvious alternative.

<comment><USER8> Dustin's post was not simply about whether to prepend labels with "my" or "your". That choice was an example of a more fundamental concern: whether to imagine the user as seeing an app as an extension of themselves or as seeing the app as a separate entity, and the implications of that in the interface.

It may have been helpful for the post to consider the effects of using no pronouns on a user's mental model, and a better response to the post would be to explore those effects, not to dismiss it outright as a false dilemma. A much better method of dismissing posts that have obvious answers is to not comment on them.

</comment></comment></comment></comment><comment><USER9> From the section of the iOS HIG about writing alert copy:

> Avoid using "you," "your," "me," and "my" as much as possible. Sometimes, > text that identifies people directly can be ambiguous and can even be > interpreted as an insult.

<comment><USER10> I agree with this. Using the example from the article, "Profile" is just as expressive as "My Profile", more concise, and groups better with other similar actions. Taken to its logical extreme, you'll have to put "My" everywhere; imagine GMail with "My Inbox", "My Starred", "My Important Messages", "My Circles", etc.

<comment><USER6> I think pronouns should be reserved more for interactions, where a UI's personality really shines through. So when refreshing your inbox, you may see "Fetching your email", for example.

<comment><USER10> Why does a UI have to have personality? Why can't it just look good and be easy to use? Does anyone actually care if an application is "speaking" as if it is a conscious entity?

<comment><USER11> Good UI design is all about effective communication. If you have a UI that is pretending to be something it isn't (a person) then it is basically lying to you. That's hardly good communication. It's confusing and dishonest.

And believe it or not there are some users who won't understand that it isn't really a person. Some minds are very prone to anthropomorphizing especially when they are dealing with something they find hard to understand and unpredictable like a computer.

<comment><USER12> "Having a personality" is going to happen whatever you do.

Somewhat counterintuitively, this doesn't mean your interface pretends it's a person; but all copy is written by people -- words are used by people only (pretty much), directly or indirectly -- and the words chosen are projecting some personality onto the application whether you want to or not.

There are no words/phrases/instructions without baggage, connotations, etc..

<comment><USER11> I have no objection to that. I just don't want those words written by people to make it sound like the application is a person. The app can talk about itself doing things (it does do things after all) but not as a human being with feelings and stuff.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I mostly agree.

I also think that physical vs. digital is a big determinant of whether Yours or Mine is appropriate. When using a physical object, you are at the very least spatially aware of all of the components. Your pencil, car, hammer are all items that operate due to mechanisms easily understandable at a very basic level simply by observation. There's no mystery. It is purely an object, and it is _my_ object.

Digitally, however, you cannot understand the mechanism by which a mobile app works simply by observing it. There is a level of obscurity, a veil of mystery, as if someone, something were behind the scenes pulling the strings. Unlike looking at an engine and observing all of the gears and rods involved in making an axle spin, one cannot observe bytes of data travelling between microprocessors. I think it's that layer of obscurity that gives digital products a degree of personality that a car or hammer or pencil or knife cannot have. There's something at play that you're not seeing with digital interfaces, and perhaps we most comfortably assume that another human is involved in the process.

</comment><comment><USER13> Excellent thought process on the differences in possessive pronouns.

But what if you go for a more minimalist approach? What if your app doesn't use possessive pronouns at all?

You could just display "Settings", "Settings have been saved!", "Profile picture has been changed." etc and I've seen apps that do this natively.

Although, to a certain extent I suppose that proves his point, as apps will be forced to act as though they aren't using possessive pronouns if they use "My" - it would be a little strange to display messages like "My profile picture has been changed", etc. Using the possessive pronoun "Your" is the only one with special modifiers throughout the app's structure that don't sound redundant.

</comment><comment><USER14> I've always thought there was something condescending about "My" stuff. Like, I need this page to tell me where my stuff is so I don't edit someone else's. Or something.

</comment><comment><USER15> In foreign languages with a polite form of "You" (such as French or German), there is an additional question: should a website use the polite of familiar form.

And it's widely accepted that a website should use the polite form.

<comment><USER16> Is it really widely accepted? I'm still weirded out when _people_ use the polite form. Let alone computers, that's just silly.

Why would a computer/website be polite to me? They have no concept of these things. Just using polite forms doesn't mean you're being polite, you have to mean it. A computer is as of yet incapable of having intentions.

<comment><USER17> Why would a computer use the familiar form? It seems to me that I would uncomfortable if a computer, or worse, a web interface actively maintained by team of strangers, started to address in language that suggested a certain level of intimacy.

<comment><USER16> It might just be my youngness and general disapproval of the polite form speaking here. I really think English has gone in the right direction by removing their polite form in favour of being polite without senseless grammatical contortions.

<comment><USER18> It's a minor point but actually English has only the polite form. Stiff upper lip, and all that. "Thou" is the singular, but it isn't used much any more.

<http://en.wikipedia.org/wiki/Thou#History>

</comment></comment></comment></comment></comment><comment><USER19> This article could be better - it presents a problem but does not resolve it in any meaningful way. It asks the equivalent of "which is better, left or right?" and concludes with "my opinion is that left is better."

This is not a pragmatic approach to the problem - where is the research? Where is the substantiation of _why_ left is better than right? There is a _rationalisation_ provided, sure, but people rationalise shooting heroin too, so that doesn't go too far. It would be interesting to see a study on this.

</comment><comment><USER20> False choice. I think that the best choice is neither. Unadorned 'Profile' is better than 'My Profile' or 'Your Profile.'

I think there is a decent analog here with unadorned naming being like flat design and my/your being like skeuomorphism.

</comment><comment><USER21> I have to say I disagree with the author's value assertion. It may true that people do treat computer interfaces in a social way, but whether this is useful (for many difference definitions of useful) is clearly open to debate. I wrote a paper about this a few years ago that pins the popularity of the idea of the computer as interactive artifact on Lucy Suchman and her work _Plans and Situated Actions_. The relevant paragraph is here: <http://peermore.com/astool.html#nid21T> (take off the fragment for the whole paper).

If we're actually having some kind of debate about how to signifiy in an interface I'd probably choose "profile" and forego "my" and "your" as they imply a relationship that does not exist and a facility in the interface that is not possible.

Given that most people aren't actually concerned about that and just want their stuff to be "nice" or "friendly" I'd pick one of "your" or "my", whichever fit in the grammar of the rest of the system, and be consistent.

</comment><comment><USER22> I see it as a conversation happening both ways. It just depends on who is the initiator of the conversation.

Consider for example the following two imagined scenarios:

In order to send a new tweet:

1) You click a button that says "Send My Tweet".

2) You click a button that says "Send Your Tweet".

In the first case, you are telling Twitter to send the tweet you just wrote. The power lies with Twitter to send it.

In the second case, Twitter is telling you to send the tweet. In this case, the user has all the power.

.

.

It's interesting to compare Facebook's approach with Twitter's:

Facebook is a bit of an oddball in addressing the user. Facebook usually addresses the user as "you", but it sometimes refers to the user in the third person. On the home screen, it asks "How's are you doing, Sean?" and displays the link to your profile as just your name. On your actual profile page, if you hover over the Activity Log button, it will say "See your activity on Facebook". But then when you go to privacy settings, it says "Who can see my stuff?". This makes a ton of sense. By using "my" instead of "your", Facebook is making the user feel like they have control of their stuff.

Twitter is pretty squarely in the "Me" camp, as evidenced by the link to your profile on the top of the page.

If the website has something informational to tell the user, like a notification, they will always refer to the user as "you".

For example: "Bill just retweeted you", "Bill just liked your status", "Your page is undergoing maintenance".

When you're changing account settings, the website will invariably refer to the user as "you". You are the one who actually needs to perform an action.

For example: "Change your password", "Update your email".

<comment><USER23> I think there's also a difference regarding publicity of the material.

Using "your" is more appropriate for things that already are, or are expected to become, public as a part of the standard workflow (think photo sharing application).

Using "my" works better for things that are private and sensitive, like "My settings" or "My reading list" is often something that should not be shared, or only explicitly shared.

</comment></comment><comment><USER24> In general, I think avoiding either My or Your is better. However, there could be situations in the UI that you may want to separate My Stuff vs Other's Stuff. E.g. a shared folder with a header "My Files" vs "Others". In this case, I think using "My" is stronger. There other other cases like "Your files have been fetched" that sounds more right. I think in general, if you are labeling something, My is ok. If you are communicating a message (e.g. through a notification), Your is better.

</comment><comment><USER25> His conclusion is totally against the "the best interface is no interface" UI/X design idea. He goes:

> Interfaces are much more abstract, and much more intelligent; they far more > closely resemble social interactions than physical tools.

...therefore if I (the user) feel that I have a social-like interaction with the interface, it means that I am _definitely noticing it IS there_ , whereas if I can feel it as an extension of self, I can get more easily to just ignore it once I get used to it and actually feel that there is "no interface". It's easier to ignore the hammer in your hand the person you're talking to, at least for me (and I believe for most social people).

Then again, if you are creating something like the UI for an ecommerce site, you probably want to give the user part of the feeling that he is in a real shop, that implies a real physical interface, so you say "Your shopping cart" - but I'm not sure this is necessarily a good idea.

Imho, OP did a good analysis of the interaction perspective, but somehow managed to arrive at what is 90% of the time the wrong conclusion (but then again, maybe my 90% is his 10%...).

</comment><comment><USER26> in some cases couldn't you design the app not to mention "your" vs "mine" and just say "user profile" or profile?

just a thought. very interesting commentary on the connotations of the usage of "your profile" "my profile' nonetheless.

<comment><USER27> That seems strictly worse than the first two options.

</comment></comment><comment><USER28> The descriptor should either be unqualified "Purchases", not "Your/My Purchase", which is redundant and pandering, or, for any feature which can scale beyond a single user, identify the relevant user (your enterprise customers will thank you): "username => Settings". It's also useful to classify groupings, tags, or other attributes (Engineering, Accounting, HR, etc.) and integrate these with security and other aspects.

I always found "My Computer" to be annoying. It's pedantic (no shit, this is my computer), or wrong (no, this is Mike's computer, I'm just borrowing it), or void of useful context (this is a multi-user computer but I'm accessing it from my or someone else's account).

From a testing perspective, individually naming elements based on their ownership attribute makes for hell in scripting, testing, or writing suitable generic instructions (how do you tell Aunt Tilly how to change her settings when "My Computer" has been sensibly renamed "Aunt Tilly's Computer"?).

Sub-par article fails to consider many other relevant alternatives and considerations.

</comment><comment><USER29> I DON'T agree with this conclusion.

You can easily just test both (with Neither as your control) and survey your users to find out which group is more satisfied with your UI.

When it comes to what customers want or will like, what you "think" is almost always wrong, so stop thinking and start testing.

<comment><USER28> The test shouldn't be what users _say_ they're more satisfied with, but which labeling _results in better task performance_. Now, if self-reported user satisfaction is your designated task, that's fine, but contexts such as multi- user support, shared system access, single-user use of multiple accounts, and centralized maintenance/access of many multi-user systems might also be considered.

</comment></comment><comment><USER30> I feel interacting by voice changes this a bit. Using the Xbox as an example... Microsoft has a 'my pins' option (to select favorites) while the Amazon video app has 'your videos'. Certainly feels odd to say'your videos'out loud.

</comment><comment><USER31> I know this is only tangentially related, but this has always annoyed me in Windows. For example, "My Pictures" does not contain my pictures. My photos are in c:\photos.

And it gets worse with every Windows release. The standard file dialog in Windows 7 is absolutely ridiculous. There is a tree on the left, with absolutely worthless (to me) entries: Desktop, Favorites, Recent Places, My Photos, My Documents, etc., etc. The actual hard drive navigation is at the very bottom, and usually requires scrolling.

A sane navigation tree would just be a list of volumes.

<comment> T-hawk This is because Windows has moved to modern file system organization concepts, keeping data for users within the user accounts and not in the global file space. Why are your photos in c:\photos? Why do you organize your files like it's 1995?

You'll find that that left tree is useful if you flow with the design of Windows rather than fighting against it. Desktop is meant to be an easily visible place for short-term storage of working documents. Recent Places is pretty smart about remembering frequently used local and network locations. My Photos / My Documents are totally useful if you actually put things there like the system is designed to do.

If you insist on drilling down to that hard drive navigation, don't blame the software for yourself deciding to break past the abstraction.

<comment><USER31> Three reasons.

1) They aren't my photos, they are my family's photos. My wife has her own user account and needs just as much access as I do. I'm sure there is some sort of "sharing" solution, but then you lose the convenience of having one location for "My Pictures", so what's the point?

2) C:\photos is a lot easier to type than C:\Users\xxx\Pictures. I much prefer typing to mouse navigation.

3) Windows will actually admit that C:\photos is a directory on a hard drive. If I navigate to "My Pictures", I get some pseudo-directory called Libraries > My Pictures.

Also, are you really so limited that you think there is only One Way to organize files on a hard drive, to the point that you feel the need to mock a stranger for choosing a different location on his hard drive for photos? I expect that snark on anonymous internet forums, but having it embedded in the operating system is another matter.

</comment></comment></comment><comment><USER32> Both usages have a valid context.

In system generated messages "yours" seems more appropriate. It implies that someone else is talking to the user. If I got a message "My email was received", I would feel like talking to myself.

The UI is an extension of human brain. So labeling things with "mine" will make the UI feel natural. My contacts feels closer than your contacts.

I wrote about the same subject: <http://mouly.me/2011/07/my-contacts-or-your- contacts/>

</comment><comment><USER33> Interesting analysis, though personally I sit firmly in the camp that software are tools and as such should not express a "personality" or attempt to provide an "experience". For me, this suggests that straight nouns should be used for this sort of thing i.e "Profile" rather than "(Your|My) Profile".

My power drill doesn't refer to the chuck as "Your/My chuck". My toaster doesn't refer to to the bread as "Your/My bread" and my car doesn't refer to "your/my door is ajar".

</comment><comment><USER34> "your profile" sounds odd. Either "profile" or "my profile". May it should be an action such as "edit profile" or "view profile".

</comment><comment><USER35> I have to disagree. The usage depends on what you are referring to. If it is the user's files, then saying "My Uploads" is preferred over "Your Uploads". Saying "My" shows the users that it is their files, therefore, they have full control over their files and they can do whatever they wish with them.

</comment><comment><USER36> I like the explanation of terms, but come to a different conclusion. Rather than a universal my/yours I would think it ends up being whatever is appropriate to the interface. Some interfaces are for tasks that require "tools" others not.

</comment><comment><USER37> This is really the kind of thing where A/B testing is both necessary and straightforward. Decently intuitive arguments can be made for both sides and there isn't really overwhelming strength on either of them.

<comment><USER38> What, pray tell, is the hypothesis to be tested? Whether "my" or "your" results in more clicks? How do we know they aren't clicks borne of confusion? Whether "my" or "your" users visit the site more often? Over what time frame? A day? A week? A year? A decade?

A/B testing isn't magic fairy dust that settles design questions. You need to have a clear hypothesis to test. It's especially difficult if the design question concerns long-term perceptions and psychology. An A/B test in this situation is anything but straightforward.

I'd be interested to learn about how this design decision was made in the companies that have had to face it.

<comment><USER39> Reduce how often users click back or cancel or close after attempting the action (I.e. to attempt to make them abort the action less often).

</comment></comment></comment><comment><USER40> This could be empirically tested. For me "My Computer", "My Profile" reflects the internal dialog occurring in the users head and (in my perception) has less cognitive overhead than the reflexive "your".

</comment><comment><USER41> If you _really really_ want to connect with the user, go with "Our".

</comment><comment><USER42> I personally think this is a matter of personal preference, but the critical thing is to ensure you always use the same terminology throughout the entire application. Mixing them up is horrendous.

</comment><comment><USER43> Somewhat topical pedantry:

The incorrect non-reflexive use of _myself_ to avoid the potentially incorrect choice of I vs. me. As in:

 _... rather than the interface being an extension of myself._

<comment><USER44> Maybe he just meant "an extension of my self."

</comment></comment><comment><USER45> Is there really any effect or difference between using either?

</comment><comment><USER46> OK, I'm going to pitch in:

The button should be called "My Settings" (or just "Settings") because it's a command I'm shouting at the program. Compare with "Save"/"Open"/"Like". I want to open MY settings. If the settings can't be loaded the program should tell me: "There was an error loading your settings", because the program is talking to me. The documentation could tell me the following: "To open your settings, click the My Settings button". So yes, I favor the conversation pattern. Just pretend you're talking to a human or to a computer with speech recognition.

</comment><comment><USER47> I am pretty sure I saw "Pull to refresh" before it was used in tweetie, but I cant remember where - Anyone have better memory than me?

</comment><comment><USER48> My stuff is what runs locally. Your stuff runs on a server, which also hosts other people's stuff.

</comment><comment><USER49> You know what I do when I inadvertently open a link to a Svbtle network post? I close the tab.

<comment><USER50> I'm curious, why do you feel this way?

<comment><USER49> You know that nauseous feeling you used to get from reading a Daring Fireball post? That.

</comment></comment></comment><comment><USER51> Brilliantly stated!

"My..." implies the interface is an extension of the users brain.

"Your..." implies the interface is a tool to be mastered.

Both might be appropriate for certain use cases. Using github as an example interface with personality, perhaps "My Forks" but "Your SSH Keys"?

</comment><comment><USER52> My stuff

</comment><comment><USER53> Is it really true that no one here has genuinely studied this question before?

Findings from cognitive science and UI research:

People attribute personalities to everything, including software.

Personalized emails, with a person's name, have higher conversion rates.

One of the ways the brain deals with reading is to pretend, on some level, that it's having an imaginary conversation. Concrete description of objects, use of the active instead of passive tense, questions, and keywords like "You," all improve understanding, attention, and memorability.

It's that simple, guys. The research is out there. It's not hard to find. It's not hard to read, either! Just pick up a couple books on writing/cog sci and subscribe to the ACM and do a quick search of their library once in a while.

Or continue to have an argument based solely on what you feel, as if the data is not out there… that works, too.

</comment><comment><USER54> I opt for my stuff because its more immersive. It's the first person narrative. As creator, I want to get out of the way of their experience as much as possible.</comment>