Live data from Hacker News

What software engineers can learn from the rapid collapse of Fast

newsletter.pragmaticengineer.com

371–380 of 482 posts

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

#371
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 need that kind of money, when a decent family home near the offices costs $4 million

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

#372
post #338

Earlier quoted context omitted.

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

Do you know what the average salary is in the Bay Area? You’re completely out of touch if you think $250k is “insane inequality”. Take a look through the salaries paid for working at public transit there (BART): https://www.bart.gov/sites/default/files/docs/Salary%20Sched...

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

#373
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 joined Fast towards the end of last year. I didn't get as much exposure to the rest of the company as parent comment, but I'll say I saw a weird air of complacency and assumed success. I first ignored my instincts that something was wrong, but as I saw more of how the company operated, I became convinced that the single largest problem the company had was the culture. On the surface, I agree with the parent comment…

This whole thing is strange to me. It's targeted at software engineers, and the dominant theme is that you should be wary of toxic positivity and a number of specific indicators that you should be able to see from your desk as an engineer. The discussion in here is also focused on that.

But if you are an early employee with equity, you are not just an engineer. You are, figuratively, a shareholder. One of the reasons they give you stock options as opposed to actual shares is that shareholders have a ton of rights against companies, and can e.g. sue for investor fraud, vote the board out, get quarterly reports with financial & performance statements therein backed by federal law and the threat of investor fraud lawsuits. You, on the other hand, are given the financial exposure to the company's performance without any of the attached rights. And they will happily lie to you in order to keep you happy & get you to project enough positivity to hide flaws & keep outside investment flowing until it all collapses.

So as an employee, you should be trying to claw back some of what being a shareholder would get you, given you are so heavily exposed. I've worked at companies where there is a monthly meeting, nearly everyone present, where the entire company's business position, prospects and challenges are discussed openly. The employees (largely) didn't even have equity. Any cracks (like an imminent complete collapse in the next three days) would show very early on, but there were none, because the employees were empowered to do something about any challenges.

So, yes, there are warning signs, and your response isn't a binary choice between staying and leaving. I would like people to come away with a better model of this than "if they are hiring exclusively from big tech, that's a red flag, get out of there". You can demand more transparency if you know what transparency looks like. If you are content to sit at your desk and happily churn out React components, satisfied with management sending enough emojis at you via slack, then you can't protect yourself at all.

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

#374
post #339

Earlier quoted context omitted.

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

Get a better job, you’re underpaid if you have the skill set to work in tech. Don’t take it out on everyone else because you’re selling your skills at below market value.

> Maybe if those guys gave away 50% of their salaries to support good causes, I’d feel better about it

Do you give away 50% of your salary? How would you feel about someone who only clears $30k claiming you don’t need that money and that you should give away 50%?

Introspect why you have tall poppy syndrome, it’s toxic and will hold you back.

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

#375
Sounds like a great deal while it lasted for the engineers working there. They were over paid by a company that was bending over backwards to please them with money, benefits, and pretty much everything they could want. The stock turned out to be worthless of course, which is a bit of a bummer. But that's why salaries were presumably that high.

So, the money ran out and people got fired. So what? If they were any good, they no doubt found other companies to get a good deal with pretty soon after. I see no problem here. There's a shortage of competent engineers. That's the reason companies like this pay so well.

The only issue I see is dumb investors putting money in a company that clearly had no product market fit, a big spending problem, and nowhere near the ARR you would normally associate with a 100M+ C round. I mean, we're a struggling bootstrapped startup and we are getting close to that revenue this year. The investors we talk about (for a seed round) seem to be a lot more picky than was apparently the case for this company. You'd hope investors would do some due diligence. That clearly did not happen, at all. What the hell were they thinking?

Probably a juicy story there of incompetence, greed, stupidity, and various individuals benefiting when they arguably shouldn't have. I imagine the e.g. CEO of this company funneled away plenty for himself before bailing out in a hurry. If he paid his engineers a quarter million per year, I bet his own salary was probably a bit higher.

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

#376

con man as CEO is usually a good indicator

So Elon Musk then? Any day now a car will fully self drive across the country, as was promised to happen 4+ years ago.

Not quite, both spacex and Tesla generate significant revenue. Not lies about the business.

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

#377

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.

Over a career though you'll be at quite a few of them. Figure 7-10 or more in some cases. Some will be quick fails (within a year you know it's just not going to work and you move on) and others will be OK success (maybe you have an OK exit with equity but not life changing) over 4 years of service and maybe 1 or possibly 2 will be really nice. And if you're really lucky one will be beyond amazing.

Those numbers don’t line up with the actual failure rates though unless you’re joining relatively mature startups.

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

#378

> I found some unsettling information about the founder of Fast, Dominic Holland. This thread [1] touches on what some of that stuff probably was. Sounds like the CEO was a charismatic scammer. [1]: https://nitter.net/jack_raines/status/1511737489190494208

I'm shocked to learn that people with money funded another charlatan to the tune of $120M /s

Maybe some Big Tech guys wanted to fire some non-performing engineers, and funding Fast which would lure them then go bankrupt was the cheapest way.

(Just kidding).

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

#379

Earlier quoted context omitted.

I interviewed at Fast last year as an experienced startup engineer. I was given the "describe a production incident you were involved in" question. I detailed a case where a recent deploy I had done had resulted in elevated error rates for some of our clients and how I had solved it with a quick follow up push to prod. The interviewer asked why it wasn't caught in staging and I mentioned that it could have been but a…

What exactly is meant by "cowboy" here?

Someone who plays it "fast and loose" in terms of engineering (for example, deploying straight to prod). As parent mentions- this isn't necessarily a bad thing depending on the context (but "cowboy" here has a negative connotation).

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

#380

Earlier quoted context omitted.

I interviewed at Fast last year as an experienced startup engineer. I was given the "describe a production incident you were involved in" question. I detailed a case where a recent deploy I had done had resulted in elevated error rates for some of our clients and how I had solved it with a quick follow up push to prod. The interviewer asked why it wasn't caught in staging and I mentioned that it could have been but a…

What exactly is meant by "cowboy" here?

Not OP but in tech cowboy often means "taking unacceptable risks to increase velocity". In this case, shipping code without integration tests in Staging. whether that risk was 'unacceptable' is the difference of opinion at issue.

Fun fact: The 2011 article Cowboys and Pit Crews (https://www.newyorker.com/news/news-desk/cowboys-and-pit-cre...) points out that modern cowboys actually spend a lot of time on communication and checklists.

Post reply on HN