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

221–228 of 228 posts

Re: Meta developer tools: Working at scale

#221

Post by Spooky23 »

rsdbdr203 wrote: post #197
Spooky23 wrote: post #123

Earlier quoted context omitted.

Splunk can save money, as long as you’re intelligent about processing data. I can think of dozens of security and operational incidents where splunk saved the day. I’ve been through a few savings exercises where everything is gonna go open source dashboards etc. Once the guy who understands how it all works disappears, it migrates back to splunk. One security incident response will pay for the entire splunk infrastru…

This isn't a great argument... sure, Splunk "saved the day" because it caught that really bad security thing... but what other tools, at half the cost, could have also "saved the day"? If most of them could have, then it's not really worth the price... right?

Sure. I can save a ton of money by fixing my own car too - if I have the ability to execute.

If you can, that seriously awesome. The point is, many can’t.

Re: Meta developer tools: Working at scale

#222

Post by ghnws »

lostmsu wrote: post #88
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?

IntelliJ. To name a few features I've not been able to get in VS Code or have had a worse experience: - debugger

- refactoring (extracting functions and variables, renaming across entire project etc.)

- context aware selection (expand selection from cursor logically)

- stack trace / error parsing

- comparing anything (diff selection with clipboard for example)

- DB schema support even in SQL formatted as strings (e.g. when using psycopg) directly from DB by just connecting to a DB

- find in files (I've never seen a VS code user have an easy time finding stuff)

Etc.

Re: Meta developer tools: Working at scale

#223

Post by rangledangle »

ben_w wrote: post #218
rangledangle wrote: post #142

Earlier quoted context omitted.

Most of the open source Ai things are Meta. React, GraphQL, pytorch, rocksdb, docusaurus, prophet, a whole ton of internal tools that aren’t public knowledge. Full disclosure I haven’t worked there since 2019 though, so not sure since then.

None of that looks like it's about the Facebook website itself? But I guess that implies you didn't mean the website itself when you wrote "FB" in the comment I replied to? :) (One of the most well known consumer brands shipping tooling rather than stuff the consumers use directly is, ah, apt for a company called "meta").

When I worked there it was still called Facebook. I’m still not used to calling it Meta haha. My bad.

Re: Meta developer tools: Working at scale

#224

Post by no_wizard »

rangledangle wrote: post #182
no_wizard wrote: post #177

Earlier quoted context omitted.

Its not the tools, its the culture. Meta cut red tape in its early years especially. I know there is more "process" now, but they empowered teams and individuals to just make decisions and move on and the ecosystem around everything supports this. They'd be just as fast with Slack or whatever, for the most part. EDIT: as someone posted below: > The open-ness of code, visibility, diffs. It was perfection. Something br…

100% agree. The culture is a huge factor as well, but in some of the environments that I encountered before and after, that culture was there, but the tools didn’t allow the same cohesion. To your point, other experiences have shown me the ego that rears it’s ugly head when trying to move that way in an env that didn’t have that culture. At FB there was a lot of candor, but in other environments I feel like I’m going…

In part this is only possible at Meta because it incremental measured improvements would raise all boats. You didn't have someone being evaulated how well a project was planned (Product Managers), how well it was executed (Engineering Managers) and how well it was built (Engineers / IC). All 3 of these things can be extremely orthogonal to each other and human nature makes it so more often than good intentions of a person to even realizes.

Meta cut through that by focusing on measurable improvements.

The downside is it can create silos, a negatively competitive environment. IE, teams not sharing resources or credit etc because they are only looking out for themselves at the end of the day, because any measurement you don't capture is one you can't claim as yours.

I also argue it can breed short therm thinking. Meta even had special teams from what I understand that were "exempt" from the typical metrics driven review cycles because they'd create the wrong incentives.

I think the general ethos can be really powerful though, but I'd peg it to collaboration and value driven measurements (and value is loose here, I'm not strictly thinking monetary) rather than strict "user based metrics".

Re: Meta developer tools: Working at scale

#225

Post by seemethere »

cletus wrote: post #125
aseipp wrote: post #95

Earlier quoted context omitted.

Buck2 is IMO much better than even Bazel is from a design POV, because it actually cleanly separates all user rules from the build engine, and has a coherent modern design around a sound theoretical basis. Neil, one of the leads and author of this post, has written many build systems, so it's not like he's unaware of Bazel; his taxonomy of build systems and ones like Bazel in "Build Systems a la Carte" is worth readi…

I hope Buck2 is better. Like I said, I have no experience with it. My issue is more organizational. Meta, as a company, in my experience, does not put in sufficient investment to build a mature, robust open source project with few exceptions. Even things like the www test infra, which are core to the company when I was there had ~1 FTE SWE. That's not open source but you get my point. Buck (and Thrift) seem to have b…

What about pytorch?

Re: Meta developer tools: Working at scale

#226

Post by HumanOstrich »

c_crank wrote: post #186
HumanOstrich wrote: post #180

Earlier quoted context omitted.

Can you provide some specific examples?

The token system used instead of passwords now was horribly explained. I had to look at several online resources to figure out how to actually use it. I've noticed that the system seems to repeatedly throttle me where it never did before. Logging in often results in being given an error until I try it enough times. Sometimes attempting to pull recent changes from a repo will fail, and tell me that I pulled the recent…

Thanks for the clarification.

I agree with you on the token system. It was a pain to figure out.

I've actually run into issues with throttling and stale fetches before, but it was due to a company proxy intercepting all requests. So effectively our entire org was hitting GitHub through a small number of proxy gateway IPs. Happened with AWS APIs too -- major throttling issues with terraform that seemed to be triggered based on the shared IPs.

Might be a longshot, but I'd check to make sure you aren't going through some proxy or VPN because I don't think your experience is typical.

Re: Meta developer tools: Working at scale

#227

Post by morgannewman »

jonathankoren wrote: post #114
TechBro8615 wrote: post #100

Earlier quoted context omitted.

Also keep in mind they've been in hypergrowth mode since 2010 or earlier. Regardless of whether Git is the clear solution today, it definitely wasn't at that time. So it makes sense they invested in building their own tooling.

And now it's 2023, and they're inventing the wheel again.

[dead]

Re: Meta developer tools: Working at scale

#228

Post by quadrifoliate »

martinvonz wrote: post #217
ak67 wrote: post #213

Earlier quoted context omitted.

> I know that, I meant the specific reasons why Sapling diverged from standard Mercurial The needs of a large internal code base are often quite different than what open source projects need. Anther issue is that tools like Git and Mercurial need to be compatible with positively ancient repositories and can't really break backwards compatibility whereas within Meta, it is easier to move faster and deal with breaking…

> Finally, Google is also moving away from Mercurial. Perhaps the JJ developers want to respond why (and check out Jujitsu -- it's a novel and very interesting system y'all should check out). Sure. I presented about that at Git Merge 2022. https://github.com/martinvonz/jj#disclaimer has links to the slides and the recording from there. I'll summarize the problems we have with Mercurial here: 1. Performance/scalabilit…

(A bit late, but better than never) Hey thanks, this is exactly the sort of detail I was looking for -- appreciate the link and clear reply!
Post reply on HN