What software engineers can learn from the rapid collapse of Fast • Hacker News Board

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

#161

Post by CoastalCoder » Thu, Apr 07, 2022, 10:18 PM UTC

wnevets wrote: post #150

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.

> Sounds like the engineers were just entertaining themselves with shiny toys rather than solving the problems they actually had. Programmers love to add the latest tech to their resume then move on to a new position within ~18 months

That may be specific to early-mid career focus

If/when a developer builds deep knowledge of a problem domain, things like framework-of-the-month may become an unwelcome distraction.

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

#162

Post by sodality2 » Thu, Apr 07, 2022, 10:18 PM UTC

sydthrowaway wrote: post #128

buf wrote: post #13

Wow, I make the same revenue as Fast as a one-man entrepreneur. It really amazes me sometimes the strategies of these heavily funded companies. Why pile on so much burn so quickly?

What do you do?

Their profile contains a website with some companies that are probably related.

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

#163

Post by [deleted] » Thu, Apr 07, 2022, 10:18 PM UTC

karmasimida wrote: post #87

> the company only generated $600K in revenue in 2021 Ain't none of the investors catch this ... ? Losing money is one thing, but this seems to me as really low growth right?

[deleted]

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

#164

Post by Animats » Thu, Apr 07, 2022, 10:20 PM UTC

jollybean wrote: post #81

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

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.

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.

Uh oh. That has so much scam potential.

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

#165

Post by louthy » Thu, Apr 07, 2022, 10:20 PM UTC

karmasimida wrote: post #39

> the company only generated $600K in revenue in 2021 Ain't none of the investors catch this ... ? Losing money is one thing, but this seems to me as really low growth

This is what surprised me. It seems the board was asleep at the wheel, failing in their fiduciary responsibilities

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

#166

Post by twic » Thu, Apr 07, 2022, 10:20 PM UTC

Informative but depressing looking at the salaries given in the job listings at the end.

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

#167

Post by [deleted] » Thu, Apr 07, 2022, 10:23 PM UTC

sergiotapia wrote: post #135

PragmaticPulp wrote: post #55

Earlier quoted context omitted.

Even startups benefit from job titles and hierarchy. Even startup employees benefit from a visible promotion path. Remember, they had hundreds of employees. Not just a couple people in a small office somewhere. Most likely, the levels corresponded to pay bands and helped determine where people fit into the seniority hierarchy (such as determining who receives sensitive daily information updates)

Levels before you even have product market fit is a joke.

[deleted]

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

#168

Post by bryanrasmussen » Thu, Apr 07, 2022, 10:23 PM UTC

mwcampbell wrote: post #138

zozbot234 wrote: post #132

Earlier quoted context omitted.

Tailscale's "database from 2022" is neither here nor there. What you should do in this situation is use the most boring tech, such as PostgreSQL with a simple HA setup. Thus avoiding the "play with nifty toys" trap and maximizing the chance of making appropriate choices.

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 - 5 hours every day for several weeks, down to 2 hours a day for several weeks after that, and now down to the nearly inescapable 20 - 40 minutes a day I have now.

Yeah, not doing that would be my own form of playing with nifty toys.

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

#169

Post by everybodyknows » Thu, Apr 07, 2022, 10:25 PM UTC

diiaann wrote: post #77

Not having a big company signed is not inherently bad. Going after small business can be a valid strategy (i.e. Salesforce) but it sounds like there wasn't healthy growth or the right relationships to support this path.

Consider this:

> ... engineering directly raising concerns to the CEO, and suggesting to focus on larger customers, fewer customizations, and bring in more revenue. Sales, however, wanted the opposite: close many deals and hit their targets of signups. In the end, sales got their way, ...

If the product is customized for nearly every customer, they've degenerated to a de facto consulting shop.

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

#170

Post by alar44 » Thu, Apr 07, 2022, 10:27 PM UTC

PragmaticPulp wrote: post #55

encoderer wrote: post #17

Earlier quoted context omitted.

Lol. L6. Look no further folks. This guy Dominic was clearly LARPing a startup. Leveling frameworks before traction is a joke to me.

Even startups benefit from job titles and hierarchy. Even startup employees benefit from a visible promotion path. Remember, they had hundreds of employees. Not just a couple people in a small office somewhere. Most likely, the levels corresponded to pay bands and helped determine where people fit into the seniority hierarchy (such as determining who receives sensitive daily information updates)

Yeah that’s all fine and good but 6 levels is ridiculous for a new startup. My company has been around for 30 years, doing $75 million in sales this year, has 300 employees and we now have 4 levels, one more than last year, and even that feels artificial.