I moved to California and joined FacebookThe latter was not the cause for the former. I moved to California to co-found a startup (check!), but after killing myself for three months, I decided that the combination of working on consumer software that served millions (now billions) of users and getting a stable paycheck was something I really enjoyed. Now that I was in California, there were more companies where I could do that then there were in New York City, so I shopped around a bit. After working at Google for so long and feeling like Facebook was The Enemy/technically inferior (they write PHP, right?), I never thought that I would end up there.
Fortunately, I decided to test my assumptions about Facebook by talking to engineers there who I knew and greatly respected, and I learned that they were quite happy and doing good work. Facebook in 2012 felt more like the Google that I joined in 2005 than the Google of 2012 did, so I was also excited about that. Basically, Facebook is a lot smaller than Google, yet I feel like my potential for impact (both in the company and in the world) is much larger. I attended Google I/O this year, and although I was in awe of all of the announcements during the keynote, I imagined that whatever I could do at Google would, at best, be one tiny contribution to that presentation. Personally, I found the thought of feeling so small pretty demoralizing.
Fast-forward to life at Facebook, and things are exciting and going well. "Done is better than perfect" is one of our mantras at Facebook, which encourages us to move fast, but inevitably means that there is always some amount of shit that is broken at any given time. Coming from Google, this was pretty irritating at first, but I had to acknowledge that that mentality is what helped Facebook get to where it is today. If you can be Zen about all of the imperfections, you can find motivation in all the potential impact you can have. At least that's what I try to do.
Using Outlook instead of Gmail and Google Calendar is infuriating, though.
At Facebook, there are many web developers who rely on abstractions built by the core UI Engineering (UIE) team. When I joined, my understanding was that if you wanted to be a UIE, first you needed to "pay your dues" as a web developer for at least a year so that you understood the needs of the Web frontend, and then perhaps you could be entrusted as a UIE. In general, this seems like a reasonable system, but all I was thinking was: "I made Google Calendar and Google Tasks work in IE6. I have paid my fucking dues."
Okay, so Android or iOS? I had just gotten a new iPhone after living miserably on a borrowed Nexus One for the previous six months (my 3GS only lasted 75% of the way through my contact), so the thought of doing Android development, which would require me to live with an Android phone every day again was pretty distasteful. However, my alternative was to write Objective-C (a language where you have to manage your own memory and suffers from dissociative identity disorder, as it has dual C and obj-C constructs for every programming concept) in an IDE I cannot stand (Eclipse figured out how to drag-and-drop editor tabs about a decade ago, why does XCode make organizing my windows so difficult?) on a platform that irritates me (every time the End key takes me to the end of the document instead of the end of the line, I want to shoot someone). As an Android developer, at least I could use Linux and write in Java (a language that I should probably be ashamed to admit that I enjoy, but whose effectiveness in programming in the large continues to make me a supporter).
Historically, the iPhone has always been a beloved piece of hardware (and is the device app developers flock to), whereas Android devices have been reviled (anyone remember the G1?). The same was true at Facebook when I joined: more engineers owned iPhones themselves (for a long time, it felt like the only people who owned Android phones were Google employees who had been given them for free, though obviously that has changed...), so more of them wanted to work on the iPhone app, and hence Facebook's iPhone app was a lot better than its Android app. Again, this is what made the possibility of working on Android simultaneously frustrating and intriguing: the codebase was a nightmare, but there was a huge opportunity for impact. For my own career, it was clear that I should learn at least one of Android or iOS, and Android seemed like the one where I was likely to have the most success, so that's what I went with.
But like I said, the codebase was a nightmare. What was worse was that building was a nightmare. We were using a hacked up version of the standard Ant scripts that Google provides for Android development. Like many things at Facebook, our use case is beyond the scale of ordinary use cases, so the "standard" solution does not work for us. We actually had many Ant scripts that called one another, which very few people understood. As you can imagine, developers' builds frequently got into bad states, in which case people could not build, or would do a clean build every time, which is very slow. In sum, Android development was not fun.
After dealing with this for a couple of weeks and wondering what I had gotten myself into, I said, "Guys, this is ridiculous: I am going to create a new build system. We can't keep going like this." As you can imagine, there were a lot of objections:
- "Why can't we use an existing build system like Ninja or Gradle?"
- "What happens when Google fixes its build system? Then we'll have to play catch up."
- "Would you actually support your custom build system long-term?"
- "Seriously, why do engineers always think they can build a better build system?"
At that point, I had no credibility in Android, and more importantly, no credibility at Facebook. If I decided to go against the grain and my build system was a failure, I would not have a any credibility in the future, either. On the other hand, there was no way I was going to endure life as an Android developer if I had to keep using Ant, so I forged ahead and started working on my own build system.
In about a month and a half, I built and deployed Buck, an Android build system. Builds were twice as fast, so the number of objections decreased considerably. Life at Facebook was, and continues to be, very good.
I spoke at some conferences...Thus far in 2013, I gave two external talks at conferences, two internal talks at Facebook, and one best man's speech. Public speaking really stresses me out, yet I continue to volunteer to do it. (The best man's speech was the shortest of the five, but probably the most stressful. It's a friendly audience, but expectations are high!) I used to think it was weird when I read that actors like John Malkovich often avoid ever seeing the movies that they are in, but given that I rarely watch recordings of talks I have given, I guess I can understand why. Like listening to your own voice on tape, it always seems worse to you than to anyone else.
(The title of the talk was Keeping Your Code In Check, which is not very specific to what I actually spoke about. Often, conference organizers want talk names and abstracts early in the process so they can make schedules, create programs, etc. In contrast, conference presenters want to do things at the last minute, so I supplied an amorphous title for my talk, figuring that whatever I ended up speaking about could fit the title. I'd say that it worked.)
I spent hours and hours working on this talk. I was so exhausted when I got to the end of the presentation that I botched some of the Q&A, but whatever. The slides are available online, but I always find it hard to get much from a deck alone, and watching the full video takes a long time. In the future, I hope to convert the talk into an essay that is easier (and faster) to consume.
...which included open sourcing the Android build tool that I wrote (Buck)The second conference I talk I gave was at Facebook's own mobile developer conference in New York City. As I mentioned above, the whole custom Android build system thing worked out pretty well internally, so we deemed it worthy to open source it. This conference seemed like a good vehicle in which to do so, so once we launched Facebook Home on April 4 (which I worked on!), I focused 100% on my conference talk on April 18th.
Though the presentation itself was only a small portion of what I needed to do. We had to clean up the code, excise any comments that referred to secret, internal stuff, and generate sufficient documentation so that people could actually use the thing. For once, I successfully delegated, and everything got done on time, which was great. The only downside was that I was not able to spend as much time rehearsing my talk as I would have liked, but I think that it came out okay:
Note that the title of the talk was How Facebook builds Facebook for Android, which does not mention anything about Buck or a build system at all. This is because we decided to make the open sourcing a surprise! I asked whether I should do "the big reveal" at the beginning or the end of the talk. I was advised that if I did it at at the beginning, then people would stop paying attention to me and start reading up on it on their laptops. If I did it at the end, then I would not leave myself any time to talk about Buck. So clearly, the only reasonable alternative was to "do it live," which is what I ended up doing. If you fast-forward to around 22 minutes in, you can see my "showmansip" (that term definitely deserves to be in quotes) where I get the audience to ask me to flip the switch in GitHub from private to public. It was nerve-wracking, but great fun.
I updated plovrWith so much going on professionally, and my new focus on Android, it has not left much time for plovr. This makes me sad, as the October 2012 release of plovr was downloaded over 9000 times, so that's a lot of developers' lives who could be improved by an updated release. Last month, I finally put out a new release. Part of the reason this took so long is that, in the past 18 months, Oracle dropped support for Java 6 and Google moved some of the SVN repos for Closure Tools over to Git. Both of these things broke the "turn the crank" workflow I had put in place to facilitate turning out new versions of plovr with updated versions of Closure Tools. I finally created a new workflow, and as part of that work, I moved plovr off of Google Code and onto GitHub. I have already accepted a couple of pull requests, so this seems like progress.
ChickenfootChickenfoot is the venerable end-user programming tool for customizing and automating the Web that I built as part of my Master's thesis at MIT in 2005. It was built as a Firefox extension, as Firefox gave us a unique way to make invasive modifications to a real web browser, while also providing a distribution channel to share our experimental changes with ordinary people (i.e., non-programmers). This was pretty spectacular.
The last official release of Chickenfoot (1.0.7) by MIT was in 2009, and targeted Firefox 3. As the current release of Firefox is version 23.0.1, clearly Chickenfoot 1.0.7 is a bit behind. After the NSF grant for Chickenfoot at MIT ran out (which is what effectively ended "official" development), I moved the source code to GitHub and got some help to release Chickenfoot 1.0.8, which was verified to work on Firefox 4.0-7.0. It may very well also work on Firefox 23.0.1, but I have not kept up.
Historically, we hosted Chickenfoot downloads on MIT's site (instead of Mozilla's offical Add-ons site) because we wanted to control our releases. My experience with submitting an extension to the Mozilla Add-ons site has been no better than my experience with submitting an iOS app to Apple's app store, in that a review on the vendor's end is required, and rejections are frustrating and do happen. Since we were not going to host releases on MIT's site anymore, I decided to give the Add-ons store another try. Here are the contents of the rejection letter from January 19, 2012 (emphasis is mine):
Your add-on, Chickenfoot 1.0.9, has been reviewed by an editor and did not meet the criteria for being hosted in our gallery. Reviewer: Nils Maier Comments: Your version was rejected because of the following problems: 1) This version contains binary, obfuscated or minified code. We need to review all of your source code in order to approve it. Please send the following items to email@example.com: * A link to your add-on listing. * Whether you're nominating this version for Full Review or Preliminary Review. * The source files of your add-on, either as an attachment or a link to a downloadable package. * For updates, including the source code of the previously approved version or a diff is also helpful. You can read our policies regarding source code handling here: https://addons.mozilla.org/en-US/developers/docs/policies/reviews#section-binary. 2) Your add-on uses the 'eval' function to parse JSON strings. This can be a security problem and we normally don't allow it. Please read https://developer.mozilla.org/en/Using_JSON_in_Firefox for more information about safer alternatives. 3) Your add-on uses the 'eval' function unnecessarily, which is something we normally don't accept. There are many reasons *not* to use 'eval', and also simple alternatives to using it. You can read more about it here: https://developer.mozilla.org/en/XUL_School/Appendix_C:_Avoid_using_eval_in_Add-ons 4) Your add-on creates DOM nodes from HTML strings containing unsanitized data, by assigning to innerHTML or through similar means. Aside from being inefficient, this is a major security risk. For more information, see https://developer.mozilla.org/en/XUL_School/DOM_Building_and_HTML_Insertion (All of the above is already marked by the validator as warnings. I stopped at this point; there might be more issues) Please fix them and submit again. Thank you. This version of your add-on has been disabled. You may re-request review by addressing the editor's comments and uploading a new version. To learn more about the review process, please visit https://addons.mozilla.org/developers/docs/policies/reviews#selection If you have any questions or comments on this review, please reply to this email or join #amo-editors on irc.mozilla.org
An underlying principle of Chickenfoot is to empower an end-user to be able to write a script, which we would
(This experience is what engendered my (arguably ill-advised) quip to Mike Shaver during my first week at Facebook: "I used to like Firefox." I didn't know that, prior to Facebook, Mike had been the VP of Engineering at Mozilla, but I'm pretty sure that everyone within earshot did. Awk-ward. I think we spent the next hour or two complaining about calendaring standards and timezones. We're friends now.)
Given the uphill battle of getting Chickenfoot into the Add-ons site coupled with the general need for a full-on rewrite, people sometimes ask: when are we going to port Chickenfoot to Chrome? To be honest, I am not sure whether that's possible. For starters, Chickenfoot leverages
It actually breaks my heart when I get an email from an end-user programmer who asks for a new version of Chickenfoot. Unlike a full-fledged programmer, most of these folks don't have the tools or knowledge in order to build an alternative solution. Some of them continue to run Firefox 2.0 or 3.0 just so the workflow they created around Chickenfoot still works. I would love to have a clean Chickenfoot codebase from which I could pop out an up-to-date extension, a piece of software that leverages everything I have learned about development over the past decade, but I don't have the cycles.