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

401–410 of 482 posts

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

#401

Post by forgingahead »

throwawaythekey wrote: post #266
pyb wrote: post #218

Earlier quoted context omitted.

Good point, I am always surprise when well funded startups hire former big-tech engineers, rather than experienced startup engineers.

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…

This is hilarious - velocity vs. bug tradeoffs is a key balancing act that every startup does, and you were totally right in what you were doing, also with your point that other companies may choose differently and that's also totally fine.

But to be deemed as a cowboy - utterly hilarious, given where they ended up. Pretty cowboy with the investor money instead I reckon?

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

#402

Post by ejb999 »

Nextgrid wrote: post #385
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…

> Sounds like the whole thing could have run on a single cheap VM, perhaps with a second one for redundancy. You're describing most startups here.

very true

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

#403

Post by Majestic121 »

p0nce wrote: post #400

Why investors take on bad deals like that?

If you have a way to surely differentiate bad deals from good deals, while keeping a low false negative rate (i.e. still being able to notice the next Airbnb/Google/etc...), I'm sure a lot of investors will want to talk to you.

Do you have a good track record on this ?

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

#404

Post by searchableguy »

pyb wrote: post #218
maybetoofast wrote: post #207

Earlier quoted context omitted.

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…

Good point, I am always surprise when well funded startups hire former big-tech engineers, rather than experienced startup engineers.

They pay them better salaries and comp too. Startups boast about poaching talent from big tech by matching compensation and putting those new big tech employees at forefront.

It's a fund raising and public marketing trick.

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

#405

Post by p0nce »

Majestic121 wrote: post #403
p0nce wrote: post #400

Why investors take on bad deals like that?

If you have a way to surely differentiate bad deals from good deals, while keeping a low false negative rate (i.e. still being able to notice the next Airbnb/Google/etc...), I'm sure a lot of investors will want to talk to you. Do you have a good track record on this ?

No absolutely not I'm not an investor. I guess with hindsight it is easier to see how bad it would be. In the microISV space, having expenses below revenue is the only way to go, so it all feels really remote.

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

#406

Post by gameswithgo »

myrandomcomment wrote: post #314
geoduck14 wrote: post #240

Earlier quoted context omitted.

>Early on, the math heavily favors worrying less about infra spend and more about product enhancements that can build revenue. YES! This is VERY true

It is a careful balance. At my last startup we knew we had scale technical debt in our SW. Not something we could fix by tossing HW at the issue. It was all great until we landed that major customer that blew past our supported scale. 6 months of engineering work and a complete stop of feature process. A more careful consideration of the tradeoffs when making them would have saved a huge headache, but no one wanted t…

No post body was provided.

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

#407

Post by gameswithgo »

mwcampbell wrote: post #322
myrandomcomment wrote: post #314

Earlier quoted context omitted.

It is a careful balance. At my last startup we knew we had scale technical debt in our SW. Not something we could fix by tossing HW at the issue. It was all great until we landed that major customer that blew past our supported scale. 6 months of engineering work and a complete stop of feature process. A more careful consideration of the tradeoffs when making them would have saved a huge headache, but no one wanted t…

> Not something we could fix by tossing HW at the issue. I'm curious to learn why, if there's any more you can share. What about vertical scaling, i.e. bigger machines instead of more of them? Can't that go pretty far?

No post body was provided.

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

#408

Post by lbriner »

Isn't this a really common danger for those who want astronomical growth? Most of us would love $100M to spend on stuff but the expectation behind those investments practically begs you to employ far too many of everybody and just assume it will all go good in the end.

I partly understand the over-engineered system because almost by definition, any measure of success will need to support high volumes of transactions but there are plenty of other lessons here, most of them seem quite obvious!

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

#409

Post by nemo44x »

kortilla wrote: post #377
nemo44x wrote: post #120

Earlier quoted context omitted.

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.

Correct. I’d suggest series b. Getting past a is a huge leap but you still have risk and upside.

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

#410

Post by lupire »

cormacrelf wrote: post #373
maybetoofast wrote: post #207

Earlier quoted context omitted.

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…

The reason they give options is that giving out stock basically forces an early IPO due to the 500 employee rule.
Post reply on HN