Live data from Hacker News

What software engineers can learn from the rapid collapse of Fast

newsletter.pragmaticengineer.com

481–482 of 482 posts

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

#481
post #247

Earlier quoted context omitted.

I have actually heard of this startup amazingly, as well as the founder, but I wasn't aware it was/is? as much of a s.show that the article portrays at Fast. Do you have any context you might be willing to share, I am genuinely curious.

bizarre tech decisions have led to insane costs with 0 customers. launch is about 2 years behind. having a lot of trouble hiring senior engineers, when they do they don't listen to them. they have a strange platform that every product team must use. tech leadership has never launched a successful startup before. they have over 300 employees, maybe 400 now. 4 levels of management already, and a _lot_ of them. it's ind…

I guess its not _that_ different than that one time I had 4 VPs of Engineering, for 30 engineers Sounds like an absolute bonkers-fest, thank you for sharing.

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

#482

Earlier quoted context omitted.

Perhaps one problem with the current backlash against over-complicated infrastructure is that for some of us, doing everything in one process on one machine using a local embedded database is its own form of playing with nifty toys.

yeah, I guess, I'm not going to get too specific here but I do think it would be nifty if I didn't go through a couple 10 minute periods every day where I have to basically shut everything down run a number of scripts, then restart individual processes that are problematic, to be able to work again. Note that this basically works 99% of the time now and is part of a learning process that had the whole thing taking 2…

Wow. I would find it super annoying to be interrupted twice a day to do a 10min task. Can’t you try to narrow down the underlying bug? Or somehow automate the restart?
Post reply on HN