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