throwaway82931

Yeah, I way overperformed on this test because it was multiple choice. There were 11 words I didn't know at all, and another 8 where I was uncertain to varying degrees. My score of 99/100 does not reflect my actual ability. Even the one I got wrong was a misclick.

when I have my 2 programmers in office

I'd like to think that you see "my 2 programmers" as "my team" but I've come to expect phrasing like "when we have our 2 programmers in office". That perspective emphasizes that we're all in this together, rather than serfs working for the benefit of the lord.

The "my programmers" phrasing plays into my prejudice that one reason you like having "your programmers" in office is the exhilaration you feel in seeing them at your beck and call.

Indeed, passkeys would seem to represent a step forward from single-device to single-account.

What bothers me about the rest of this thread is not that "grunts" are seen as fallible, but that management is implicitly infallible. Blaming everything on the "grunts" is irresponsible garbage in an industry where leadership, of necessity, often doesn't have a deep understanding of what's going on and the ability to make generally correct decisions with incomplete information is a critical management skill.

You’d think from this thread that the messes inevitably originate from ”grunts” wandering off the reservation. In my experience the source has often been “innovation” imposed from above, in the form of buzzword-driven development championed by semi-technical leadership enamored of this poisonous “grunts can’t be trusted” ideology.

For what it's worth, I'm actually a senior IC who's cleaned up plenty of messes over decades and who enjoys migrating legacy systems. In my experience, it's the management-level architecture astronauts who don't understand loose coupling who do the most harm. The damage done by low level individuals can be contained if they're working on properly isolated subsystems (which of course requires competent management to set up).

And I'm cynical all right. I used to believe that I could be part of a "we're all in this together" team. But I've realized how rare that is after bad experiences at multiple companies where management sees an antagonistic relationship with engineering as inevitable — because they agree with you that "grunts can't be trusted".

they are usually right.

This message encapsulates why so many software jobs are terrible. Put your heart and soul into doing your best, earnestly combat NIH and pursue meaningful productivity, and _still_ the culture is such that at many companies, there will never be trust because the prevailing culture is that management is "usually right" that grunts can't be trusted.

I've worked for good bosses that aren't like this, but they're hard to find.

Github has made multiple decisions which, whatever the rationale, damage trust in them as an identity authority and make it more difficult to believe that a Github account represents who it appears to.

They also allow for accounts to be renamed and then for someone unrelated to register the abandoned name:

https://www.theregister.com/2018/02/10/github_account_name_r...

Web search engines claim fair use for snippets, and MS claims fair use for Copilot. However, a web search engine result page is only an aggregate of the excerpted pages, and it refers back to them; unlike software authored using Copilot, it does not draw those snippets together into a coherent purposeful whole, strip all reference to the original author. and claim complete originality.

That MS went ahead with training Copilot on open source code authored by people who are clearly not OK with it is why they are so short on goodwill.

I've always heard about technical debt at AWS, with thousand line functions everyone is terrified to touch, demotivated employees doing whatever it takes to close tickets without dealing with the root causes, and so on.

I presume that this rash of downtime is just the rickety structure inevitably creaking and breaking. It's probably too late now to fix things — dealing with legacy code requires patience, discipline, and understanding which the management of Amazon doesn't have. They'll just yell at people louder, and hold people "accountable" by punishing anyone where anything breaks.

I'd wager price, convenience (fast shipping, etc.), size, and design matter far more to a buyer.

That's true until having been poisoned suddenly matters more.

But laissez-faire and buyer-beware I guess. Who needs any safety regulations at all, when we can all live in a utopia where every purchase needs to be evaluated by every consumer for every possible way it could cause harm?

Amazon has a long history of selling hazardous, poisonous goods on its website:

https://www.insider.com/amazon-selling-toxic-toys-lead-poiso...

Amazon has been selling thousands of products that have failed federal safety tests, including children's toys containing four to 411 times the safe limit of lead.

I am not aware of similar problems with poisonous products being sold through the physical storefronts of Whole Foods or Amazon Fresh.

However, if in fact Amazon's physical grocery stores are just as bad as its website, then you absolutely should not trust Amazon grocery stores not to sell you pesticide contaminated foods.

Like prosecuting Facebook for colluding in the sale of stolen property?

I am loathe to recommend the use of Facebook for anything, but [...] It's at least better than doing nothing

Is it? A central theme of the article is how Facebook is facilitating bike theft by providing essential electronic storefront space, and that you can't get Facebook to take down such storefronts.

Ideally, this article would hopefully help de-platform this seller off of Facebook, but we aren't holding our breath on that one. Facebook is basically terrible about this, and their existing mechanisms for dealing with reporting sellers like this simply don't work.

[...]

There is no button to click where you can explain to anybody at FB "this is a repeat seller of bikes stolen in Colorado, and here's our proof, and here's our contact info." etc. It is almost as if their system for reporting stolen goods is designed not to work.

So "storefront for stolen goods" is another way Facebook makes our lives worse.

This safety risk applies to anything else you buy on Amazon. Not just pottery, but all dinnerware. Not just dinnerware, but also items like children's toys.

If you can't trust the origins of pottery on Amazon, why can you trust the origins of anything on Amazon?

And if you can't trust the origins of anything, you can't count on safety regulations and standards that you take for granted.

A punitive culture of "accountability" naturally leads to finger pointing and evasion.

This fits with everything I've heard about terrible code quality at Amazon and engineers working ridiculous hours to close tickets any way they can. Amazon as a corporate entity seems to be remarkably distrustful of and hostile to its labor force.

Google is Kafka at scale. All of the other characters in The Trial besides Josef K have been optimized away and replaced with silicon.

The key insight that made it possible? That responding to front-paged Hacker News complaints doesn't have to scale. This allows them to shaft users in the vast majority of cases which never become high profile.

Yes, you're right. I guess I couldn't let go of the idea that an an appeals process should be scalable for paying customers. I still believe that.

That's one option. Another would be that you need to pay for your service on a monthly basis.

Some way that for a user to have faith in the appeals process and purchase peace of mind. Just knowing that a backstop is there would help a great deal.

OpSec is hard. I'm not going to risk that Google won't be able to connect the shadow accounts.

Maybe 1) remove everything else from Google and 2) Start paying for your Gmail account, which will hopefully make it more likely that the appeals process actually works? Gmail's service is clearly something you depend on and that is worth paying for.

It's hard to know what's best in terms of risk management here. The likelihood that you will be hit is small but the consequences are potentially devastating.

The user cannot log into their Google account. https://news.ycombinator.com/item?id=29458794

It's terrifying that the punishments are so draconian (because one false move and you lose access to the entire Google account, and possibly become persona non-grata and lose the ability to create another one even in a company context), it's hard to understand what the rules are, the appeals process generally won't help, and even being a paying customer won't save you.

It seems like best practice for any professional who needs to use Google anything would be to avoid Google to the greatest extent possible except in professional contexts, lest some inadvertent mistake (or something malicious like a hack) cripple your career.

One way to do better is to recognize that the onus is by default put on minorities to explain discrimination. For example, black people in the US spend extraordinary amounts of time explaining racism to white people, an exhausting and neverending effort. It's like a DDOS.

By "open source orgs" I mean entities such as all the non-profits which host/support open source projects.

You're right about it being unhealthy, unfortunately. It might be for the best if it dies and is replaced by something else.

Absolutely. At open source orgs, the internal communication channels are way worse than the public ones. People advocate for positions all the time which would negatively impact their careers if made public.

I'm glad to hear that. It makes perfect sense that reducing the subjective "culture fit" factor reduces hiring bias.

But I would also say that as someone who has experience at the highest levels of open source organizations and who has witnessed the extraordinary extent to which entrenched parties will fight to keep structural discrimination in place: Don't underestimate people's ability to discriminate based on identity alone, without having met in person.