Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What software engineers can learn from the rapid collapse of Fast

newsletter.pragmaticengineer.com

Post reply on HN
Print view View original

41–50 of 482 posts

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

#41

Post by PragmaticPulp »

lmeyerov wrote: post #31

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…

> We get job candidates with high competing offers for companies I know to be rotten inside,

I fell for this trick once when I was younger, but never again.

As it turns out, when companies are bleeding talent and struggling to hire they suddenly find ways to pay well above market rate. You can have a fancy title, too!

We had a competitor do something similar at a prior company. I would tell candidates that we can't match their compensation numbers but to come back if things don't work out at the other company. I'd often get a message about 3-4 months later asking if the job was still available

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

#42

Post by jonas21 »

mwcampbell wrote: post #20

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…

It would not have made a difference. Maybe they'd be losing $9.9M a month instead of $10M a month.

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

#43

Post by lupire »

AYBABTME wrote: post #18
adamsmith143 wrote: post #7

That Startups are fundamentally risky and despite all the talk on HN you are highly likely to spend years working in a high pace high stress environment for equity that will ultimately be worthless or at best match comp at FAANGs all while having questionable WLB.

But working at FAANG is not much fun. I think a mix of both startups and Big Tech leads to a happy life.

What's fun about working at startup that is just cloning a bad old Amazon feature? Besides getting to call yourself a "staff+" on Twitter, I mean.

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

#44

Post by photochemsyn »

Wow, these numbers are like those from pets.com:

> "During its first fiscal year (February to September 1999) Pets.com earned $619,000 in revenue, and spent $11.8 million on advertising." (Wikipedia)

> "The company raised $82.5 million in a February 2000 IPO but filed for bankruptcy nine months later." (Investopedia)

Fast rasied $102 million in capital and had $600k in revenue that year... Is Big Finance about to hit the panic button again?

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

#45

Post by EinsDueTresFour »

mwcampbell wrote: post #20

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…

I would add that the "Sales vs engineering and sales winning" would be a very relevant warning also:

> [sales] signed up a large number of smaller businesses on the platform. [...] However, integrating these smaller businesses was challenging thanks to several customizations needed for each new customer.

The ratio of revenue per each small customer vs the total cost of integration (and very likely on-going maintenance) was probably at least an amber flag somewhere for those who had visibility of it.

But maybe there was on-going hope that they would be able to sign up a big customer and integrate them before they ran out of money?

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

#46

Post by uoaei »

xrd wrote: post #19
gregdoesit wrote: post #12

Earlier quoted context omitted.

Author here. I was wrong on this information and updated the article - got a correction since. L6 and above employees would receive this: staff+ engineers, eng leadership, sales etc. There are companies where this information does go out to all employees in the spirit of radical transparency. Skyscanner is an example where every day, every employee gets the full revenue breakdown. These numbers are also shown on moni…

That's really fascinating information. Dashboards are all the rage as a way to get teams aligned around "critical numbers" (the metrics that matter). But, if your dashboards start telling a story of impossibility, your best people are going to leave earlier rather than hang on. A definite downside to the dashboard cult.

It's only a downside if the company's priorities are so completely misaligned vs employees' priorities. But at that point, I would call that misalignment the downside!

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

#47

Post by hinkley »

mwcampbell wrote: post #20

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…

I would hope this problem doesn't exist at startups but I've seen it at entrenched institutions any number of time:

If your boss's boss or peers signed a contract for $1m a year from Oracle, you're going to use Oracle even if Postgres is a better product. And the only way to use Postgres in this situation is if they don't know you're running it. Which puts you in the uncomfortable situation of wanting to say, "But Oracle sucks, look how successful we've been at using Postgres?".

Basically if you don't already know that someone higher up the food chain is comfortable with saying, "I've made a huge mistake", you aren't going to 'help' them learn to do it by pointing out they fucked up. What they're going to hear is that you're asking them to say, "I just wasted a million dollars of company money on something everybody hates," which not only are they not going to do, but they're going to start thinking about how to shoot the messenger.

As many conversations go in a couple of my hobbies and talking to friends and acquaintances about health concerns, the answer often starts with, "first, get a time machine" and ends with, "or learn to live with it," often with some useful compromises in between.

One of the important things to do early in your tenure at a place is to bid various people in the management chain and those who seem to be on a management track to see how open they are to having their minds changed. Because you want to know this when the stakes are low (also the blowback on low stakes things seems to be less problematic). Then you know if or when a boondoggle is in the making whether you can stop it before it starts, or amplify all of the problems and kill it along the way, or whether you should keep your head down and conspire to keep the 'doggle at arm's length with those who agree with you.

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

#48

Post by whateveracct »

jonas21 wrote: post #42
mwcampbell wrote: post #20

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…

It would not have made a difference. Maybe they'd be losing $9.9M a month instead of $10M a month.

Heh maybe if they also didn't hire a bunch of engineers to scale out too, it would've helped..

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

#49

Post by nly »

photochemsyn wrote: post #44

Wow, these numbers are like those from pets.com: > "During its first fiscal year (February to September 1999) Pets.com earned $619,000 in revenue, and spent $11.8 million on advertising." (Wikipedia) > "The company raised $82.5 million in a February 2000 IPO but filed for bankruptcy nine months later." (Investopedia) Fast rasied $102 million in capital and had $600k in revenue that year... Is Big Finance about to hit…

$100M is a lot less money today than it was in 2000 after factoring in inflation and low rates.

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

#50

Post by mwcampbell »

jonas21 wrote: post #42
mwcampbell wrote: post #20

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…

It would not have made a difference. Maybe they'd be losing $9.9M a month instead of $10M a month.

Sure, their primary problem was extravagant hiring, but I think this is still an important warning for developers working in fledgling companies that are appropriately cautious on the hiring side.
Post reply on HN