Ben Billings has worn many hats since coming to Facebook in 2008. He began by building internal tools to help the business run and then moved to Infrastructure, where he managed the Site Speed team for a year and a half. As of last week, Ben has made the choice to return to day-to-day coding as a software engineer on the Ads team. Read on to learn more about how his goals changed over the years and what he’s learned about balancing growth and site performance while moving fast.
Q: You moved from software engineer to manager back to engineer. What did that journey look like?
A: When I started, I was building custom tools that helped the business run, but the eventual deprecation of these tools is what allowed me to move to the Site Speed team. At that time, the manager approached me to see if I wanted to jump in and manage his team because he was also looking for something new to try. Even though I knew very little about performance, I saw this as an opportunity to learn a brand new space and meet new people. It turned out that this move actually allowed me to meet every single one of the product managers and tech leads on each of the products. I worked directly with Jay Parikh and the infrastructure management team, and it was great getting to leverage that expertise and learn how to build teams, recruit, and mentor.
Q: Why did you decide to come back to coding day-to-day?
A: I took a hard look at what I wanted to be better at a year or two years out, and realized I wanted to get back into the technology. I want to get good at JavaScript, get good at CSIs, and also leverage the fact that I’m at Facebook and the stuff that we build here is used by a number of people that’s basically unheard of anywhere else.
I really love my team and learned a ton as a manager, but if I had stayed on the management track, it would have been about more vision, more strategy, and more team building. I wasn’t sure that’s where I want to go with my career at this time, but I did know I wanted to get better at understanding our products from both a user and technology perspective. I spent quite a few years at CMU in the HCI department trying to understand how we present information to users and actually build an interface they can use. It’s exciting to now think about how we can simplify our interfaces while still keeping a lot of power in the system.
Q: How has your time as a manager made you a better engineer?
A: After a year and a half as a site performance manager, I have a fundamentally different understanding of how the Internet works. To see the entire stack of Facebook from the moment you type in www.facebook.com into your browser to the time you see News Feed, and what’s happening to actually get that content on your page, is pretty awesome. Before, I was able to build web pages, but now I love that I’m able to sit down with someone and talk through why their page is slow and drive change behind that.
Q: Coming from Site Performance, how do you think about balancing growth and performance?
A: Today’s Facebook is incredibly information dense—just look at aggregated stories and how much information we’re able to present inside the webpage from Ticker and Chat and Applications. The Facebook of three or four years ago is not the Facebook we have today, and we’re constantly having to push not only the Internet itself, but browsers, computers, and what is generally thought possible on the web. But the big question is, how do you build that and make it perform well at the same time? A lot of times this much data and interconnectivity can mean a cost in terms of performance. We have to make sure we can mitigate this cost as much as possible and make sure that using Facebook doesn’t mean waiting for pages to load and interactions to finish. Performance is a feature of a product, and without it you have a problem.
Q: What about the dev process here lets you get stuff done?
A: The speed and openness are key. The fact that we can push a regression with the knowledge that we can re-push in a couple of hours again if we need to is chaotic for a performance team, but also a blessing because we can fix things quickly. We can also go into pretty much any server or codebase we need to, which gives everyone the autonomy to solve problems efficiently.
There also isn’t code that’s forbidden at Facebook. If there’s a system that’s broken, you can go fix it. I think the ‘be bold’ portion of “Move Fast, Be Bold” is about not worrying about stepping on somebody’s toes or doing the wrong thing, but rather giving it a shot. If you’re doing the wrong thing, somebody will tell you. But you can’t be afraid to jump into something and ask stupid questions.
Q: What advice do you have for other engineers?
A: When people look for traditional engineering roles or manager roles without understanding what they really want to do, they can flounder. Facebook gives you a lot of room to decide how you want to make an impact and then go do it. We don’t coddle people, we don’t tell you what to do on a day-to-day basis; our expectation is that you get stuff done. You just have to be willing to own your career and build your own development plan by deciding what you want to get better at or what problem you want to solve. And then go make it happen however you want to make it happen. Don’t wait and ask for permission. Ask for forgiveness later.
