Live data from Hacker News

What software engineers can learn from the rapid collapse of Fast

newsletter.pragmaticengineer.com

331–340 of 482 posts

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

#331
post #234
post #62

"Most engineers joining didn't know much about why the one-click checkout industry has the potential of billions." So why isn't this a standard feature of every shopping cart program, including the cheap ones? The complicated part is that you need "undo", valid for a while after ordering. That's what makes one-click buy feel safe for customers. This complicates inventory management. But you really need "undo" for an…

As a shopper, one click buttons make me so nervous whenever I see them on the page. It definitely distracts me from my shopping experience, with a region of the screen screaming "don't touch me!!!".

That was Amazon's innovation. One click buy, easy undo. Previous systems usually used the "we have your money now, muahahahahaha!" approach, with difficult order cancellation. Too many still do. It's obvious in retrospect, but not obvious until seen.

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

#332
post #328
post #312

Earlier quoted context omitted.

this doesn't answer the question at all, it's just a bunch of bullshit words strung together. we never raised any money, and we had more to show than Fast although we were in a completely different industry. this goes to show that all that matters is knowing people, it doesn't actually matter whether you have a real business and have achieved anything at all.

VCs sometimes follow "hot" companies. Companies become hot when several VCs think they are hot for whatever reason. When the company is hot and gets offers, other VCs will rush to give them more offers and at that point you might not even need a deck or any metrics anymore. The startup can then bid those offers against each and can end up raising even more they initially were trying to. Fast did great job hyping the…

traction doesn’t matter. or we would have raised. story and team maybe. i think that VCs buy into a certain type of person. maybe a younger version of themselves. somebody they want or wanted to be. that rules out anyone who is nerdy or weird. and they like to go to parties to hear what others are investing in and then do the same.

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

#333
post #195

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…

> Our new hires are getting paid from customer revenue Money is fungible

Customer revenue is recurring

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

#334
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…

i worked for a startup with a promising product in a lucrative niche but rather than invest in their unique value propositions and use that as a sales ratchet they instead pursued a sales strategy of "outsourced IT" at below cost. engineering time was devoured by integration issues and custom work for customers that were paying far less than the cost of the custom work

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

#335
post #318

Sorry, I read it all the time, but still - how the fuck is it suddenly normal for a fairly standard salary amongst any non exec layer in a company to be ~$250k? I know engineers and developers have to be skilled, but this is insane. No-one needs that kind of money. People in Nepal live for $10 a week. What an insanity.

> No-one needs that kind of money.

I'm currently renovating an old house, I certainly need it :-)

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

#336
post #95
post #80

Earlier quoted context omitted.

> Sounds like the engineers were just entertaining themselves with shiny toys rather than solving the problems they actually had. This is often the problem when hiring too fast. New employees don't have context or direction but generally people try to be productive, so they start inventing work. Management team is new too, and not built up either direct or handle the bandwidth and they also are lacking the direction.…

It's not just limited to startups. When my business unit in Amazon spun up we hired way too fast and ended up having a harder time shipping v1 of the product than if we would've started lean and grown organically. We ended up spending a lot of time on a modularized platform to enable ~5 matrixed feature teams to contribute across iOS and Android apps. Looking back, a small dedicated team for iOS and another team for…

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 encouraged organizational sociopathy.

With 50% turnover per year (IT stats, not warehouse worker stats), it'll be hard to sustain development as well.

So it makes sense that Amazon would overhire.

Get out as soon as you can.

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

#337
post #318

Sorry, I read it all the time, but still - how the fuck is it suddenly normal for a fairly standard salary amongst any non exec layer in a company to be ~$250k? I know engineers and developers have to be skilled, but this is insane. No-one needs that kind of money. People in Nepal live for $10 a week. What an insanity.

You're looking at the wrong level of the problem. Engineers in Big Tech can make $250k because they're making even more money than that for their bosses - if they were paid less, it would just mean that the bosses and stockholders got paid more.

Same for startups, except there it's a VC betting that he'll make $50M if he gives 10 companies $2.5M so that they can each pay 10 engineers $250k.

We don't live in a system where what you "deserve" has anything to do with what you get; the factors are how much cash you're expected to bring in and how much leverage you have when splitting up that cash between you and the company.

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

#338
post #318

Sorry, I read it all the time, but still - how the fuck is it suddenly normal for a fairly standard salary amongst any non exec layer in a company to be ~$250k? I know engineers and developers have to be skilled, but this is insane. No-one needs that kind of money. People in Nepal live for $10 a week. What an insanity.

What point are you suggesting with your Nepal example? It's a third world country. Fast presumably employed people in San Francisco. That weekly wage from Nepal might buy you a bag of apples from Costco here. An entire year's worth of wages in Nepal might pay for one month's rent of basic housing. Sure, nobody needs $250k per year to survive. CEOs also don't need to have an obscene compensation ratio compared to thei…

> We have a few other systemic issues I’d like to see solved first

Insane levels of inequality is what’s on my list

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

#339
post #318

Sorry, I read it all the time, but still - how the fuck is it suddenly normal for a fairly standard salary amongst any non exec layer in a company to be ~$250k? I know engineers and developers have to be skilled, but this is insane. No-one needs that kind of money. People in Nepal live for $10 a week. What an insanity.

You're looking at the wrong level of the problem. Engineers in Big Tech can make $250k because they're making even more money than that for their bosses - if they were paid less, it would just mean that the bosses and stockholders got paid more. Same for startups, except there it's a VC betting that he'll make $50M if he gives 10 companies $2.5M so that they can each pay 10 engineers $250k. We don't live in a system…

Sure. I’m just expressing discomfort at how it became just “meh, it’s how it is”.

My issue is I just don’t see the world in this money focused way. From out here, in the land where it’s sort of average to earn maybe $50k and feel pretty good about that, it looks pretty sick. I don’t get it, I don’t like it, it feels disingenuous to support it with what seems to be an endless “it’s ok, everyone does it” or “that’s just how the system is” argument.

Maybe if those guys gave away 50% of their salaries to support good causes, I’d feel better about it. But I’m betting my ass they don’t.

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

#340
post #318

Sorry, I read it all the time, but still - how the fuck is it suddenly normal for a fairly standard salary amongst any non exec layer in a company to be ~$250k? I know engineers and developers have to be skilled, but this is insane. No-one needs that kind of money. People in Nepal live for $10 a week. What an insanity.

I mean, would you rather my company have the money? As a software engineer you have the ability to take a lot of money from a lot of soulless bureaucracies and do whatever you want with it. You could do a bunch of good with it if you want. We're on the labor side of this equation, we should be asking for as much as we can get.
Post reply on HN