Live data from Hacker News

What software engineers can learn from the rapid collapse of Fast

newsletter.pragmaticengineer.com

471–480 of 482 posts

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

#471

Earlier quoted context omitted.

> I am always surprise when well funded startups hire former big-tech engineers, rather than experienced startup engineers i'd say that if you plan on scaling, you need a bit of both. a lot of tricky scale/process/architecture questions have effectively been "solved" in big orgs, it's useful to have people who can bring this experience to take a completely random examples: setting up a performance improvement plan, p…

That’s the problem. They had 0 need of scaling. It’s premature optimization 101.

nail it, then scale it

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

#472
post #293

Earlier quoted context omitted.

I don’t get this sentiment: https://twitter.com/dcarter_js/status/1509916298574442498 “I could not be happier or more proud of my teams and what they have accomplished.” If the company wasn’t successful, then that’s partially on engineering. As employees, we win as a team and lose as a team. It seems like they were way overbuilt and should have gone much slower from a hiring perspective. Perhaps these are just words…

Maybe what you're not getting was that it was posted on April Fools day?

no

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

#473

Oof, just one of our customers pays about the same as their full revenue, and we're a cockroach team. The real thing here is they're not that surprising. A lot of companies with their kind of funding use enterprise sales to force say $5-10M ARR, but there's only so much VC money can force for a leaky funnel, broken product, and overall incorrect market + fit. I didn't appreciate this until maybe a year or two ago. Va…

i feel like even the possibility of a company like docker failing would be among the greatest failures in the history of software

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

#474
post #210

The article has good points but misses the actual answer in my view to "what software engineers can learn" or in fact anyone can learn from this. Don't join a company only because there is more money. If you don't know what one click checkout is or have any intellectual interest in it, but jump on it just because you can make more, you will be disappointed. This works the same way in everything in life. One must have…

I have very little interest in tax software, but my current and previous jobs are writing tax software (though I guess my previous job was technically tax software plus other internal tools for a local government). But for me the interest isn't in what the software I'm writing is for, it's in the interesting and unique problems I get to solve, even for something as boring as tax software.

there are literally no interesting and unique problems in tax software. literal oxymoron

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

#475

Earlier quoted context omitted.

That’s the problem. They had 0 need of scaling. It’s premature optimization 101.

nail it, then scale it

Exactly, scaling doesn't help you solve product-market fit. It adds operational complexity/overhead with, in this specific case, no benefits, and solidifies the product that doesn't have market fit. Watch this for a laugh: https://youtu.be/y8OnoxKotPQ

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

#476
“North Bondi” is code in Australia for an extremely, extremely wealthy set of suburbs when they don’t wish to be directly identified (such as Vaucluse, Dover Heights, Rose Bay).

This is undisputedly the wealthiest part of Australia.

How did the founder raise $100M with no revenue? “Charisma”? No, this is high-net worth connections and is an overlooked aspect of this whole saga.

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

#478

Earlier quoted context omitted.

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.

So, over $500k per year? Not a bad deal for class of 2019

Yep, not bad. But talking in salaries hides the most important number: how many hours are you expected to work for that?

IME, F are the only ones to whip out their laptop at a house party or bar at 10PM on a Friday night because they felt an insatiable to work on some feature request; GMA may do the same when on-call, but I've never seen it otherwise.

I'm personally going the other route: Class of 2019, secured a decently sized FAANG bag (barely worked the whole time while doing it), and now I'm transitioning to a position with even fewer hours of commitment required but also lower salary. Going to focus on things I've come to find more important than money and code.

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

#479
post #463
post #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.

You invested? As a VC? Something doesn't add up in your comment because Amazon literally invented one-click checkout. Why would they have Fast on?

No my bad I miss read I thought it was about Fastly (FSLY).

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

#480
post #427

Earlier quoted context omitted.

Beanie babies aren’t scarce and can only be produced by a single company.

neither is right clicking on a jpeg and saving it

Neither is photographing the Mona Lisa.
Post reply on HN