Facebook Developers with Nick Schrock
Podcast: Play in new window | Download
Subscribe: RSS
When Facebook was scaling in its early years, the company developed engineering practices that were unlike any other organization before it.
Early Facebook engineering developed unusual practices because the problem set was unusual. Facebook was a highly detailed, highly interactive, multi-user web application. Facebook was pushing the limits of PHP and JavaScript in a time when there were not simple frameworks to help with user interface development and data fetching.
In addition to unique engineering problems, the Facebook product itself was also unique. When a product has as much traction as Facebook did in the early days, how are you supposed to manage the direction of that product?
Should you double down on the core competency of the product, and make it as good as possible at simply connecting friends to each other? Or should you rapidly expand into adjacent systems like messaging, groups, and photos? How should you allocate developer resources when you have problems to be solved at every layer of the stack, from backend infrastructure to frontend performance?
At a typical company, you would put all these engineering problems and product opportunities into some kind of project management software and assign developers to work on them, and gradually make steady, measured progress. The downside of that approach is that it slows down the pace of product creation and experimentation, and turns software development into a top-down, bureaucratic process.
At Facebook, developers self-assembled into teams that did what needed to be done. The engineers who were the most productive and charismatic could quickly build a reputation for themselves and become technical leaders. These “influencer engineers” within Facebook had a proven track record, and would become magnets for other engineers who wanted to contribute to the projects with the most momentum.
Facebook is a case study in the ability for developers to self-organize into groups who are working on projects that are meaningful to the company and personally satisfying to the individual engineers. Many engineers in the software industry work under a less capable manager who has complete control over their creativity. This leads to employee churn, dissatisfaction, and burnout.
Facebook’s ability to move fast is predicated on its ability to match engineers with problems that are interesting to those particular individuals. Whether you want to work on newsfeed or developer productivity tools or machine learning research, there is a path within Facebook to finding a problem that is both important and fun.
Facebook’s unique set of engineering challenges required the company to develop a unique set of internal tools. Because Facebook had data and throughput requirements which were unprecedented, the available tools and best practices at the time did not satisfy Facebook’s requirements. Over the years, Facebook has developed its own databases, caching strategies, and JavaScript frameworks.
Nick Schrock worked at Facebook for eight years. He is best known as a co-creator of GraphQL, a tool for efficiently fetching data through a federated request language. GraphQL was the result of years of evolution of internal tooling within Facebook.
Nick has discussed the creation of GraphQL in other podcasts, and we will have a more dedicated episode around a retrospective of GraphQL in the near future. Today’s episode is about the process by which developers at Facebook self-organized, and Nick’s ideas around how to identify a need for an internal tool.
Since leaving Facebook, Nick has parlayed his experience in developer tools into Dagster, a programming model for data applications.
RECENT UPDATES:
The FindCollabs Podcast is out!
Transcript
Transcript provided by We Edit Podcasts. Software Engineering Daily listeners can go to weeditpodcasts.com/sed to get 20% off the first two months of audio editing and transcription services. Thanks to We Edit Podcasts for partnering with SE Daily. Please click here to view this show’s transcript.
