Thread by @schrockn

3.1/ FB v GOOG:
Jeff asks about the FB/GOOG culture comparison which is a common theme in the whole series. My/Pete’s thesis: Facebook’s engineering values are better suited for the vast majority (but not all) of startups building cloud-based consumer- and business-facing apps

3.2/ First of all downstream from founder personalities/experiences. Google founded by academics/PhD’s. Facebook founded by college dropouts. Early team and early hires also in the same cohort for the most part.

3.3/ Second downstream of initial/core product. Google is a text box and a list, backed by incredibly sophisticated infrastructure. Product has a very narrow, stable surface area.

3.4/ Facebook nearly the opposite. Product surface area very wide and chaotic. Lots of interrelated concepts that change all the time. In this way, most business apps and consumer apps are much more like Facebook’s core product than Google’s.

3.5/ GraphQL

I go through the full story of GraphQL, which I won’t tweet about here. But a few takeaways: GraphQL was the easiest sell ever in the company. It spread quickly.

3.6/ Huge thing is that was a tool (GraphiQL) that demonstrated the value and principles of the tech. We didn’t even need to explain it. Just sit a product dev down, have them start typing, and things pop up and they can get data. It was magical.

3.7/ It actually spread too quickly. It was a problem. We made a bunch of mistakes and mistakes were magnified because it was too hard to claw them back. Some of FBs mobile tech liabilities even today -- especially on Android -- stem from mistakes in this period.

3.8/ A lot of these problems weren’t really resolved until @leeb led the incredible redesign of the system leading up to its open source launch in summer of 2015. If you want to learn about his process recommend:

3.9/ Lee had a bold strategy: Write a spec. It was very un-Facebooky. I was super skeptical that anyone would read it, let alone implement it. Boy was I wrong.

3.10/ The spec was a great opportunity to formalize our messaging and evangelism. And writing things down thoughtfully is incredibly leverage. All of a sudden people are showing up on YouTube echoing your arguments. It’s surreal. Also very effective.

3.11/ A couple takeaways: Sometimes it’s very appropriate to step back and be deliberate and formal. Don’t underestimate external developers and OSS communities: They’ll do hard things and do work if it is interesting and has value.

3.12/ Challenging Orthodoxy: The PR that killed MVC at Facebook. I love this story so I’m going to tell it here.

3.13/ FB has been pretty good at challenging orthodoxy. A lot of those battles occurred in the PHP codebase between 2008-2012. JSX came from XHP in the PHP codebase. We didn’t use a traditional ORM. This story is about Model View separation.

3.14/ The whole story is worth a listen. At the time (2010) FB was strict about having UI code and data fetching code in separate files. This was conventional wisdom.

3.15/ An intern (@zrait) and a returning intern (@bmaurer) decided that this was silly. The argument is straightforward: In order to render data you have to fetch it. It’s coupled. It’s self-evidently coupled. Figure out a good way to couple it. Don't pretend it is not.

3.16/ Every senior engineer (myself included) weighed in saying how it was a bad idea. “Please schedule a meeting”. That kind of crap. They persisted. And one by one they were able to convince people re: their approach. I’m very proud that I was one the earliest to turn. :-)

3.17/ Within a few months all new product code was being written using this strategy, and the approach has lived on. Relay and Apollo Client in the GraphQL space have adopted this. It all can be traced back to the interns telling the “senior” engineers how things should work.

That's it! Lots of other stuff in that podcast but I think those are the high/most general points.