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

#431

Post by userulluipeste » Fri, Apr 08, 2022, 2:17 PM UTC

BigJono wrote: post #426

brian_cunnie wrote: post #419

Earlier quoted context omitted.

> we would have world-class catering for lunch every day I'd like to point out that this is not the case for every Silicon Valley start-up: the three start-ups I worked at (CollabNet, Aeluros, Ardatech) were incredibly frugal with money (exception: salaries were competitive). At one of the companies, the CEO and I took a trip to Safeway to buy soft drinks for customers. When we got back, I walked around the office te…

That sounds like way too far in the other direction at both places. Stuff like drinks and printers are basically noise compared to engineering payroll when you're paying people $250k a year. The lesson should be buy whatever the hell people want, just stop buying people until you need them. They're the expensive bit. 3 great devs can do about the same work as like 30 average ones. People massively underestimate commu…

"just stop buying people until you need them. They're the expensive bit."

If only they could be bought that easy right when you'd need them. At least in a corporation, the HR will tell you "50 engineers? That's going to take X monts, judging from the hiring rate we had so far."

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

#432

Post by danielmarkbruce » Fri, Apr 08, 2022, 2:33 PM UTC

kortilla wrote: post #350

danielmarkbruce wrote: post #256

Earlier quoted context omitted.

There is a pretty good reason. If the experienced engineer worked at a startup that went anywhere, they have a lot of money and aren't coming to work for you. So the choice in many cases is big tech engineer or failed startup engineer. It's not clear which is better, it is clear (ish) which seems better.

> If the experienced engineer worked at a startup that went anywhere, they have a lot of money and aren't coming to work for you. This is a stupid view of motivation and competence. First, it implies people are only motivated by money. At the first startup I worked at, one of the senior engineers had been through 4 successful exits and was in the business to build things. Second, competence of the engineering org and…

A lot of what you are saying is true - but if you re-read my comment, it wasn't saying what you seem to be thinking it was saying. Just read it literally.

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

#433

Post by danielmarkbruce » Fri, Apr 08, 2022, 2:33 PM UTC

DevKoala wrote: post #311

danielmarkbruce wrote: post #289

Earlier quoted context omitted.

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…

From my experience, the choice isn't clear favoring BigTech engineers either. For example, a pattern I noticed among the pool of BigTech engineers recruiters would pitch to me was the following. The engineer would join a startup with an immediate promotion in title, and then 18 months after the fact, they would jump back to BigTech to a higher level than the one they had when they left. When you asked what they deliv…

Yep, the choice really isn't clear.

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

#434

Post by danielmarkbruce » Fri, Apr 08, 2022, 2:35 PM UTC

notac wrote: post #319

danielmarkbruce wrote: post #256

Earlier quoted context omitted.

There is a pretty good reason. If the experienced engineer worked at a startup that went anywhere, they have a lot of money and aren't coming to work for you. So the choice in many cases is big tech engineer or failed startup engineer. It's not clear which is better, it is clear (ish) which seems better.

I think judging an engineer's engineering skills by the (effectively random) chance of them being at a startup that "makes them rich" just reveals a significant lack of understanding of how the current startup world works. The vast majority fail. The ones that succeed tend to not make anyone any significant amount of money except the founders. There seems to be a significant number of tech industry employees still fl…

At least in my experience, even people who understand how it works seem to have this bias. On average it might even be a fair bias.

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

#435

Post by danielmarkbruce » Fri, Apr 08, 2022, 2:37 PM UTC

te_chris wrote: post #358

danielmarkbruce wrote: post #255

Earlier quoted context omitted.

An overly positive culture is default behavior for most startups. It does appear to be poisonous and there is nothing you can do about it. If you call people out on BS, you are painted as a negative person. Not sure there is a fix.

Think this is a particularly American trait - though infecting other parts of the world. Brits, e.g., tend to be more cynical by default, so it’s hard to run a sycophantic culture like that.

Australians too, generally. The Fast situation is a very peculiar Australian.

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

#436

Post by panick21_ » Fri, Apr 08, 2022, 2:39 PM UTC

nikanj wrote: post #369

panick21_ wrote: post #344

Earlier quoted context omitted.

How one can patent something like this is just beyond crazy.

They didn't patent one-click, they patented one click _on a computer_. It's been well-established that you can patent anything, as long as it's on a computer.

Ah I didn't realize that. Computers are very fancy and who knows how they work.

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

#437

Post by danielmarkbruce » Fri, Apr 08, 2022, 2:39 PM UTC

Nextgrid wrote: post #381

danielmarkbruce wrote: post #263

Earlier quoted context omitted.

I don't work at salesforce, but I can almost guarantee people who work there will tell you they are miles from getting everything right. Every company is pretty messy internally. As for theranos and wework - i don't mean those kinds of things. I mean standard non-fraud startups. The always positive culture is there, and at least for folks who take some pride in being rational, it is quite demoralizing.

> I mean standard non-fraud startups. Fraud is not black and white. "Toxic positivity" can enable shenanigans or conceal problems in an otherwise non-fraudulent startup.

Yep true. I should have been more clear - I just meant that toxic positivity is more widespread, it's not only at fraudulent companies.

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

#438

Post by adamsmith143 » Fri, Apr 08, 2022, 2:49 PM UTC

nemo44x wrote: post #409

kortilla wrote: post #377

Earlier quoted context omitted.

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.

Right but I think even with "Successful" exits your equity will most likely just get you back to level if you had instead spent the time at Google e.g.

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

#439

Post by hedora » Fri, Apr 08, 2022, 2:52 PM UTC

lupire wrote: post #410

cormacrelf wrote: post #373

Earlier quoted context omitted.

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.

Also, the taxes for RSUs doesn't work. Say the pre-IPO stock is worth $3 right now, and a good exit is $10. I'll need cash to pay taxes on those RSUs as they vest. Their current market value should greatly exceed my salary as IPO approaches, but even at $3, the taxes on the RSUs are likely to be 25-50% of my post tax cash income. With 33% effective tax on the income, paying another 50% tax for the RSU vest means my effective tax rate would he 66%. Compensating for by increasing salary would increase the company run rate, and would bump many employees into the 51% tax bracket, so their marginal rate would be something like 75%.

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

#440

Post by brian_cunnie » Fri, Apr 08, 2022, 2:56 PM UTC

BigJono wrote: post #426

brian_cunnie wrote: post #419

Earlier quoted context omitted.

> we would have world-class catering for lunch every day I'd like to point out that this is not the case for every Silicon Valley start-up: the three start-ups I worked at (CollabNet, Aeluros, Ardatech) were incredibly frugal with money (exception: salaries were competitive). At one of the companies, the CEO and I took a trip to Safeway to buy soft drinks for customers. When we got back, I walked around the office te…

That sounds like way too far in the other direction at both places. Stuff like drinks and printers are basically noise compared to engineering payroll when you're paying people $250k a year. The lesson should be buy whatever the hell people want, just stop buying people until you need them. They're the expensive bit. 3 great devs can do about the same work as like 30 average ones. People massively underestimate commu…

> The lesson should be buy whatever the hell people want, just stop buying people until you need them. They're the expensive bit.

Absolutely. We were frugal, but not to the point of self-sabotage. Our biggest expense was payroll, followed by the Cadence/Synopsys EDA software licenses.

So, for example, no catered lunches or breakfasts, but if there was a customer or investor dinner, it would be expensed.

We had good health insurance, but we didn't have gym memberships or (gasp!) an onsite gym.

The workstations were powerful, but we shaved costs by buying "gamer rigs" instead of the more expensive "engineer workstations". We bought prosumer equipment (Netgear) instead of enterprise equipment (Cisco).

If someone needed, say, a Wacom tablet to accommodate a wrist injury, we made that happen.

We had a well-stocked lab, but some of the electrostatic benches we got at a good price secondhand.

Our office was near the train station to accommodate the engineers who commuted from the city, but it wasn't expensive space (all glass & chrome); it was a "B" office. We shared a bathroom with the other tenants. It was a little run-down, but it was clean.

We didn't have offices or cubes, just desks, and the CEO & President sat next to each other in the big room we all shared.