Declaring a FAANG company failing because it‘s toolset is antiquated is the rare hn elitist opinion you see here more and more. Are startup people in the valley more and more becoming blind to the real world?
There is a certain kernel of truth to it. I work at Google, and doing anything at all is a chore - it's almost as if we're back to programming with punch cards.
It's not surprising that Python doesn't work well in such a high-delay dev environment.
I haven't worked at Google or any other big tech company, but I understand that Google's culture is far more like academia anyway. Compared to Facebook, Google prioritizes code quality over development speed. Other companies seem to fall somewhere in between.
> Google prioritizes code quality over development speed.
That's putting it nicely. Based on experience, I'd say it's arguing about preferences while demanding that code be coupled because "that's how we do things here".
> culture is far more like academia anyway
Academia is actually based on research and correctness to a much higher degree. The lack of focus on correctness in code worked on at Google is, honestly, appalling. Until, of course, you realize that all other FAANG employees still write loads of concurrency bugs and pronounce themselves gods for doing so.
> That's putting it nicely. Based on experience, I'd say it's arguing about preferences while demanding that code be coupled because "that's how we do things here".
That's certainly not been my experience (and I get the exact opposite impression from people involved in the formal readability process).
> Academia is actually based on research and correctness to a much higher degree.
This depends, greatly, on what part of academia you're in. In many ways, Google is much better about correctness than much of academia (reproducibility, for example, is often near trivial at Google but uncommon in most non-theoretical areas of academia).
> The lack of focus on correctness in code worked on at Google is, honestly, appaling
There are tradeoffs here. On the one hand, you have tens of thousands of engineers, you're not going to be able to enforce perfection by every single one with the tools available today with a reasonable cost. On the one hand, I see evidence that Google is willing to invest huge amounts into improving software correctness at the lowest levels (like proposing and upstreaming changes to languages to improve correctness-by-default).
Hi, can you elaborate the high delay part? Is it the case that all code is accessed through internal network using FUSE or something? Or is it because monorepo?
I'd say once you take a peak behind the curtain at some of these FAANGS you see that their once greatest assets are becoming liabilities. The magic of "FAANG" goes away. The innovative systems they all built in 2007-2012 period are now aging.
so right, but it won't make you any money or get you any linkedin/twitter fans if you speak the truth. We have AI being tossed around like it isn't just database queries most of the time.
I don't think I agree with you. Systems have been evolving, some are being deprecated, rewritten, etc. It might be true that the OSS world has been catching up so it is worth less to have a custom made solution. But the fact that systems are aging does not mean that those systems are becoming irrelevant.
On the one hand I agree with you, in that these liabilities you describe are much like the legacy systems I see in our local banking sector.
On the other hand, these legacy systems just work. And adopting newer / more modern systems might definitely have advantages, but doing so creates a bunch of other liabilities - as I've seen take place in our new startup banks.
Stuck between a rock and a hard place.
Of course that's just in banking. I most certainly don't have the experience to comment on whether the same liability tradeoff would happen at FAANGs.
FAANG's often don't have paying customers, banks do.
Its not being stuck between a rock and a hard place, you just need strong management that understands that changing whole systems is never a good idea without clear benefit, other than "technical debt" which is such a bad term for reliable software. Software doesn't age, im not sure how software engineers don't understand this, or maybe they do and want to write more s/w.
