A lot of FAANG and FAANG-adjacent dev jobs are not any more glamorous than other dev jobs. A lot of the day to day looks the same, just keeping the lights on. Sometimes a really interesting technical problem does come up, but a lot of the complexity of the job is working within a huge complicated environment, both technically and organizationally.

I will say, completely anecdotally, that the average bar for competency and work ethic is higher. Day to day stuff just gets done faster and more thoroughly with more accountability. But that's just personal experience, YMMV.

I worked on cooler and more diverse stuff at various start ups and contract gigs, but I get paid literally double (or more) in big tech sooooo yeah riding it out for a bit. I don't see doing this for 20 more years, though.

Yeah, I imagine day to day work isn't profoundly different wherever you go, but rather it's intangibles like culture and work environment and working mentality that make the difference.

Most of my coworkers are simply there to collect a paycheck. Not that there's anything strictly wrong with that, but there is distinctly a lack of interest in doing anything beyond the bare minimum to satisfy technical requirements. Grass is greener on the other side, but my interactions with employees of tech companies has given me the impression that they're just a lot more enthusiastic about their work than many equivalent SWEs at companies where tech is a cost center.

The features may have limited scope but if they have an entire team dedicated to them they usually deal with large enough scale that it's worth it.

When you're dealing with distributed systems at large scale you can no longer have services be down for longer periods of time because it's a lot of money you're losing.

The business decision for employing an engineer or engineering team should be made at the margin -- that is, if the marginal revenue increase is higher than the cost of employing that team you should definitely employ them.

At large scale, a sub 1% increase in revenue or decrease in revenue lost can be multiple $M, so it would be worth having a team that only increases productivity across the company by an average of <1%.

FAANG companies can't move fast and break things like startups. If their services go down, it might be mentioned on the evening news, and it would certainly cost a lot of money. FAANGs have huge existing revenues to protect, large customer bases to keep happy, and laws to obey in all of the countries where they operate.

A "simple" feature change is not so simple for companies with those concerns.

Can't you say the same about banks and finance? Hospitals and medical tech? Software in say, cars, aircraft, ships? If anything, even more so?

I could be naive, but what is the most societal impact that could happen if say, Instagram goes down or gets a major bug? Or if something went wrong at Netflix?

Vs. software going wrong at a major bank or on an airliner?

"move fast and break things" is literally Facebook's motto, the F in FAANG. It's why you know the motto.

They used that motto when they were a startup and changed it a while ago.

> On May 2, 2014, Zuckerberg announced that the company would be changing its internal motto from "Move fast and break things" to "Move fast with stable infrastructure"

https://en.wikipedia.org/wiki/Facebook,_Inc.#History

A lot of small features are needlessly complicated at a FAANG because they reinvent the wheel.

I think it's also that the economics are just different. If you're evaluating a CICD tool at a small company, you're going to find something affordable and bend your process to how it works. A mid-size company might invest a bit into customizing Jenkins hoping that it will pay off in the long run. A giant company might spend millions building a fully custom system from the ground up because gaining 1% more efficiency in developer effort or even build times makes it worth it. And more than that, they may be willing to invest in experiments knowing that some will fail because the chance of success is still worth it.

From what I have seen, the internal tooling is usually worse than what is publicly available. Often times it is only used because it was built before there was anything publically available, and now all of their tooling and workflow depend on it and they can’t easily change. Plus no one wants to rock the boat and suggest throwing out a tool that likely employs a bunch of people.

And the return of investment for the change is low plus it's an extremely hard sell for management ("we'll work 2 years to get roughly where we are now and maybe get 3 minor features plus the promise of lower maintenance in the future").

I don't think that's limited to FAANG. My company needlessly reinvents the wheel, but I get the impression the reinvented wheel is more competently reinvented at FAANG than at my bank.