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

81–90 of 228 posts

Re: Meta developer tools: Working at scale

#81

Post by randall »

quadrifoliate wrote: post #33
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 don't know anything about tooling at Meta, but I have appreciated custom-built tooling at all the jobs I have worked at so far -- much smaller companies ranging from about 100 to 5000 people. Some of this is just having worked in the industry for a while. Guess what, 15 years ago "Put all your code in a web service running on AWS" was not nearly as slam-dunk a proposition as it is now; and tools optimized for on-pr…

https://sapling-scm.com/

It did work out.

Re: Meta developer tools: Working at scale

#82

Post by jeffbee »

cletus wrote: post #53

I've worked for both Facebook and Google so can make informed comments on this with two exceptions: Buck2 came after I left and I'm honestly not sure what sapling is. Is it some Mercurial-like re-implementation a bit like how Google's Piper is a re-implementation of Perforce? The tl;dr is that Google's developer tooling and ifnrastructure is superior in almost every way. Examples: - When I started at FB we used Nucli…

> A lot of generated code is committed at FB that isn't at Google. This exacerbates the previous problem. FB has a ton of partially and completely generated files that mean a change to the generating code has a massive effect. At Google, for example, the protobuf generated code is genearted at build time and isn't in the repo.

What's nice about this scheme at Google is all manner of generated code is indexed, so you can navigate up and down the caller-callee graph between artisanal code and generated code. Really works well.

Re: Meta developer tools: Working at scale

#83

Post by jeffbee »

kayson wrote: post #50

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 reques…

"Contribute back to our piece of crap that is 99% antagonistic to your use case" is not realistic. No amount of third party contributions to git will relieve git of its opinions about how development workflow should be done, and those opinions are not shared with every organization.

Re: Meta developer tools: Working at scale

#84

Post by theptip »

kevinventullo wrote: post #27
typon wrote: post #22

Earlier quoted context omitted.

It's interesting to hear the contrast between Meta and my experience talking with ex-Googlers who complain that open-source or industry standard infrastructure is far inferior to what they were used to at Google. Why such a big chasm between the internal tool quality at Meta and Google?

FWIW I am a Meta-to-Google transplant and I feel the opposite way. There’s a lot of internal tooling and functionality I miss dearly. Most of all, Workplace.

I do really like Workplace, I think it provides a much better information architecture than docs/slack alone.

It’s possible to run a really disciplined Slack where updates go in a ready-only channel, and people broadcast their work appropriately - but it’s really hard. Most people default to non-discoverable DMs and then stream-of-thought in public channels, which are both bad for discovery in their own way.

Posts end up being a bit more considered than a slack message, but still lightweight, and more discoverable than docs.

Shame Google nixed their “Google plus for workplace”, I would love to see this workflow used more widely.

Re: Meta developer tools: Working at scale

#85

Post by SamuelAdams »

nicce wrote: post #32
ksec wrote: post #18

Earlier quoted context omitted.

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

… lock developers into the ecosystem and prevent them leaving, since their knowledge is not so valuable elsewhere. A bit cynical, but maybe not so unpopular opinion. Meta as business is all about locking users to the ecosystem.

Same thing applies to most government jobs. The tech is so out of date / niche that you become un-hire-able with those skills.

Re: Meta developer tools: Working at scale

#86

Post by changoplatanero »

castlecrasher2 wrote: post #51
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…

>Slack is straight up painful compared to their chat system. As someone who vastly prefers Slack over all its competitors, I'm very interested in hearing how Meta's compares. What makes it better than Slack for you?

I also think meta's workchat was better than slack. Maybe its because at my new company slack has to play the role of both workplace and workchat whereas at meta they have two separate things for that.

Re: Meta developer tools: Working at scale

#87

Post by lostmsu »

giraffe_lady wrote: post #80
phyrex wrote: post #67

Earlier quoted context omitted.

It's also doing a lot of good. It's in the nature of any broadcasting and communications platform

"drunk driving may kill a lot of people, but it also helps a lot of people get to work on time, so, it;s impossible to say if its bad or not,"

Never actually saw the skip parent post quantify harm vs good and yet.

Re: Meta developer tools: Working at scale

#88

Post by lostmsu »

ghnws wrote: post #54

The linked article has a section about IDE that this one does not touch. I was surprised they are locking them selves in to one tool with their workflow. I'm a bit worried about the dominance of VS Code. I can't stand the editor and it's popularity just grows and grows.

What are you using and why?

Re: Meta developer tools: Working at scale

#89

Post by aseipp »

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…

I'm one of the earliest GitHub users, have run FOSS projects, etc. Sapling is absolutely excellent. If anything, the 'sl web' UI alone, which can do rebases/commits, is worth giving it a shot. 'sl web' makes Git rebase look like the dark ages.

The UX just has lots and lots of polish in small ways and it has a nice amount of good features. It has fewer verbs than Git, but it's still a bit different from Mercurial. Having a built in 'undo' command that basically always works is nice.

I have replaced Git with Sapling (and a similar-but-not-the-same system, Jujutsu) in most of my own personal workflows at this time. If that's a good enough endorsement for you, then I suggest trying it out. You might be surprised.

Re: Meta developer tools: Working at scale

#90

Post by quadrifoliate »

randall wrote: post #81
quadrifoliate wrote: post #33

Earlier quoted context omitted.

I don't know anything about tooling at Meta, but I have appreciated custom-built tooling at all the jobs I have worked at so far -- much smaller companies ranging from about 100 to 5000 people. Some of this is just having worked in the industry for a while. Guess what, 15 years ago "Put all your code in a web service running on AWS" was not nearly as slam-dunk a proposition as it is now; and tools optimized for on-pr…

https://sapling-scm.com/ It did work out.

I know that, I meant the specific reasons why Sapling diverged from standard Mercurial. https://sapling-scm.com/docs/introduction/differences-hg/ lays out some of the differences; but not why they exist.

One guess that I can make from Sapling docs is that perhaps FB/Meta needed an ability to pull in Git repos where needed; and I can see Mercurial devs not being super enthusiastic about that being a first-class workflow in Mercurial itself.

Post reply on HN