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

381–390 of 482 posts

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

#381

Post by Nextgrid »

danielmarkbruce wrote: post #263
throwthere wrote: post #259

Earlier quoted context omitted.

Makes me think about theranos or wework. Charismatic leaders can get a lot of people/talent following them without necessarily having a solid grasp on all of the complicated aspects of the business they run. Of course you have really great charismatic leaders in startups like Marc Benioff for example who kind of get everything right.

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.

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

#382

Post by Nextgrid »

mwcampbell wrote: post #273
henrikschroder wrote: post #258

Earlier quoted context omitted.

> I wonder when the music stops. Who cares? Champagne on the Concord, and let's order a bunch of Starfire servers from Sun Microsystems!

> let's order a bunch of Starfire servers from Sun Microsystems! I wonder if any doomed startups will order a rack from Oxide Computer. I hope Oxide's primary customer base is established companies that actually need serious efficiency at scale.

Does it matter? If there's an infinite supply of VC-funded startups it doesn't matter whether those startups ultimately succeed - Oxide gets paid upfront either way. If anything, companies burning money by buying your stuff for hype reasons without actually making much use of it is probably better with regards to support queries/warranty claims than those actually making serious use of the equipment.

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

#384

Post by dmje »

kortilla wrote: post #374
dmje wrote: post #339

Earlier quoted context omitted.

Sure. I’m just expressing discomfort at how it became just “meh, it’s how it is”. My issue is I just don’t see the world in this money focused way. From out here, in the land where it’s sort of average to earn maybe $50k and feel pretty good about that, it looks pretty sick. I don’t get it, I don’t like it, it feels disingenuous to support it with what seems to be an endless “it’s ok, everyone does it” or “that’s jus…

Get a better job, you’re underpaid if you have the skill set to work in tech. Don’t take it out on everyone else because you’re selling your skills at below market value. > Maybe if those guys gave away 50% of their salaries to support good causes, I’d feel better about it Do you give away 50% of your salary? How would you feel about someone who only clears $30k claiming you don’t need that money and that you should…

I'm not an engineer, I'm a generalist who works in tech. I'm based in the UK, so no - I apparently have no idea about what it's like to live in the area. But that's not really my point. My point isn't about how expensive it is to live in SF, it's about looking at this bigger picture thing about money, how important it is, why the world (and let's face it, particularly the US and even more particularly the tech hot-spots of the US) is killing itself on 80 hour weeks for insane salaries but still being miserable and having to fill themselves with happy pills to get through the day, and meanwhile 90% of the world is scraping food out of a ditch. Sorry for being an idealist, or "out of touch" but I don't know how anyone can look at this and just say "yeh, I'm ok with that".

FWIW, some context:

- I live on a household income of maybe $100k for a family of 4, by the sea in Cornwall. We live what I would personally consider an extremely luxurious life: a 5 bed house, lots of space, lots of greenery, big skies, amazing seas, and time to look at them

- I work way less than a 40 hour working week. I work with non-profits. I love what I do. It makes me happy.

- I see my kids. I see my wife. I hang out with my friends. I have hobbies. I'm putting aside enough for a pension. No, I won't be able to retire at 50 (I'm 49!), and I'll probably still be doing this in 10 / 15 years' time. But it's fun, thoughtful work that (I hope) isn't going to kill me.

As you've asked - no, we don't give away 50% but we are gifting 10% of profits this year, to see what it means, and will likely be upping this and taking the Effective Altruism pledge next year. It's a small amount, but it feels important and the right thing to do.

I had to look up "tall poppy syndrome" - I'm getting old :-) To respond to this particular criticism - I mean, I guess I'd ask "what is success?" here. I don't know if there's a way of saying this without sounding highly antagonistic or patronising, but for me it's less about criticising those who have found "success" and more that I feel sad for people who think money is everything. It strikes me as the ultimate folly.

And thanks, but I don't feel held back. I feel pretty good. Anyway, It's 10am on a Friday morning and I should go start work ;-)

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

#385

Post by Nextgrid »

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…

> Sounds like the whole thing could have run on a single cheap VM, perhaps with a second one for redundancy.

You're describing most startups here.

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

#386

Post by Nextgrid »

enra wrote: post #80
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. This is often the problem when hiring too fast. New employees don't have context or direction but generally people try to be productive, so they start inventing work. Management team is new too, and not built up either direct or handle the bandwidth and they also are lacking the direction.…

"Hiring too fast" happens because managers, company executives and sometimes even investors want to play with shiny toys rather than solving the problems they actually had.

The "shiny toys" in this case are employees and the task of managing them.

As a (future?) lead/manager, having more people on your team bolsters your resume. A lot of people would benefit from the company hiring more too as it generates demand in other parts of the business - HR, IT support, etc (which in turn causes more hiring if you need more people to deal with the increased workload). As a higher-up in the company, it looks better on your resume if it was a "big" company with 100+ employees rather than a scrappy garage startup with 3 people, and likewise for investors.

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

#387

Post by itronitron »

whymauri wrote: post #156
cush wrote: post #118

Earlier quoted context omitted.

But the revenue is also inflated, so it all works out in the wash.

So Pets.com actually drove more revenue than Fast?! Oh my god.

Also, most people in the US had heard of Pets.com while it still existed.

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

#388

Post by Nextgrid »

teaearlgraycold wrote: post #225
CoastalCoder wrote: post #161

Earlier quoted context omitted.

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.

Seeing someone using nothing but tried and true tech to solve new problems is a resume green flag.

Is there a place where such "green flags" would net me money? It seems like as a software engineering employee, the roles that require me to waste time reinventing the wheel and battling self-inflicted complexity pay significantly more than those who require solving actual problems with boring tech.

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

#389

Post by ChrisMarshallNY »

infinite8s wrote: post #260
ChrisMarshallNY wrote: post #198

Earlier quoted context omitted.

...which is why it's so important to foster an environment, where they don't want to leave. I kept engineers (really good ones) for decades . They had many "life problems" (like divorce, cancer, etc.) during that time, and I kept them on. It's entirely possible. I have done it. I ran a team that was all "top-shelfers."

I assume you were able to do it with more than just money?

Definitely. My company offered “competitive” salaries (i.e. “low”).

I feel as if I was a very “human” manager, and that seemed to make the difference.

My employees were loyal to me, not the company. Not an ideal situation, but it WFM.

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

#390

Post by ChrisMarshallNY »

lostcolony wrote: post #324
ChrisMarshallNY wrote: post #198

Earlier quoted context omitted.

...which is why it's so important to foster an environment, where they don't want to leave. I kept engineers (really good ones) for decades . They had many "life problems" (like divorce, cancer, etc.) during that time, and I kept them on. It's entirely possible. I have done it. I ran a team that was all "top-shelfers."

You still should avoid being too siloed. Bus factor matters; their life problems you might be able to keep them, but you're ensuring you suffer death problems the same time they do.

Well, the software industry seems to believe that, for some reason, we get to live by different rules from every other company on Earth, throughout all of human history.

Depending on key roles is something that every company in history has had to do. It’s a risk, but one that has been paying off for hundreds of years, for millions of companies.

There are ways to reduce “bus factor,” yet still maintain high Quality work. The corporation I worked for, managed this, but the price is extreme levels of overhead and rigidity. That has its own risks. I was treated as a “cowboy” in our company, and was considered to be borderline “reckless.” Most folks here, would have considered me to be destructively conservative and risk-averse. I got the job done, though. Our team consistently delivered high-Quality solutions to difficult problems, for decades.

The “easy answer” is to keep expectations and demands on labor low. Keep quality to a minimum. Rely on “black box” dependencies. Don’t use advanced development techniques. Squeeze your coders like lemons. Treat every employee the same as every other one, and control for the lowest common denominator.

That’s not how I worked.

It's OK. The industry is safe from me, and my radical views. It was made abundantly clear, years ago, that no one wants people like me in their company, so I have been forced to work with people that can't afford even crappy programmers.

Poor bastards are living the nightmare.

Post reply on HN