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

291–300 of 482 posts

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

#291

Post by irjustin »

SkyPuncher wrote: post #143
lolsoftware wrote: post #33

Earlier quoted context omitted.

The TailScale folks caught a bunch of flak for their "do things that don't scale" approach to databases. But, honestly, most startups would be better off following that approach than what Fast did. Sounds like the engineers were just entertaining themselves with shiny toys rather than solving the problems they actually had.

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…

Exactly, the cost of turning on additional servers is measured in ~US$100's/mth vs an engineer's time ~US$10k-25k/mth.

If you can make the problem go away by spending more in servers always do it.

For startups, the life and death is product market fit and you only get there by iterating on the business as many times as possible, not making something more efficient.

Put engineers on business iterations.

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

#292

Post by ec109685 »

emgeee wrote: 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…

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 that folks say to put best light on things as they leave, but it strikes me as disingenuous and lacks that ownership mentality that engineering leadership should display.

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

#293

Post by smabie »

ec109685 wrote: post #292
emgeee wrote: 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…

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?

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

#294

Post by im_down_w_otp »

belval wrote: post #276
im_down_w_otp wrote: post #272

Earlier quoted context omitted.

How on Earth did the company raise so much money with so few milestones of any kind being achieved?

A well known name was attached and it was at the peak of the AI craze.

Ah, celebrity investing. Of course, of course.

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

#295

Post by subroutine »

encoderer wrote: post #185
bps4484 wrote: post #183

Earlier quoted context omitted.

they were a company of nearly 500 people. they had 150 engineers. At that stage people who don't have levels will feel like they have no direction.

This is just such a big company mentality. Yes, you need like Engineer and Senior Engineer and then when you have some rock stars who actually move the business forward they are your principles and/or future directors. To try to build this all up ahead of time, show me where it's ever worked? When Google was that size they were playing with having no managers at all .

If you're only interested in sniping FAANG talent, arbitrary levels provide a familiar comfort, and an opportunity to offer a level up immediately upon joining. "You're level L4 at Google, but we'll bring you in at L14".

>> * Fast hired engineers, engineering managers, product managers, and executives directly from Big Tech. Many of the software engineers joined from Meta, Google, Uber, Amazon, Apple, Microsoft, and other well-known companies. Many joining had competing offers both from Big Tech and other high-growth startups.

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

#296

Post by paradite »

Having spent the past 3 years building online checkout and mobile payment solutions at a top fintech company, it hurts to read articles like this where some of red flags are so "obvious".

During my time there, I would regularly check our monitoring dashboards and analytics tools to understand how business is doing. We also had frequent all-hands during which business metrics are communicated transparently. Through digesting and understanding the data from various sources, I was able to have a good sense of how well the business is doing, and that helped me grow in the confidence of the company.

Online checkout, as simple as it looks, has tons of complexities, nuances and interplay of various factors hidden behind it. But that's another long long story.

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

#298

Post by pedrosorio »

meetups323 wrote: post #78
PragmaticPulp wrote: post #41

Earlier quoted context omitted.

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

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

#299

Post by jollybean »

bombcar wrote: post #275
jollybean wrote: post #81

Earlier quoted context omitted.

That's the magic question. 1) Carts are slow to evolve but they will. 2) Bolt/Fast contain user based information, consumed from their use on other sites. So there's a 'network effect'. If they've shopped at ABC.com before your store, then you already have their CC data ready to go in their car. Sort of like Single Sign On but for carts.

PayPal and (Amazon) have way more customers and their data ready to go. I don’t think one click buy is that useful for smaller sites (something like Apple Pay is much more valuable as the customer doesn’t have to think about a bunch of details).

PayPal represents a specific kind of payment, moreover, they are a payment processor and that's not what Bolt is as far as I know.

It does help smaller sites.

'One Click Buy And Ship' makes a very material difference, particularly on mobile.

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

#300

Post by presentation »

nomel wrote: post #223
naiwenwt wrote: post #145

Earlier quoted context omitted.

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.

A title is free to give and can motivate people who want them.
Post reply on HN