When I started reading Move Fast: How Facebook Builds Software from Jeff Meyerson of Software Engineering Daily, I was expecting to learn little from this book. I've kept up with Facebook engineering since 2010 and expected few new stories I've not heard before.
Still, I found myself zooming through the whole book. Even though I listened to several Software Engineering Daily episodes, the book does a much better job of distilling the stories told by guests on the podcast. The writing is crisp, easy to follow, and short enough to read several chapters in one sitting.
The book does a good job of calling out key characteristics that made Facebook successful but, unfortunately, stops here. After telling the story of how Facebook tackled a large challenge, there is often no definite takeaway or advice on how other teams, companies - or even the Facebook of today - might take on the same challenge. Despite this, would I recommend this book? Yes, to certain groups.
I recommend this book to engineering leaders (from engineering managers all the way to VPs and CTOs). Going through the journey of Facebook from 2010 to 2018, the book serves as a reference to reflect on where your organization is at, compared to the "old" and the "new" Facebook.
The book is also interesting for engineers wanting to learn more about engineering strategy or understand how the engineering practices at Facebook evolved over time.
Stories of Facebook's Past
The book is a curated collection of short stories from Facebook's early years in 2010, all the way to 2018. These stories are grouped in an easy-to-follow order and often cross-reference each other.
The book follows the narrative of Product, Culture, and Technology, as it showcases what Facebook employees thought made Facebook a deliberately successful engineering culture.
The stories are often told by a former Facebook employee. The narration made me feel like I was sitting next to them as they recalled some of their most difficult projects. Like when they realized HTML5 wouldn't scale on mobile, to when the whole company truly feared Google would crush them with Google+.
It is impressive how the author got so many ex-employees to go the record to give first-hand details about a large variety of projects. Having written books before, I'm very much aware of how challenging all of this can be.
Facebook Pivoting to Mobile, 2011-2014
Much of the book covers the biggest challenges at Facebook between 2011-2014. Facebook's pivot from HTML5 to native mobile is covered in several sections, and the book keeps circling back to this transition.
The Pivot chapter covers just how difficult Facebook found the move to the web - and the conflict between "move fast" web engineers and "we can't move fast" mobile engineers is described in detail.
The web-vs-mobile conflict an all-too-common one that I have seen and keep seeing play out all too many times and was one of the reasons I wrote Building Mobile Apps at Scale: 39 Engineering Challenges. A quote that captures this tension:
The cultural gap between Facebook’s web and mobile engineers created tensions within the company. “They came from these very different backgrounds,” says Jocelyn. “They were just talking past each other. The mobile apps had to run on eight-week release cycles, Facebook web developers wanted to move faster. The mobile engineers identified themselves as the gatekeepers against the barbarian Facebook product engineers.”
I was disappointed to see so few details on the technical challenges themselves. For example, feature flags are mentioned only once, when it was a key tool in how Facebook tackled updating the app on-the-fly. Rollout strategies, scaling manual testing, performance monitoring at scale are all not mentioned.
To be fair, going into detail would make the book harder to read and would focus less on the strategy, which is the deliberate focus of the book.
Facebook Processes to Take Note Of
The book covers some of the unique processes present within Facebook that I have still yet to see replicated at many places.
The focus on individual engineers and keeping them motivated is an open invitation for any team or company to take note. The chapter covering the challenges of doing this was probably my favorite one in the book. After all, someone needs to do the "boring" work: how do you balance with making people feel like they work on what they feel is important?
Bootcamp covers a whole chapter, and rightfully so. The concept of Bootcamp, years later, is still unique to Facebook, and there's little denying the impact it has on the culture. Still, I would have enjoyed Andrew Bosworth or Pedram Keyani - two key figures in the Bootcamp history - giving their take on it and the mechanisms they used to start and keep it running.
I liked how the book stayed grounded, stating how a program like Bootcamp only really makes sense at high-growth companies: and can do wonders at hypergrowth.
Bootcamp also addresses another issue at most companies:
With bootcamp, Facebook avoids a toxic problem that plagues many software companies: the misleading job description
Code winning arguments and the rise of the influencer engineer was a practice I have mixed feelings about. The Facebook culture does bias for action: action meaning build a prototype with code and win that argument. This is something I encourage others to follow. I'm less certain about is connecting writing code with the "influencer engineer". The book says:
Influence is built through reputation, and code commit history is an unambiguous measure of reputation.
Yes, being someone who ships code is important for a reputation among engineers. However, the book seems to oversimplify the concept of influencing. It is just as much about communication, empathy, teamwork, and helping others.
I know plenty of "influencer engineers", and I'd characterize them as highly competent engineers who are very strong team players, often humble and curious, and people who help others without reservation.
The book closes with the Technology section, covering cross-platform, release engineering, networking, frontend (React), and rethinking best practices.
The technology section was my biggest disappointment in this book, as it felt like most of this section was described on layman's terms. The book talks about how Facebook famously had no unit tests: but today, there are risk profiles created with each PR. However, it doesn't go into details or references more reading material.
It talks about speeding up mobile releases - yet barely mentions feature flags and never goes deeper on how much (or little) Facebook uses hot reloading or backend-driven UIs. It describes GraphQL: but only from a birds-eye view.
However, it was the story about the reason React was invented where I paused in reading. According to the book, React was invented out of the necessity to build an advertiser console on time for the IPO. The book says:
Facebook needed to figure out how to create a smooth experience for the advertisers. Just as Lee Byron and Nick Schrock had realized with GraphQL, Jordan Walke understood that he was encounter-
ing an engineering problem that nobody else in the industry - had been existentially threatened by. It would require a new engineering solution from scratch.
I can assume many reasons FaxJS - the predecessor to React - was a reasonable choice at the time. However, saying that leading up to the IPO, the advertising console needed a technology to be invented to ship it is just as a ridiculous claim as saying that Uber needed to move to Swift in 2016 to be able to rewrite our app.
I'm sure bringing in the FaxJS was a convenient thing to do at the time - just like Swift was a reasonable choice to make at the time - but I refuse to accept that this was a response to some existential crisis that could not have been averted, was it not for FaxJS.
The FaxJS story highlights my biggest problem with some parts of the book: it gets me interested, wanting to know more details... and then the chapter ends.
An Entertaining Read That Made Me Want More
Move Fast: How Facebook Builds Software is an easy and relatively short read: it took me two hours to go through it. However, as I was reading it, I could not shake the question: who was this book written for? The book answered this question almost at the very end, where I highlighted the following parts:
"Through this book, we tried to present Facebook through the lens of software company strategy. And we hope these lessons of strategy are useful as you proceed in your career, whether you are an engineer, a manager, an investor, or a student.
Wherever you are in your software career, it is worth studying companies’ operational strategies. It is worth understanding how strategy affects every layer of an organization. Once you understand company strategy, you can determine how to have a higher impact within your own organization."
And the book did deliver on the promise on showcasing a good part of Facebook's engineering operational strategy. The final chapter collected all the supposedly deliberate practices that made Facebook successful.
Still, as I finished the book, I could not help but wish there was more. More depth, more in-the-weeds, more failed projects, and more painful lessons learned.
Sign me up for part two.