At Facebook, our engineers collaborate to create an open environment where ideas win and are executed quickly. Each week, our engineers will give you a look into what it’s like to ideate and build at Facebook in our new “Meet a Facebook Engineer” Q&A series. Check back weekly to hear from different engineers about what problems they’re passionate about solving right now, what they’re up to at Facebook and what advice they have for you.
Q: What problem are you most proud of solving at Facebook?
A: The search typeahead backend makes a pretty good war story: We built the personalized, prefix-searchable, synchronous real-time updatable, large-scale search engine that powers the search box on Facebook.com. We invented some cool data structures for the index along the way, which you can learn more about from a tech talk I did here.
That said, nothing I’ve worked on has gone from 100% “unsolved” to 100% “solved.” Real software is an organism. Even if you’re writing new code it has some genetic relationship to other problems, and even when you’re done you know the solution could be improved.
Q: What problem are you most passionate about solving right now?
A: Making PHP both fast and interactive. Right now, PHP developers have a “Sophie’s Choice” between a high-performance compiled environment (Facebook’s HipHop compiler) and a high-productivity interpreted one. A bunch of us on the HipHop team have been working on the HipHop Virtual Machine, a just-in-time execution environment that combines high performance with the interactivity that makes PHP productive.
Q: What does a typical day look like for you?
A: I ride my bike into work and sit down at my desk in the HipHop team’s pod for some coding. I keep an earlier schedule than most of my colleagues, so morning is my best shot at a multi-hour stretch of uninterrupted coding. As other folks arrive, they fill me in on what they discovered yesterday evening after I left, and I let them know what has been going on in the morning. The second half of the day is reserved for communication: chasing down issues that developers using HHVM are hitting, reviewing code that other engineers produced, fixing issues in my diffs that reviews uncovered, technical discussions, etc. The fun part, obviously, is those hours in the morning producing software with my bare hands. You need everything else, but it’s all life-support for the actual coding.
Q: Why do you come to work in the morning?
A: In broad strokes, I find Facebook’s vision for the future of technology uplifting and worthy of hard work. More specific to my work, I think making “developer productivity” languages (PHP, Python, JavaScript, etc.) efficient is one of the most important tasks we systems people can apply ourselves to right now. Programmers using these languages get more done (yes, really), but there are some tasks that are beyond these languages’ reach today due to performance problems. If we can narrow the performance gap to statically typed languages, all of humanity will benefit because programmers will be able to solve a wider range of problems more quickly than they can today.
Q: What advice do you have for engineers?
A: Take more risks. Through historical accident (we call ourselves “engineers,” even though the analogy between software and engineering projects is limited) and temperamental self-selection (you need a big perfectionistic streak to get good at software), most software engineers’ technical instincts are way, way too conservative. We are afraid of taking risks and are numb to the benefits of trying something new and exotic that might have a large payoff. Culturally, many of us think of the software that guides a Mars lander, or the control rods of a nuclear power plant, as an ideal to strive toward (zero defects!), instead of a strange outlier in the landscape of trade-offs. Unless human lives are on the line, quality is one of the dimensions along which you must trade-off; those near-zero defect rates come at the cost of modest ambitions for what the software actually does, and huge amounts of time and treasure. Imperfect software systems still provide value to their users, and you’re kidding yourself if you think you can perfect the system by working on it for another six months before releasing it. So you probably owe six more months of useful software to your users, even if they notice some bugs.
