Why invest in Tools?

Why invest in Tools.
A few days ago at the React-europe meeting I shared graphql, a project I had been working on Facebook for more than three years.
After this conversation, several participants at this meeting asked my Facebook how to consistently produce new technologies and "rethink current Best Practices", which has succeeded in changing the way we build software as an industry.
This is a react meeting, let's start here ...
Graphic: Lasmousse Anderson
When it started open 2 years ago, react was ridiculed by the JavaScript community, and many people (myself included) thought it was a bad idea within the first few months of Facebook. Jordan Walke was stubborn in all the proper ways, and his idealism finally had an impact. We thought he was crazy, he was crazy, but he was right at the same time on something. React has changed the way we create software on all platforms. Adam Enster (Adam Ernst) borrowed these ideas and created Componentkit for iOS, which was skeptical of our internal iOS team on its first appearance. It also dramatically changes the way we build iOS software.
React and Componentkit started by a single individual and were not required to do so. In fact, these projects began with a direct opposition to their engineering team at the time of inertia. React directly challenges the other JavaScript frameworks we use. Componentkit began to evolve like other internal iOS-built UI frameworks that are ready to use. There's nothing wrong with the other tools, they're not bad (actually good), but they're not perfect either. They have different trade-offs, strengths and weaknesses. A better tool for their work may exist when an engineer thinks there is and only they are allowed to create tools.
Based on my experience with Facebook, experiments like this are not only permissible, but also encouraged. They are risky, and like these ideas are often not exciting and will fail. But sometimes you get react, Componentkit, HHVM, GRAPHQL, immutable.js, flow, POPs, or Asyncdisplaykit. The risk is worth it. One of the benefits of Facebook's growing up as a huge engineering organization is that we have the ability to allow talented engineers to take on such risks rather than strictly adhering to a scrum timetable or the company's top-line short-term goals.
Each of the projects I have just mentioned faces considerable internal opposition. There will always be people (sometimes I) want a project that admits failure earlier. However, they are still continuing. Facebook has a project management philosophy and a great engineering manager who knows how important people are to believe in themselves. Despite the opposition from trusted colleagues who have not yet understood its value, and despite the more important things to do, the best managers in Facebook trust their own people to take risks and spend their own time on things they think will find an impact.
My team, the product infrastructure team, and most of the Facebook team have a common idea that the engineering impact will not stop at the company's products. The list of projects is open source, and each of them has a strong community, and each has some notable effects on the way people think and software development across the industry. Open source is not just a charitable ideal, it is an important part of how we learn and demonstrate the impact of our work desire.
Healthy open source is also extremely powerful for recruiting. I interviewed dozens of people and they told me that they began to focus on Facebook after seeing React,asyncdisplaykit,pop and other projects they wanted to participate in. This makes intelligent people in and the virtuous circle continues.
Success is not an isolated discovery. As the project becomes exciting, the potential is seen by others, and the team constitutes-point-to-point or otherwise-and the snowballing effect helps push the project. On Facebook, projects that work outside the main job responsibilities are not uncommon, or are quickly moving between teams, allowing this snowball effect to occur. It also means that there are a lot of unsung heroes behind these projects.
For graphql I want to point out some (but far from all) who have had a meaningful effect early on except the original team Nick Schrock (Nick schrock), Daniel Cheves (Daniel Schafer) and myself.
Bohatshoen (Beau Hartshorne) is a real catalyst for GRAPHQL. He found and clarified the problem, found the right person, and inspired us to find a solution. Sometimes it's hard to get rid of blinders trees, but Bo (Beau) is a rare person and he is always able to see the forest.
Jonathan Dann (Jonathan dann) and David Renie, two iOS engineers, are the supporters of our rough graphql early versions and they have done a lot of work to integrate them into iOS news subscriptions. They also helped build some of the important infrastructure that we continue to use today, and they provide subscriptions for future blog posts.
Lasmousse Anderson (Rasmus Andersson) was the first to look at our client Software Development Kit in a new light, and he imagined the flow of data between mobile applications in a different way. This is the foundation of our Andr OID SDK, and some of these ideas give relay inspiration, a tool that uses GRAPHQL to build the web.
Other GRAPHQL Team alumni, Nathaniel Nierroma (Nathaniel Roman) and Charlesma (Charles Ma), were early members of our team and helped launch the client tools that later became GRAPHQL.
Scott Wolchok (Scott Wolchok) has independently organized and improved the GRAPHQL iOS data model and subsequent client tools across all platforms. His critical vision inspired us to investigate recent crosscutting improvements.
Today, more and more teams support and invest in GRAPHQL, server, client tools and Facebook type systems.
Facebook is able to consistently generate new technologies, "reflect on current best practices" and generate huge waves in the industry as we focus on producing long-term value. We take risks. We believe our people do what they think is right, and when things can be potential, smart people across the team come together.
Our job is not just to build Facebook, but our job is to make the world more open and connected-and the task of our product infrastructure is to get the tools of the software industry to help us accomplish this mission.