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

361–370 of 482 posts

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

#361

Post by kortilla »

bps4484 wrote: post #183
encoderer wrote: post #173

Earlier quoted context omitted.

You are 100% right — for late stage startups where you would normally see 500 people. At the Fast stage, the only viable promotion path is ship work that impacts the business or close deals that bring in revenue. The promotion levels game is something you play in larger organizations to engineer a rat race for people because it turns out they really like that. But no, a startup does not benefit from hierarchy quite t…

they were a company of nearly 500 people. they had 150 engineers. At that stage people who don't have levels will feel like they have no direction.

Oh shit, there is no number in front of my name! What will I do with my life? The incredible vanity of it all.

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

#362

Post by nikanj »

munchler wrote: post #199
bps4484 wrote: post #184

Earlier quoted context omitted.

I completely disagree. They were 450 people with 150 engineers. If I had to guess I would bet the engineers clamored for leveling and it came from bottoms up requests and a need to be fair with compensation when hiring. Now to be clear they shouldn't have been that big (clearly), but leveling people was not the problem.

That simply begs the question of why in god's name a startup with no traction needs 150 engineers.

Engineering is expanding, to meet the needs of the expanding engineering. Continuously built self-scaling heuristic AI-based microservices that have full resiliency across four datacenters and twelve chaos monkeys.

Do not underestimate mans ability to overcomplicate things, when his continuing employment depends on him finding more things to engineer.

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

#363

Post by netfortius »

The hockey stick may be odd in the case of startups, and maybe in regards to strict specialization (of software engineering), which may be the intended audience of HN. There is nothing wrong (in fact normal, and considered healthy if the slope of growth matches the needs) for expansion of a product in diff countries, upon acquisition of new manufacturing or distribution points, for example, or after divestiture events, or even some M&As directed towards short term expansion of product reachability, when a large, global company leverages a small acquired one for a niche product gaining large distribution capabilities, etc., etc. All in all - hockey stick shape is not always bad - quite to the contrary.

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

#364

Post by nikanj »

propter_hoc wrote: post #111
tomrod wrote: post #61

Earlier quoted context omitted.

Yes, but also no. Per the CPI, for every $1 in 2000, you need $1.68 today. 1.68^1/22 - 1 is about 2.39%/year inflation. https://data.bls.gov/cgi-bin/cpicalc.pl?cost1=1&year1=200001...

For the purposes of engineering salaries, CPI is not an accurate representation of the change in what $100M can buy.

For the purposes of corporate exits too, or for the purposes of real estate.

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

#365

Post by kortilla »

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.

This attitude of cutting down the upper middle class incomes is baffling to me. On $250k you can probably retire 10 years earlier than normal. It’s nice but you still live a normal life and do normal things.

Why is it normal in your mind for a lawyer to make that? Why a doctor? Why the owner of a small business? Why an exec?

> No-one needs that kind of money.

Money hasn’t been issued based on need ever in the history of the world. How is this any different?

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

#366

Post by noisy_boy »

lostcolony wrote: post #323
tootie wrote: post #206

Earlier quoted context omitted.

There's always misalignment incentives. If you put a tech manager in charge they're going to look for tech solutions that increase their head count.

Not really. Managers don't have incentives to grow their team size; they have incentive to deliver. And Amazon is known for 'two pizza teams' anyway. The parent mentioned 5 teams instead of 2. That's director or higher level decisioning. Which is where you frequently end up having someone far enough away from the actual work that needs to be done, starting early to come up with a roadmap. Given fixed deadline and fix…

> Not really. Managers don't have incentives to grow their team size; they have incentive to deliver.

This may be true about Amazon but it is not a given in general. Managers can operate in the grey area where they deliver just enough to justify more headcount "in order to deliver more" where the underlying motivation is increasing headcount. Not atypical in political environments like banks etc.

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

#367

Post by dgb23 »

irjustin wrote: post #291
SkyPuncher wrote: post #143

Earlier quoted context omitted.

I've done startup engineering for a while. I've seen exactly 1 issue that we couldn't solve easily (N+1) or with simply turning our server count up (often way cheaper than putting an engineer to a problem). Basically, to move development velocity faster we "load everything". Seems like a really bad idea on the surface. In practice, we only ran into an issue with a single customer that was literally 1000x as large as…

Exactly, the cost of turning on additional servers is measured in ~US$100's/mth vs an engineer's time ~US$10k-25k/mth. If you can make the problem go away by spending more in servers always do it. For startups, the life and death is product market fit and you only get there by iterating on the business as many times as possible, not making something more efficient. Put engineers on business iterations.

Using more machines also introduce complexity.

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

#368

Post by omarfarooq »

throwawaythekey wrote: post #266
pyb wrote: post #218

Earlier quoted context omitted.

Good point, I am always surprise when well funded startups hire former big-tech engineers, rather than experienced startup engineers.

I interviewed at Fast last year as an experienced startup engineer. I was given the "describe a production incident you were involved in" question. I detailed a case where a recent deploy I had done had resulted in elevated error rates for some of our clients and how I had solved it with a quick follow up push to prod. The interviewer asked why it wasn't caught in staging and I mentioned that it could have been but a…

What exactly is meant by "cowboy" here?

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

#369

Post by nikanj »

panick21_ wrote: post #344
rileyphone wrote: post #131

Earlier quoted context omitted.

Amazon had the patent but it expired recently AFAIK.

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.

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

#370

Post by tuyiown »

im_down_w_otp wrote: post #272
belval wrote: post #270

Earlier quoted context omitted.

This echos my experience at a $100M startup that I worked for and that ultimately failed. HR would tell us we were extraordinary, we would have world-class catering for lunch every day, and yet we had no customers, no contracts, and no money except the investors'. It was a sobering realisation on the damage that can happen when you are submerged in toxic positivity. You forget that companies still need to earn actual…

How on Earth did the company raise so much money with so few milestones of any kind being achieved?

Way too much VC money is not driven by business analysis, and influenced by FOMO, especially in big names circles. It's totally irresponsible.
Post reply on HN