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

281–290 of 482 posts

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

#281

Post by DevKoala »

danielmarkbruce wrote: post #277
DevKoala wrote: post #269

Earlier quoted context omitted.

This is not true at all. A lot of people In BigTech companies boast of passing a tough interview as their biggest accomplishment and beyond that haven’t really done much. Meanwhile, good startup engineers are used to learning new technologies quick, can work across the full stack, can own all aspects of their app/feature, work without much direction, never mind a formal spec, and generally are used to solve problems…

You've compared the worst big tech engineers with the best startup engineers. Those are rarely the choices faced.

Your comparison was similarly unfair at the other end while presenting it as a common scenario, which is why I presented a different one.

This is from my experience as a hiring manager who has worked at multiple startups and now works for a large public tech company.

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

#283

Post by ec109685 »

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

What I couldn’t understand was that there were times where something like ApplePay was a clearly superior way to pay. E.g. JavaScript says the user has it configured and able to make payments, so one click payments were actually possible.

At least publicly, Fast never addressed this, and insisted on requiring the user to log into Fast to make a payment even when it was a worse option.

Browsers like Safari are explicitly designed to prevent people from remaining logged into third party sites like Fast. All this was just brushed under the rug and instead it was just a bunch bluster on how Fast was a revolution.

At least Bolt allows payment via ApplePay, and seems more about doing whatever it takes to maximize each seller’s conversion, rather than having an ulterior motive to push its own brand everywhere.

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

#284

Post by ec109685 »

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…

They had 20 user designers / researchers. Just massively over done for a company that was just getting traction: https://twitter.com/marianoaavila/status/1511410574327881728

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

#286

Post by asmithmd1 »

robocat wrote: post #194
StillBored wrote: post #119

Earlier quoted context omitted.

Early in my career when in a discussion with my manager at the time, he threw out the "planes with two engines have twice as many failures as single engine planes" line. So in my now close to 30 years of experience later, working on systems expected to run 24/7/365, I can't tell you what percentage of failures and outages were caused by the redundancy/fail-over/etc software and hardware layered into a system, but its…

> "planes with two engines have twice as many failures as single engine planes" There has to be a smart reply to that, like: 100% of pilots of single engine planes don’t make it home after a single engine failure. 100% of pilots of dual engine planes do make it home after a single engine failure.

If you lose an engine on a twin engine plane, you have to decide if you have an emergency or not. If you lose an engine on a single engine plane, you have to decide where you can make an emergency landing.

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

#288

Post by marketerinland »

danielmarkbruce wrote: post #261
lowkey_ wrote: post #228

Earlier quoted context omitted.

But didn't Bolt succeed (order of magnitudes more revenue) by taking those enterprise customers while Fast was only getting SMBs? I'm currently at a seed-stage startup with a few Fortune 500 companies as users. We're lucky to have a great sales team that can bring that business in. If we're solving a problem for them, they're willing to use us regardless of our size, though they do care about some small particular is…

If you can get them, that's awesome. Which company?

Quick comment on this. I also work for a seed level startup and we have gotten dozens of Fortune 500s, plus most of the big accounting, auditing and consulting firms.

The reason this is possible for us is because our tech isn’t mission critical for them.

I doubt the CEOs/CXOs of any of these companies even know we exist.

We’ve just been fortunate that a lot of ops teams in these companies need our thing.

So - that has really changed my paradigm of enterprise sales.

Sometimes, if you’re SAP, you need to get whole of company buy-in. But if you’re SurveyMonkey, you don’t

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

#289

Post by danielmarkbruce »

DevKoala wrote: post #281
danielmarkbruce wrote: post #277

Earlier quoted context omitted.

You've compared the worst big tech engineers with the best startup engineers. Those are rarely the choices faced.

Your comparison was similarly unfair at the other end while presenting it as a common scenario, which is why I presented a different one. This is from my experience as a hiring manager who has worked at multiple startups and now works for a large public tech company.

But I was implying the choice isn't clear.

There aren't many good startup engineers with experience at successful startups who are floating around, especially from when the company in question was actually a startup.

edit: i re-read, my comment "failed startup engineer" may have read differently to what i intended. I meant they worked at a failed startup, not that they were a failure. It's largely unfair, but people do seem to think people who worked at a successful company are better than those who worked at a failed company.

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

#290

Post by danielmarkbruce »

marketerinland wrote: post #288
danielmarkbruce wrote: post #261

Earlier quoted context omitted.

If you can get them, that's awesome. Which company?

Quick comment on this. I also work for a seed level startup and we have gotten dozens of Fortune 500s, plus most of the big accounting, auditing and consulting firms. The reason this is possible for us is because our tech isn’t mission critical for them. I doubt the CEOs/CXOs of any of these companies even know we exist. We’ve just been fortunate that a lot of ops teams in these companies need our thing. So - that ha…

Yep, totally. I wasn't even surprised tbh. It's just a good thing and it takes a good ceo/early sales person to get those deals even if they aren't mission critical.
Post reply on HN