Live data from Hacker News

What software engineers can learn from the rapid collapse of Fast

newsletter.pragmaticengineer.com

451–460 of 482 posts

Re: What software engineers can learn from the rapid collapse of Fast

#451
post #122

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.

That is nice! What happened with remarkable is I never got it and they refunded me. Which was also nice. Good guys, just a weird policy!

Re: What software engineers can learn from the rapid collapse of Fast

#452

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

This is essentially the long term endgame of any diehard adherent to stack ranking its employees.

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

#453

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

Not sure the specific title, just whatever was after senior. And I suppose it's more like 3 years at this point. Class of 2019.

Re: What software engineers can learn from the rapid collapse of Fast

#454
post #379

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

oof, i described myself as a cowboy at a interview i did last year to a higher up, no wonder i didn't get the job even though i did well on their technical exams. I always took cowboy coder to mean someone who had independence and resilience to get things done even if the environment isn't conducive towards that.

Re: What software engineers can learn from the rapid collapse of Fast

#455
post #270

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

Look at Theranos. That con lasted over 10 years and was valued at billions yet they never managed to actually DO anything.

Re: What software engineers can learn from the rapid collapse of Fast

#456

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

Shipping a VM makes a lot of sense. I wish there were better off-the-shelf tools for packaging up a web application into an easy-to-deploy, self-managing VM, without trying to stuff the typical cloud complexity (e.g. Kubernetes) into a box.

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

#457
I invested in Fast and removed all my position when it looked fishy. But the main problem of all that was all their hype about a « massive customer » they will have at the time. And close partner ship with them. And everybody speculating it was Amazon. Don’t do that. Don’t hype to the moon or it’s going to fall sooner or later to the ground.

Re: What software engineers can learn from the rapid collapse of Fast

#459
post #186

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

In our case, we're running on top of a PaaS (think Heroku). Vertical vs Horizontal scaling is essentially the same complexity for the scale we're currently at.

Re: What software engineers can learn from the rapid collapse of Fast

#460
post #9

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

Oops Affirm is getting burned in the frontpage, what a funny timing. https://news.ycombinator.com/item?id=30959322
Post reply on HN