3 ms·

One misconception people get wrong, from my perspective, about most FAANG is that you get to work with new and shiny things, especially new langauges. This is r

One misconception people get wrong, from my perspective, about most FAANG is that you get to work with new and shiny things, especially new langauges. This is really more applicable to startups where risk taking is in the DNA, you will mostly get really strong pushback because there is just too much effort involved to support more than two or three languages at scale. There are normally niche languages, but they are essentially statistical anomalies and are usually borne out of a real business need (like swift for iOS). Mostly engineering for engineering sake is also going to be frowned upon unless it really helps the business. I do agree that Amazon is the worst in regards to OSS. They really need to fix that, even if jut for PR, because they are consuming so much of it for AWS.

umanwizard 8y ago
Very good comment, +1. People don't really get the rabbit hole that is necessary in order to introduce a new technology at a large company. Just off the top of my head, a few of the issues: * Not everyone has followed the broader technology world outside the big company. It's totally possible to imagine a situation where nobody in your management chain or team has even heard of something relatively mainstream like Docker. * Your company uses custom build, deployment, and dependency management systems. Someone will have to do the work to implement support for the new technology in these. * If the new technology has its own opinionated ideas about how to do any of the above, like Rust crates, npm, pip, etc., forget about it. You need to interact with previously existing internal code which means you need to fit into the already existing build/deployment/dependency solution. * Your company has a bunch of custom internal services. You need to create bindings for these services' APIs in the new language. * Your company might be doing some esoteric stuff that the new technology has no support for, like for example if your network stack does HTTP in some sort of custom-tuned way for performance, and the new language's HTTP library only supports a subset of everything that's possible. * The new technology may have correctness or performance issues that have never been discovered because it has never been used on many thousands of servers where a 1% difference in CPU makes a huge difference, or it has never been used with a codebase big enough to take >1 day to build, or with binaries larger than several GB, etc. And the biggest one... * Every day, many new people are joining the company and beginning to ramp up on the (internally) mainstream solutions that have institutional inertia. This will dwarf the speed at which you can convince people to switch to the new technology. The pattern I have seen is that something starts off being used for one-off scripts that don't have a lot of dependencies on the existing gargantuan infrastructure, then very, very gradually gaining mindshare internally and becoming more supported.
- Frost1x 8y ago
  "...or it has never been used with a codebase big enough to take >1 day to build..." I've not worked in this scale of enterprise environments so I find this tidbit fascinating. Why does the codebase take over a day to build? Does that time include rebuilding and deploying the underlying infrastructure? I'm genuinely interested here. I can only imagine a few highly niche cases myself so I'm curious what I'm missing here.
  - umanwizard 8y ago
    Hard to find updated publicly-available information on this, but it was claimed that in 2003, Windows took 12 hours to build, on a multi-machine build farm: https://www.itprotoday.com/windows-server/supersite-flashback-nt-s-first-decade https://www.itprotoday.com/windows-server/supersite-flashbac...
  - ilovecaching 8y ago
    If you look at buck or hazel, they both use caching or artifacts to speed up builds. It still takes a long time, because everything depends on everything. But for most projects a fresh build is going to take tens of minutes normally for a medium sized project pulling in a big deep.

umanwizard 8y ago

Very good comment, +1. People don't really get the rabbit hole that is necessary in order to introduce a new technology at a large company. Just off the top of my head, a few of the issues: * Not everyone has followed the broader technology world outside the big company. It's totally possible to imagine a situation where nobody in your management chain or team has even heard of something relatively mainstream like Docker. * Your company uses custom build, deployment, and dependency management systems. Someone will have to do the work to implement support for the new technology in these. * If the new technology has its own opinionated ideas about how to do any of the above, like Rust crates, npm, pip, etc., forget about it. You need to interact with previously existing internal code which means you need to fit into the already existing build/deployment/dependency solution. * Your company has a bunch of custom internal services. You need to create bindings for these services' APIs in the new language. * Your company might be doing some esoteric stuff that the new technology has no support for, like for example if your network stack does HTTP in some sort of custom-tuned way for performance, and the new language's HTTP library only supports a subset of everything that's possible. * The new technology may have correctness or performance issues that have never been discovered because it has never been used on many thousands of servers where a 1% difference in CPU makes a huge difference, or it has never been used with a codebase big enough to take >1 day to build, or with binaries larger than several GB, etc. And the biggest one... * Every day, many new people are joining the company and beginning to ramp up on the (internally) mainstream solutions that have institutional inertia. This will dwarf the speed at which you can convince people to switch to the new technology. The pattern I have seen is that something starts off being used for one-off scripts that don't have a lot of dependencies on the existing gargantuan infrastructure, then very, very gradually gaining mindshare internally and becoming more supported.

Frost1x 8y ago
"...or it has never been used with a codebase big enough to take >1 day to build..." I've not worked in this scale of enterprise environments so I find this tidbit fascinating. Why does the codebase take over a day to build? Does that time include rebuilding and deploying the underlying infrastructure? I'm genuinely interested here. I can only imagine a few highly niche cases myself so I'm curious what I'm missing here.
- umanwizard 8y ago
  Hard to find updated publicly-available information on this, but it was claimed that in 2003, Windows took 12 hours to build, on a multi-machine build farm: https://www.itprotoday.com/windows-server/supersite-flashback-nt-s-first-decade https://www.itprotoday.com/windows-server/supersite-flashbac...
- ilovecaching 8y ago
  If you look at buck or hazel, they both use caching or artifacts to speed up builds. It still takes a long time, because everything depends on everything. But for most projects a fresh build is going to take tens of minutes normally for a medium sized project pulling in a big deep.