Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meta developer tools: Working at scale

engineering.fb.com

Post reply on HN
Print view View original

41–50 of 228 posts

Re: Meta developer tools: Working at scale

#41

Post by wussboy »

yawnxyz wrote: post #12

This kind of stuff puts me off from wanting to work at FB. If I got really good at working with these tools (or fell in love with this tooling), I wouldn't really be able to go back to working "in the real world"

For me the barrier to working at Facebook is the fact their product is causing so much harm in our world, from elections to the environment to mental health to the breakdown of social capital.

I know I’ll be downvoted for taking an ethical rather than financial or technological position, but ethics matter. Especially in technology and finances.

Re: Meta developer tools: Working at scale

#42

Post by rangledangle »

zug_zug wrote: post #19

I think Meta's tooling is inferior to industry standard. I actually took a survey while I was there, and that wasn't the majority opinion, but frankly I think most outsiders would absolutely agree. Things like Eden were a great idea, but tools had all sorts of issues they gloss over (a virtual file system can be really slow if you have a ton of small files), dev environments would randomly fail a lot, really the only…

No company I've worked at after FB/Meta ships or works even at a non-eng level with the same velocity. I always attributed that to their internal tools, since most of the other companies seem to be using the same crap. Slack is straight up painful compared to their chat system. And don't get me started on the how good the task tool is compared to literally any other ticketing system out there. Everything is behind their intern tool, and usually built to all just work together without friction.

Re: Meta developer tools: Working at scale

#43

Post by barbazoo »

bertil wrote: post #40
zug_zug wrote: post #19

I think Meta's tooling is inferior to industry standard. I actually took a survey while I was there, and that wasn't the majority opinion, but frankly I think most outsiders would absolutely agree. Things like Eden were a great idea, but tools had all sorts of issues they gloss over (a virtual file system can be really slow if you have a ton of small files), dev environments would randomly fail a lot, really the only…

I would say it’s quite uneven: most tools were better than the state of the art when they were introduced. For many, the world has moved on a lot since, and those tools feel obsolete but so embedded in practices that it’s unthinkable to apply better approaches. One example of that is tracking data sources: legacy is slow, dysfunctional, and even fairly straightforward questions time out because you have to load so mu…

My current role for the first time exposed me to amounts of data and variety of data (in type and how/where it's stored) that's difficult to learn organically. I wonder how a FAANG does that at "scale".

> most of that information is carried by the Data engineers who have built the system, and they are over-whelmed with questions that could be answer with a good system, but derive power over analysts.

Is that the kind of question you're talking about here?

Re: Meta developer tools: Working at scale

#44

Post by alexhornby »

ink_13 wrote: post #9
blitz_skull wrote: post #4

Sapling looks quite cool! I've used git extensively in my career and consider myself as having a slightly-more-advanced-than-typical understanding of how to use it just based on conversations with colleagues. However, one thing that's always been very limiting with git has been stack-based PR reviews, and as they mentioned amending deep commits. It's not impossible, but it makes it awkward enough that I usually avoid…

Probably not, if only for reasons of inertia. Git plus third-party review tools (like GitHub) is more than "good enough" for most purposes. I used to work at FB, and while sapling is quite nice to use in practice, without the internal version of Phabricator to do code review (and, in all likelihood, mononoke), I don't think I'd pick it up again.

reviewstack adds the missing stack and versioning phab UX on top of github apis, been enjoying using it outside meta for some oss stuff, and fixed a limitation of it recently in https://reviewstack.dev/facebook/sapling/pull/656

Re: Meta developer tools: Working at scale

#45

Post by fzeindl »

zug_zug wrote: post #19

I think Meta's tooling is inferior to industry standard. I actually took a survey while I was there, and that wasn't the majority opinion, but frankly I think most outsiders would absolutely agree. Things like Eden were a great idea, but tools had all sorts of issues they gloss over (a virtual file system can be really slow if you have a ton of small files), dev environments would randomly fail a lot, really the only…

The problem with metas approach to tooling from a very high level viewpoint is that they virtualize everything. They abstract all common tasks like building, testing or running by building an entirely new system that builds an abstraction layer.

Abstraction layers tend to be slow.

What they should focus on is plumbing. Take what exists and connect it in a smart way.

Take React: the idea of applying functional programming and spitting out HTML was a great idea. HTML existed before react. Then they also implemented a virtual-DOM, which was the unnecessary part.

Or react-native: rendering UIs in a functional way is great, but stuffing JavaScript into everything is not necessary.

Re: Meta developer tools: Working at scale

#46

Post by pavlov »

rangledangle wrote: post #42
zug_zug wrote: post #19

I think Meta's tooling is inferior to industry standard. I actually took a survey while I was there, and that wasn't the majority opinion, but frankly I think most outsiders would absolutely agree. Things like Eden were a great idea, but tools had all sorts of issues they gloss over (a virtual file system can be really slow if you have a ton of small files), dev environments would randomly fail a lot, really the only…

No company I've worked at after FB/Meta ships or works even at a non-eng level with the same velocity. I always attributed that to their internal tools, since most of the other companies seem to be using the same crap. Slack is straight up painful compared to their chat system. And don't get me started on the how good the task tool is compared to literally any other ticketing system out there. Everything is behind th…

Code review on stacked diffs was awesome for bigger features.

Re: Meta developer tools: Working at scale

#47

Post by alexhornby »

arnon wrote: post #2

Surprised to see them use Phabricator (I know it came out of there, but I basically already forgot it existed) I used it briefly but couldn't get most people to adopt it widely enough.

reviewstack is the thing now, adds some parts of phab UX ontop of github apis. Been enjoying using it for oss stuff oursite meta and fixed a limitation of it recently, https://reviewstack.dev/facebook/sapling/pull/656 shows what it looks like with the versioning available

Re: Meta developer tools: Working at scale

#48

Post by RandallBrown »

fzeindl wrote: post #45
zug_zug wrote: post #19

I think Meta's tooling is inferior to industry standard. I actually took a survey while I was there, and that wasn't the majority opinion, but frankly I think most outsiders would absolutely agree. Things like Eden were a great idea, but tools had all sorts of issues they gloss over (a virtual file system can be really slow if you have a ton of small files), dev environments would randomly fail a lot, really the only…

The problem with metas approach to tooling from a very high level viewpoint is that they virtualize everything. They abstract all common tasks like building, testing or running by building an entirely new system that builds an abstraction layer. Abstraction layers tend to be slow. What they should focus on is plumbing. Take what exists and connect it in a smart way. Take React: the idea of applying functional program…

Maybe it's not necessary anymore, but wasn't the virtual DOM made for performance reasons since updating the DOM used to be really really slow?

Re: Meta developer tools: Working at scale

#49

Post by rangledangle »

pavlov wrote: post #46
rangledangle wrote: post #42

Earlier quoted context omitted.

No company I've worked at after FB/Meta ships or works even at a non-eng level with the same velocity. I always attributed that to their internal tools, since most of the other companies seem to be using the same crap. Slack is straight up painful compared to their chat system. And don't get me started on the how good the task tool is compared to literally any other ticketing system out there. Everything is behind th…

Code review on stacked diffs was awesome for bigger features.

The open-ness of code, visibility, diffs. It was perfection. Something broke in my env suddenly? OH, I just checked recently pushed diffs that affect my realm. Hey there it is, security pushed something weird. I'll just revert the part that affects me and tag them. No meeting, maybe a SEV for visibility and review, maybe not. Easy peasy.

Re: Meta developer tools: Working at scale

#50

Post by kayson »

I know git is complex, and the UX is sometimes messy, but after really, really learning it (shoutout to the Github training folks), I've never had any problems that couldn't be solved. I understand the desire to simplify some things, and their log looks way better than gits, but I wish they'd contribute back instead of rolling their own entire VCS.

The one thing that is super exciting to me is the stacked pull request support. Using Github for this kind of workflow is enormously painful. Conversations constantly get outdated, and its nearly impossible to track whether comments have been addressed.

I know they're working on an improved UX/experience there, but it seems like it'll be a good long while, especially for enterprise server customers.

Post reply on HN