7 ms·
The internal tools at Meta are incredible tbh. There’s an ecosystem of well-designed internal tools that talk to each other. That was my favorite part of workin
by web3aj 2y ago
The internal tools at Meta are incredible tbh. There’s an ecosystem of well-designed internal tools that talk to each other. That was my favorite part of working there.
- Random_BSD_Geek 2y agoPolar opposite of my experience. To achieve the technical equivalent of changing a lightbulb, spend the entire day wrangling a dozen tools which are broken in different ways, maintained by teams that no longer exist or have completely rolled over, only to arrive at the finish line and discover we don't use those lightbulbs anymore. Move things and break fast.
- extr 2y agoYeah 100%. I found it immensely frustrating to be using tools with no community (except internally), so-so documentation, and features that were clearly broken in a way that would be unacceptable for a regular consumer product. If you have a question or error not covered by an internal search or documentation, good luck, you'll need it. Literally part of the reason I left the company.
- landedgentry 2y agoWell, you're supposed to read the code and figure it out. And if you can't, you're not good enough an engineer. According to people at Meta.
- extr 2y agoPeople probably think you’re exaggerating but it’s true. Sometimes when I would get blocked the suggestion was to “read the source code” or “submit a fix” on some far flung internal project. Huge fucking waste of time and effort, completely unserious.
- hnav 2y agoDoesn't sound like your type of company tbh, the flipside is that a "serious" company will often have broken bs too except now nobody is going to look at your contribution/fix.
- KaiserPro 2y agoPfft. "your type of company" sod off. Meta is only like this because its got a massive advertising revenue stream. the sheer amount of engineering time wasted because we don't document stuff is astounding. For example, how many message queue systems do we have? how many half arsed message queues have been created because they didn't know about FOQS?
- extr 2y agoYes lmao, the number of times I would start off on some nominally useful task only to find out 3 weeks later that there is actually already a solution to that created by team XYZ that nobody in my reporting chain has ever heard of…(3 weeks was optimistic case, I remember my team member getting like 2 months in to some new data pipeline before finding out some tables already existed that did what he needed…)
- lclarkmichalek 2y agoI think a fair few of them were created because they knew a bit too much about FOQS
- tru3_power 2y agoNo matter what, tools will be broken. Having access to the source and being able to land a diff to fix the issue is awesome imo.
- extr 2y agoThat’s how open source already works by default. The difference is if an OSS tool is broken my boss doesn’t imply landing a fix is my responsibility on top of my regular job duties.
- moandcompany 2y agoSame as Google. Many internal tools have painful interfaces and poor or documentation because the hiring bar was high and it was acceptable to assume that the user's skill level is high enough to figure it out. That attitude becomes a bigger problem when trying to sell tools to the public (e.g. Google Cloud Platform).
- yodsanklai 2y agoAs an outsider, I was always under the impression that Google had a tradition of engineering excellence (robust tools, clean and while tested code following strict guidelines), while Meta has more of a Hacker culture (move fast and break things).
- moandcompany 2y agoGoogle also has traditions that created Broccoli Man: https://www.youtube.com/watch?v=3t6L-FlfeaI https://www.youtube.com/watch?v=3t6L-FlfeaI
- fsociety 2y agoOr you know, go chat with the tool maintainers because they want people using them for impact.
- KaiserPro 2y agoWelcome to meta! where everything is a murder mystery. Except you're not really sure if there has been a murder, or sometimes you wonder if you're the murderer, because at every turn you're told that you've been a bad dev for trying x,y and z
- zer0zzz 2y agoAgreed. I often get my work done using open source build instructions and tools and then when everything works I port it to internal infra. Other people are the opposite though, which for open source based code bases has a nasty side effect of the work having no upstream able tests!
- loeg 2y agoIMO there's a mix of a few really good, widely used, well-supported tools as well as a long tail of random tiny tools where the original team is gone that are cruftier.
- uuddlrlrbaba 2y agoMmm breakfast
- grantsucceeded 2y agohaha the reason I stayed as long as i did
- deleted 2y ago[deleted]
- bozhark 2y agoMove Smooth and Fix Things (tm) is our nonprofit corporation’s version of this atrocious motto.
- ElonChrist 2y ago[dead]
- ec109685 2y agoLarge checkouts is a solved problem now https://github.com/facebook/sapling/blob/main/eden/fs/docs/Overview.md https://github.com/facebook/sapling/blob/main/eden/fs/docs/O...
- aprilthird2021 2y agoBut you're both talking about different things. The tools are both often left in disuse, lacking documentation, etc. But they also have a really tight integration with each other that allows for unparalleled visibility and ability over enormous systems with many moving parts.
- deleted 2y ago[deleted]
- crabbone 2y agoA friend of mine is doing his PHD while being an intern at Meta. He does not share your excitement... at all. To summarize his complaints: a framework written a long while ago with design flaws that were cast in stone, that requires exorbitant effort to accomplish simple things (under the pretense of global integration that usually isn't needed, but even if was needed, would still not work).
- slt2021 2y agohow else can you build empire as Engineering Manager and get promo? fork open source, then demand resources to maintian this monster. easiest promotion + job security. its even called "Platform Engineering" these days
- almostgotcaught 2y ago> A friend of mine is doing his PHD while being an intern at Meta I interned thrice as phd student at FB. your friend isn't entirely wrong but also just doesn't have enough experience to judge. all enormous companies are like this. FB is far and away better than almost all such companies (probably only with the exception of Google/Netflix).
- jonathanyc 2y agoAgreed. I'm reading some complaints in the thread about being told to "just read the source code" for internal tools at Meta. When I worked at Apple we didn't even get the source code!
- crabbone 2y agoI don't see why saying that Facebook's tools are bad should be invalidated by saying that Google's or others' tools are bad too. Google being bad doesn't vindicate or improve Facebook tools. There's no need for perspective: if it doesn't work well for what's it designed to do, then that's all there is to it.
- almostgotcaught 2y ago
- jchonphoenix 2y agoMeta tools are best in class when the requirement is scale. Or that the external tools haven't matured yet
- JohnMakin 2y agoOne of the crazier things a L4 meta colleague of mine told me, that I still don’t believe entirely, is that meta pretty much has their own fork of everything, even tools like git. is this true?
- sdenton4 2y agoIt wouldn't be terribly surprising. Forking everything provides a liiiitle bit of protection against things like the 'left pad' incident.
- deleted 2y ago[deleted]
- 3eb7988a1663 2y agoLeft pad was from the creator pulling the code from the public source forge, not from a destructive code change. I assume all of the big tech companies host internal mirrors of every single code dependency + tooling. Otherwise they could not guarantee that they can build all of their code.
- tqi 2y agoFacebook actually doesn't use git, they use mercurial (https://graphite.dev/blog/why-facebook-doesnt-use-git https://graphite.dev/blog/why-facebook-doesnt-use-git). That decision is also illustrative of why they end up forking most things - Facebook's usage patterns at the far extreme end for almost any tool, and things thats are non-issues with fewer engineers or a smaller codebase become complete blockers.
- kridsdale3 2y agoYes when I used to talk about this to interviewees, I described that every tool people commonly use is somewhere on the Big-O curves for scaling. Most of the time we don't really care if a tool is O(n) or O(10 n) or whatever. At Meta, N tends to be hundreds of billions to hundreds of trillions. So your algorithm REALLY matters. And git has a Big-O that is worse than Mercurial, so we had to switch.
- Qshdg 2y agoLooking at some of the bureaucracy in their open source projects, I'd say that they need less tooling and more thinking. These tools help to keep spaghetti code bases from imploding totally.
- moandcompany 2y agoMy opinion: Many Meta tools and processes seem like they were created by former Googlers that sought to recreate something they previously had at Google, during the Google->FB Exodus, but also changed aspects of the tool that were annoying or diverged from their needs. This is not a bad thing. Since Bento doesn't appear to be usable by the public, aparallel version of this that people can get a feel for cross-tool integration would be Google's Colaboratory / Colab notebooks (https://colab.research.google.com/ https://colab.research.google.com/) that have many baked-in integrations driven by actual internal use (i.e. dogfooding).
- kridsdale3 2y agoAs someone from both, I confirm/support your opinion 100%.
- mark_l_watson 2y agoI agree, the paid for Pro version of Colab just seems to have the features I need. I often use it because it simply saves me time and hassles.
- baggiponte 2y agoUuuh can you tell a bit more about wasabi, the Python LSP? Saw a post years ago and been eager to see whether it’d be open sourced (or why it wouldn’t).
- KaiserPro 2y agoYou and I must be working in different areas. For any kind of general Python/C++ work, its a _massive_ pain. The integrated debugger rarely works, and its a 30 minute recompile to figure that out. The documentation for actually being efficient in build/run/test is basically "ask the old guy in the corner". You'd best hope they know and are willing to share. The code search is great! The downside is that nobody bothers to document stuff, so thats all you've got. (comments/docstrings are for weaklings apparently) You want to use a common third party library? You'd best hope its already ingested, otherwise you're going to be spending the next few days trying to get that into the codebase. (yes there are auto tools, no they don't always work.) Also, you're now on the hook to do security upgrades.
- deleted 2y ago[deleted]