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

351–360 of 482 posts

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

#351

Post by hef19898 »

enra wrote: post #328
b20000 wrote: post #312

Earlier quoted context omitted.

this doesn't answer the question at all, it's just a bunch of bullshit words strung together. we never raised any money, and we had more to show than Fast although we were in a completely different industry. this goes to show that all that matters is knowing people, it doesn't actually matter whether you have a real business and have achieved anything at all.

VCs sometimes follow "hot" companies. Companies become hot when several VCs think they are hot for whatever reason. When the company is hot and gets offers, other VCs will rush to give them more offers and at that point you might not even need a deck or any metrics anymore. The startup can then bid those offers against each and can end up raising even more they initially were trying to. Fast did great job hyping the…

I'm all in if a founder can "sell" a company to raise money. It becomes a problem once people believe their own hype, so.

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

#352

Post by rossriley »

dmje wrote: post #318

Sorry, I read it all the time, but still - how the fuck is it suddenly normal for a fairly standard salary amongst any non exec layer in a company to be ~$250k? I know engineers and developers have to be skilled, but this is insane. No-one needs that kind of money. People in Nepal live for $10 a week. What an insanity.

Engineers at this level aren't just cogs in a wheel, the best ones can conceive, architect and ship businesses that deliver 100s of millions in revenue.

At this point in time, they're not valuing their time, but their overall value that can be brought into a company.

So just the same as a top sales person that can bring in millions of dollars of revenue can earn a certain percent of that as commission, the best engineers can strike a similar deal.

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

#353

Post by hef19898 »

StillBored wrote: post #119
Spivak wrote: post #35

Earlier quoted context omitted.

And if you think this is undersized for comedic effect I did ops for a company that went from <1mil to 15mil revenue (with the same sales strategy of targeting lots of small clients) on 4 1u white label supermicros. Two app servers and two MySQL dbs. Never in my life had such reliable infrastructure.

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"

Sounds like someone didn't understand redundancy...

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

#354

Post by agilob »

teruakohatu wrote: post #309
rockostrich wrote: post #74

Earlier quoted context omitted.

This is pretty hilarious to read. I did an interview screen with them at the end of last year for a data engineering position (former coworker was high up on the design side of things and he gave a referral). The first bit of the technical question was just "write a SQL query" and boiled down to doing a group by, count, and limit. The second was something like "what if we needed to return this query from a distribute…

What is a time-windowed hash-map? Just a time based key-value store?

Yes, a hash map that expires objects and loads new KV when key isn't present inside

https://github.com/google/guava/wiki/CachesExplained

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

#355

Post by telotortium »

JumpCrisscross wrote: post #108
deepinsand wrote: post #92

Earlier quoted context omitted.

I believe startups should implement levels once you hire 2 engineers. It's hard to retrofit a system, especially if you're trying to be thoughtful about any pay imbalances.

> startups should implement levels once you hire 2 engineers I think OP is cracking a joke about a $600k company having six levels of hierarchy.

There weren't necessarily 6 levels of hierarchy (below the L6 staff). It's almost certainly for hiring purposes - to tell hires that their role is similar to that of a Staff Software Engineer at Google (i.e., L6). Like many things in tech, other companies tend to base their leveling system after Google, and you can literally put companies side by side on https://levels.fyi to compare per-level compensation at different companies.

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

#356

Post by v-erne »

bjarneh wrote: post #335
dmje wrote: post #318

Sorry, I read it all the time, but still - how the fuck is it suddenly normal for a fairly standard salary amongst any non exec layer in a company to be ~$250k? I know engineers and developers have to be skilled, but this is insane. No-one needs that kind of money. People in Nepal live for $10 a week. What an insanity.

> No-one needs that kind of money. I'm currently renovating an old house, I certainly need it :-)

Yeah, building anything became rich man game everywhere. Building materials prices are getting crazy all over the place (in my country price of some of them doubled or event tripled over last two years).

But I like to tell myself that maybe, just maybe, it's not like the world owes me a possibility to have house. And maybe I don't even need or should have one. Its just my greed that pushes me towards having more stuff (and thus need more space to keep it).

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

#357

Post by telotortium »

encoderer wrote: post #17
gregdoesit wrote: post #12

Earlier quoted context omitted.

Author here. I was wrong on this information and updated the article - got a correction since. L6 and above employees would receive this: staff+ engineers, eng leadership, sales etc. There are companies where this information does go out to all employees in the spirit of radical transparency. Skyscanner is an example where every day, every employee gets the full revenue breakdown. These numbers are also shown on moni…

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

It's a recruiting tactic - to tell the FAANG engineer that they'll be as important as a Staff Software Engineer (L6) at Google.

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

#358

Post by te_chris »

danielmarkbruce wrote: post #255
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…

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.

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

#360

Post by Aeolun »

randomdata wrote: post #326
Aeolun wrote: post #243

Earlier quoted context omitted.

It’s a post from around a week ago. They went from embedded JSON, to something else (equally crazy), to embedded JSON again. Lots of laughs were had (and a lot of, just use postgres).

> They went from embedded JSON, to something else (equally crazy), to embedded JSON again. They went from a JSON file, to etcd, to SQLite. etcd seems a little misplaced, but presumably it was already in their infrastructure and they thought they could save time leveraging it. The file-based approach seems appropriate for their particular use-case, though. It's not like it's a Rails app.

Crap, I’d forgotten about the sqlite part. You are of course correct. Apparently I’d only remembered the fact they went back to something file based :/

I’m still of the opinion that whatever you are storing, if your alternatives are JSON or Sqlite, etcd is a really strange/unconventional choice.

Post reply on HN