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

11–20 of 228 posts

Re: Meta developer tools: Working at scale

#11

Post by sluongng »

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…

Some of the recent tool started to come out to fix Git unfriendly UX.

Meta's Sapling (1) is definitely one of them. But there is also `jj` (2) and `git-branchless` (3). These tools target a smaller set of workflow where there is 1 main branch inside a big repo and everything else are short-lived branch/topic that could be treated as ephemeral stack of patches, constantly being uproot / rebase on top of the main branch to derive final result.

If that's the workflow you use daily, then you should give these tools a try.

(1): https://github.com/facebook/sapling (2): https://github.com/martinvonz/jj/ (3): https://github.com/arxanas/git-branchless

Re: Meta developer tools: Working at scale

#13

Post by epage »

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.

I used Phab at a job and it was a complete mess. Stacked Diffs only sort-of worked, CI integration was bad, notifications were so noisy everyone tuned them out, etc.

Talking with a Meta person, it sounds like Phab really needs Mercurial to work well, at least for Stacked Diffs because you need to be able to identify commits independent of their location in history to properly maintain the Stacked Diff associations.

Re: Meta developer tools: Working at scale

#14

Post by counters »

mrweasel wrote: post #6

Someone is going to read this and start to retooling their five person developer organisation because: "Facebook uses it". It's funny that the Sapling command is "sl", that's going to conflict with installations of "stream locomotive".

lol I've suffered under that before... except it was an ex-Googler forcing bazel on us, all of a 10 person dev team working on a codebase that was probably less than 15,000 LOC across three or four packages that just _had_ to be packaged into a monorepo.

Re: Meta developer tools: Working at scale

#15

Post by skizm »

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"

Most (all?) of these are open source and can be used outside of Meta infra. https://github.com/facebook/sapling

Re: Meta developer tools: Working at scale

#16

Post by voidfunc »

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"

No see, what happens is you leave then go to some other company and complain about how shitty their tools are then build a crappy half-baked version of whatever you had at $BigTechCorp and when shit hits the fan you boomerang back to $BigTechCorp for a sweet promo and raise.

Re: Meta developer tools: Working at scale

#17

Post by naru_s »

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"

What you are assuming those tools are completely unique and there aren't any open source alternatives, which is not the case

Re: Meta developer tools: Working at scale

#18

Post by ksec »

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"

Unpopular opinion.

May be this is a feature not a bug? They want to filter out some Resume-Driven developers.

Re: Meta developer tools: Working at scale

#19

Post by zug_zug »

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 tool they had that nobody disliked was their log-searching thing (can't remember what it's called) but it was still lightyears behind something likes splunk.

It was my conclusion that "Wow you have 15 people working on a dev-tool compared to a public company with 100 building the industry-standard version over 10 years with actual product managers and UI experts, no wonder ours looks like crap... wouldn't it be cheaper just to take .01% of your salary and buy standard dev tools"

I guess "Clunky" is the word I'm looking for. "Blow it away and make a new one" was a phrase that happened with some regularity for dev-envs, repo-checkouts, etc. And iirc restarting your dev box took like >30min.

---

Side note - the other strangest thing was some of these tools people agreed were terrible (restart takes 30min). So you'd expect thousands of engineers to be swarming any system with any UI bug, edge-case, or whatever. But it just didn't work that way.

Re: Meta developer tools: Working at scale

#20

Post by 000ooo000 »

counters wrote: post #14
mrweasel wrote: post #6

Someone is going to read this and start to retooling their five person developer organisation because: "Facebook uses it". It's funny that the Sapling command is "sl", that's going to conflict with installations of "stream locomotive".

lol I've suffered under that before... except it was an ex-Googler forcing bazel on us, all of a 10 person dev team working on a codebase that was probably less than 15,000 LOC across three or four packages that just _had_ to be packaged into a monorepo.

I worked with a guy who loved to use "Microsoft does it" as justification. Likewise, my suggestions such as "maybe a consistent naming convention for these components would be sensible" were met with (literally) "hmm I haven't seen MS suggest this". That was my shortest developer gig.
Post reply on HN