Live data from Hacker News

What software engineers can learn from the rapid collapse of Fast

newsletter.pragmaticengineer.com

221–230 of 482 posts

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

#221
I'm glad that a warning was given about graphs of "potential [equity] compensation value."

I've seen this abused where co-founders were only paid in equity. Instead of being told their percentage ownership, they were shown a similar extremely hypothetical graph. Unfortunately, in reality their equity only was worth ~$600/year (when computed using their percentage ownership and current valuation, which takes into consideration future risk).

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

#223

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!

The problem is sometimes this is done for legitimate reasons and genuinely does lead to stronger outcomes for both employers and employees. It's hard to tell the difference between "stop the bleeding" title/pay inflation and "aggressively competing for talent" inflation.

> this is done for legitimate reasons

What could be a legitimate reason for giving silly titles? If it were a startup, it would be a huge red flag for an auditor.

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

#224
post #133

I think the most applicable warning for engineers when it comes to the actual work, as opposed to whether one should join a particular startup, is this: > Engineers calculated the load Fast had in needing to serve their traffic. The Fast button was rendered less than 500,000 times per day - rarely needed to ever serve more than a few requests per second. > One of the few warning signs engineers noticed is how Fast sp…

this sounds like Ridgeline, a startup most have never heard of, founded by the founder of Workday and some of its early employees.

I have actually heard of this startup amazingly, as well as the founder, but I wasn't aware it was/is? as much of a s.show that the article portrays at Fast. Do you have any context you might be willing to share, I am genuinely curious.

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

#225

Earlier quoted context omitted.

> Sounds like the engineers were just entertaining themselves with shiny toys rather than solving the problems they actually had. Programmers love to add the latest tech to their resume then move on to a new position within ~18 months

That may be specific to early-mid career focus If/when a developer builds deep knowledge of a problem domain, things like framework-of-the-month may become an unwelcome distraction.

Seeing someone using nothing but tried and true tech to solve new problems is a resume green flag.

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

#227
post #209

Earlier quoted context omitted.

> The company spent a lot of money on marketing events including sponsorship deals with the Tampa Bay Lightning and the rumored million dollar concert by the Chain Smokers here we go, this is late 90s all over again

This is such a revealing comment and here's why: The reason late 90's start-ups invested the way they did is because they had no meaningful way to track the effectiveness of their ads, much less the payback. A Super Bowl ad for Pets.com seems fine if you can (more or less) guess that it adds a bunch of customers. Since then, start-ups have built a bunch of tools to track customer acquisition costs and paybacks in a p…

Very good point and you are not alone seeing the deja vu

Remember beanie babies? We call them NFTs today.

Remember HYIP and e-gold? We call them cryptocurrencies now.

The point is that crowd behavior, especially markets driven by envy & greed, lead to the same outcome. every. single. time.

this is why guys like Warren Buffett and Charlie Munger keep making money.

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

#228
post #196

I was an engineer at Fast for over a year and wanted to clarify a few points-- - engineers did have access to data and could write their own queries to check revenue (but few people did until the article came out). - the strategy leadership decided on was to go after massive enterprise sellers which would, in theory, result in step-change functions in revenue. Many people knew about the low numbers but were willing t…

Going after large enterprise sales is a well known trap, and it's just so easy for a startup to spin its wheels for months, and eventually years, and realize that all the efforts got nowhere. The first 1B+ seller is precisely the hardest: Even when you are a relatively well known company, you'll still see reticence in bids if they know you are going to be their biggest costumer by volume. The companies I know that su…

But didn't Bolt succeed (order of magnitudes more revenue) by taking those enterprise customers while Fast was only getting SMBs?

I'm currently at a seed-stage startup with a few Fortune 500 companies as users. We're lucky to have a great sales team that can bring that business in. If we're solving a problem for them, they're willing to use us regardless of our size, though they do care about some small particular issues around size.

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

#229
Am I crazy, or is the answer "Nothing"? The product was built, they just couldn't sell it fast enough. Engineering culture had nothing to do with this failure.

And if they had landed one of those big clients, they would be kicking ass. You never know how it is going to go. Sometimes you go after the small sales and die. Sometimes you go after the big ones and live.

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

#230
Reads exactly like the stories I remember from the dot-com bust of 2000.

Back then, it created a chain reaction. Even relatively established companies like Yahoo turned out to be dependent on startups for much of their revenue. As public companies they had to announce large misses from revenue targets. And that scared investors, which chilled the capital flows to startups, which led to even more startup deaths.

Personally I wouldn't invest in recent software IPOs that sell to startups. Nasty revenue surprises may be on the way.

Post reply on HN