Earlier quoted context omitted.
Lots of sites do not have a good undo for orders. I ordered from remarkable and their solution was to deny the package...
I ordered a piece of furniture from Wayfair, and they had the same response - deny the package. Well the package arrived while I was at work. After calling them 3 times to come pick it up, due to shipping delays they were never able to, and eventually told me to keep it for free.
What software engineers can learn from the rapid collapse of Fast
451–460 of 482 posts
Re: What software engineers can learn from the rapid collapse of Fast
#452Earlier quoted context omitted.
If you have a small team, and well hired, then the stack rank grim reaper kills off 20-30% of your labor each year. For your huge hires, 1/3 of the people were hired to be fired in the stack ranking, which of course is a huge morale hit. The ones that aren't setup to fail lose 20-50% of productivity doing machiavellian backstabbing, defensively or offensively, for promotions other culturally ingrained/highly encourag…
Where the hell were you working? This isn't normal for any company.
Heavy stack ranking basically means for a life event, a worker is very likely to get axed. Any health event, having a child, partner has hard times, or management reorg that puts you with a boss that doesn't like you, and the writing is on the wall.
Companies with a good long term focus should concentrate on acquiring and developing long term workers.
Amazon in particular structures its pay (payoffs come from bonuses and vesting 3-4 years in) in such a way that if one takes a perverse sociopathic view of how they manage workers, that management is incented to rug-pull workers three-four years in so the vesting doesn't happen.
Amazon is DEFINITELY sociopathically and perversely managed to do this.
Once that fundamental disdain of your work force becomes ingrained, then all other organizational abuses (stack ranking, hire for fire, backstabbing) is all fair game.
It starts with stack ranking and the fundamental management sociopathy. Which anyone that looks into accounts of Jeff Bezos becomes apparent of the source.
So why has Amazon been successful? Amazon's advantage in the overall corporate competition landscape was simply that they built an integrated business+IT strategy while every other company treated IT as a cost and annoyance.
But they treat their people like utter shit, and as Amazon transitions from an explosive growth company to a more sustained presence, and from AWS from explosive growth to "utility", the now-huge middle management and workforce devolves from stack ranking and sociopathic disdain into a cesspool where only the wicked survive.
https://en.wikipedia.org/wiki/Toxic_workplace
Unfortunately, Amazon continues to ride a growth momentum, so the toxic workplace will be viewed as a positive. Nothing will change until serious incidents occur.
Of course Amazon is huge, so there are workers who may be in less troubled areas. Just keep in mind that toxic areas of companies that derive from corporate practices will inevitably spill over to the "good" parts. Amazon is acquiring massive amounts of pure sociopaths in their management culture, and those sociopaths will "eat" other idealistic parts of the corporate management.
Corporate america is adapting. Better integration of IT and management is going to come to Amazon's competitors. Amazon's apathy to its product fraud and fake reviews, now stretching into a three year ongoing problem shows that it is faltering. Its lies during its AWS downtimes show a blame culture in action.
Re: What software engineers can learn from the rapid collapse of Fast
#453Earlier quoted context omitted.
May help explain some Meta offers I've seen... 2 years out of college? Sure, come as a Senior! That's not enough? Principal it is!
> Meta > Sure, come as a Senior! That's not enough? Principal it is! Do you mean staff (E6, the level above Senior)? Also, no one is getting E6 offers 2 years out of college.
Re: What software engineers can learn from the rapid collapse of Fast
#454Earlier quoted context omitted.
What exactly is meant by "cowboy" here?
Someone who plays it "fast and loose" in terms of engineering (for example, deploying straight to prod). As parent mentions- this isn't necessarily a bad thing depending on the context (but "cowboy" here has a negative connotation).
Re: What software engineers can learn from the rapid collapse of Fast
#455Earlier quoted context omitted.
This echos my experience at a $100M startup that I worked for and that ultimately failed. HR would tell us we were extraordinary, we would have world-class catering for lunch every day, and yet we had no customers, no contracts, and no money except the investors'. It was a sobering realisation on the damage that can happen when you are submerged in toxic positivity. You forget that companies still need to earn actual…
How on Earth did the company raise so much money with so few milestones of any kind being achieved?
Re: What software engineers can learn from the rapid collapse of Fast
#456Earlier quoted context omitted.
> Not something we could fix by tossing HW at the issue. I'm curious to learn why, if there's any more you can share. What about vertical scaling, i.e. bigger machines instead of more of them? Can't that go pretty far?
Shipping unit was a VM to a customer. Tossing more CPU & RAM at the VM would hit general issues of how VMware allocates CPU to a guest. Within the VM we had containers for each sub-unit of the tool. For some part of the system we made the deployment model more than one VM, distributing more containers to the other VMs. However for a key part of the design there was an in-memory DB and we just it the scale limits of t…
I don't understand the issues with using a bigger VM, but I have no reason to doubt you.
Re: What software engineers can learn from the rapid collapse of Fast
#457Re: What software engineers can learn from the rapid collapse of Fast
#458Re: What software engineers can learn from the rapid collapse of Fast
#459Earlier quoted context omitted.
I've done startup engineering for a while. I've seen exactly 1 issue that we couldn't solve easily (N+1) or with simply turning our server count up (often way cheaper than putting an engineer to a problem). Basically, to move development velocity faster we "load everything". Seems like a really bad idea on the surface. In practice, we only ran into an issue with a single customer that was literally 1000x as large as…
Even before using more servers, one should consider using (one) bigger server (and another as backup). Massive servers are laughably cheap these days. E.g. 16 cores, 128GB RAM is €112 from Hetzner.
Re: What software engineers can learn from the rapid collapse of Fast
#460Earlier quoted context omitted.
New klarna virtual cards for not needing ecommerce implementing financing directly is genius. I guess with nowadays infra as code for financing that makes sense in 2022
Affirm is doing the same [1]. Debit rails are just easier versus the integration schlep. If you're a fintech, you can do all sorts of cool presentation and product offerings using a virtual account attached to a deposit account (BNPL is one, as is a hybrid credit/deposit account). Debit/virtual card also empowers the consumer, as you're not beholden to the merchant or their gateway provider to support a specific fint…