Why I Left Parse

Monday May 18th was my last day at Parse & Facebook. At the time of my departure I was the longest tenured non-founder within Parse, so I was not surprised when people demanded why I left and where I’m going. The simple answer to both is that I left Parse because it was the only way to come back to Google.

In my post Job Satisfaction, I explained that I loved Google but left largely because I wasn’t passionate about Image Search and wanted the time I spent commuting back. In Parse I found my passion in developer tools and cloud platforms, but Facebook’s acquisition of Parse added back my commute. Parse is still a great organization and Facebook has been supportive of the team. After two years I realized I had to either move near Facebook or find another job in San Francisco.

Google reached out around this time to see if I would be interested in coming back. I wasn’t sure I would find my passion within Google, so I brainstormed a list of what I needed to be happy in my job. If you haven’t come up with such a list yourself, I highly recommend it. Honestly articulating your needs helps you be objective about whether they’re being fulfilled. The Google coordinator recommended a few teams which matched this list, and on that list was the recently acquired Firebase.

Firebase and I have a small history. They are in the same domain as Parse but have a narrower focus on data. They stand out because their database tells you when new data meets your query rather than you needing to repeatedly ask what the latest results are. I had previously helped people achieve similar results with Parse Push, but the ease with which one could use Firebase made me uncomfortable. Eventually I had to admit that I had product envy; as mentioned in Recent Talks and Reading Between the Lines, Firebase has made realtime so practical that it will soon be a commodity. Frankly, they impressed the heck out of me.

I have run into Firebase employees in the past and was struck by how nice they had been. During my Google team exploration, I agreed to meet with some team members over coffee. The more I got to know the team, the more I realized that I didn’t just respect the Firebase product, I respected the Firebase team. They are some of the friendliest and most energized people I’ve met. They were smart, grounded, and focused on building both a great technology and a great team. I’ve said before that the three most important things for job satisfaction are the product, team, and environment. In Firebase I saw a home run: I could continue my passion with a narrower focus that matched where I believe the industry is headed, I could work with a team that seems awesome by all accounts, and I can walk to the Google SF office faster than the bus to Facebook. I’m grateful for everything Parse and Facebook has meant to me over the last three years, and I’m equally excited for what this next chapter in my career will bring.

Celebrating Facebook's 10th Anniversary with Parsers Andrew Imm, Grantland Chew, and Brad Kittenbrink
Celebrating Facebook’s 10th Anniversary with Parsers Andrew Imm, Grantland Chew, and Brad Kittenbrink

Recent Talks and Reading Between the Lines

I’ve absolutely neglected this blog for the last two years. In the meantime I’ve been quite busy professionally. Some of my favorite activities in the meantime have been public speaking. I wanted to share two talks and the subtext behind them:

All About Push

Parse Developer Day 2013

Ostensibly this talk is about how to use the constellation of push notification features Parse provides. Sadly, I didn’t use Android examples because I didn’t want to show code examples which were about to be deprecated with the Android Push V2 API–something we didn’t get to release until about 17 months later.

For me, the introduction to this talk was one of the most important bits. We are in the post-desktop era, but the evolution isn’t yet complete. We first moved from big screen to small screen; applications changed because the phone is both more connected and more personal than its predecessor. But people haven’t thrown away their computers yet. Many developers focus on an Android and iOS version of their application, but I push them to think of an Android and iOS window into their application. This subtle shift in thinking better prepares developers for multi-faceted experiences. Web/desktop and native mobile applications don’t always compete; they have the potential to augment each other in a more sophisticated multi-screen experience.

Two years have passed since this talk and I think the lesson still holds true. We’re seeing some strong movements towards a multi-screen era: Apple calls this Handoff, where you can seamlessly handoff work between your iOS and OS X devices. Spotify has a great multi-screen experience–if one device is playing music, the other acts as its remote. I think this is the start of a new era where the app is much bigger than the device. I’m excited to see where this next phase in our industry’s evolution takes us.

Don’t be a Drag to Refresh

Parse Developer Meetup, Nov & Dec 2013

This was a quick 10m talk about responsiveness. I invited the audience to remember the early days of cgi_bin websites. We had chatrooms but only saw new messages after posting our own or manually refreshing the website. How is this any different than a mobile app which asks you to drag to refresh? Eventually we’re going to get tired of the cute refresh animation and realize we’ve taken several steps backwards. CRUD is great because it helps us rationalize our data and applications, but we need to do better than polling for updates. Realtime updates were once a cool feature; thanks to products like Firebase, it’s quickly becoming a commodity.

Day 1 of Google I/O 2013 Leaves me Perplexed

Android Product Strategy

Google’s Android strategy has been particularly nebulous. Android handset manufactures have been slow to adopt Android updates. Though many manufacturers promised on previous I/O stages to update devices on a well-defined schedule as part of the Handset Alliance, their motivation and commitment both faded after collecting upfront revenue form handset sales. This has fragmented the ecosystem and prohibited developers from adopting new OS features. Google has cleverly begun sidestepping this issue by packaging new features not in Android, but in the Google Play app. This seems to be a trend of turning Android into an OS “Core” while many shell and API features could be provided by Google Play instead. Though this means developers get access to new features sooner, it feels like a departure from the Android philosophy. Rather than demonstrating the definition of “open”, Android is being bifurcated into an open source core and a closed-source experience. If this sounds familiar, it’s the same strategy Apple uses to separate OS X from its open Darwin foundation. Just as Darwin is unattractive without the full OS X experience, what will future versions of Android offer without Play?

As the benefits conferred by the Play app increase, Google has more power to wield against handset manufacturers and telco operators. An Android phone simply won’t be “Android” without the Play Store app that only blessed devices provide. It is further interesting that the only way to receive features such as matchmaking and push notifications is to include an app which provides Google with a monetization channel. Google is helping developers by providing SDK updates that are easily pushed down-level, but they seem to be accomplishing this with means that feel un-Google.

Regardless of the means, the new features being added to Android are exciting. Android’s API for matchmaking and achievement management looks clean and straightforward by Android standards. I was also extremely impressed with Google that they have released this SDK for iOS as well. I cringed, however, when the speaker reached the point in his talk where these services all relied on Google+ login. Despite Larry Page’s criticism of other companies who placed economic gain before technological innovation, Google seems determined to parlay Android success on Google+. Rather than supporting an open identity model where users are free to pick their favorite provider, Google has inserted Google+ as a dependency in so many places that Android will stagnate if Google+ fails. As a supporter of the Android ideals, I hope they find a way to continue to thrive. Perhaps the keynote focus on Google+ intended to convince us that the parlay is a safe bet.

I/O Presentations

As predicted, the keynote contained a series of evolutions, but no revolutions. There were a number of great announcements; it may sound bitter, but I can’t wait to replace Eclipse with Android Studio. The redesigns of Google+ and Google Maps gave me hope that designers are finally earning their well-deserved respect and authority within Google and the improvements to Google+ image processing and Google Search assure me that Google is utilizing more of the incredible brainpower it employs. Though these were great launches, they appear to be consumer-facing products only. I am unsure how the Google+ image processing features affect any of the developer-focused audience.

Truthfully, it can be hard to keep a continued fervor for the three hours we were scheduled, and it seems like Google used the gathered audience to instead deliver product announcements to the press. I would be amiss if I didn’t emphasize that I am happy for what is being released; I am particularly curious about the GCM and gaming updates to Android. Still, I struggle to digest how I feel about the movement Google has started.

This combination of brilliant engineering and product directions that feel off has been the theme of my first day. Some talks inspire me to tirelessly incorporate better technology into Parse. Other speakers seem to believe that the world would be such a better place if we only knew REST existed and want to sell us a factory factory singleton API to abstractly access a member of a JSON payload (not kidding).

Attending I/O is like watching a sitcom about a nerdy stereotype. I want Google to succeed so badly, but I uncomfortably cringe each time they stumble and a piece in their constellation of products suffers from poor design, market fit, or muddies the overall picture by overlapping older and better Google products.

Demo Driven Development

I am a huge fan of Test Driven Development (TDD). When I think about tests before implementations, I have to understand the observable effects of a system. I systematically think about each aspect of a system, and, if I’m lucky, I will see the gotchas and dead-ends before accidentally coding them. Test driven development helps me ensure a component is properly vetted before development. It is also helped guide me to a new software methodology I call Demo Driven Development.

Demo Driven Development is designing a demo and then building the features it requires. A good demonstration doesn’t need to be convention-scale; some great demonstrations fit in 150 characters. Good demonstrations concisely articulate what a product is rather than presenting a dull list of what a product does. And a good demonstration does not happen by accident. Consider the difference between two well-engineered products: the iPod and Backbone.js.

Backbone.js is a tool which helps JavaScript developers organize code in a more maintainable way. It helps calm the wild west environment of web development. On the other hand, I frequently struggle to explain to new users what Backbone actually is. Developers unfamiliar with the MVC idiom are hard to sell. Backbone helps a developer most when a project is large; at small scale Backbone will only add complexity. Unfortunately, Backbone is best adopted when a project is small, or it will be overly burdensome to use when a project is large. Though Backbone is an impressive engineering feat, it is hard to promote due to these issues that might have been better addressed before any code was written.

The iPod was clearly designed to with its demonstration in mind. An iPod requires very little setup and guides you through the few steps necessary. Everyone knows what an iPod is; it’s a fantastically compact and simple music player. Each feature of the iPod is designed so that it is easily discovered and more easily shared with a friend. These two considerations contributed most to the virility of the ipod.

Demo Driven Development is the key to successful product. It focuses engineering efforts on the parts which sell. It equips a marketing team with a compelling pitch. And it helps a user better understand the purpose and methods of using your product. If your product is hard to demo concisely, it is not likely to succeed.

Objective-C Under the Hood

Objective-C: Under the Hood Title Slide

Recently, I was invited to speak at NSMeetup, a local meetup for Objective-C developers. Since I had recently been programming against the Objective-C runtime, I offered to give a talk on the subject. The idea took off, but it soon became clear that people were more interested in knowing how the runtime works conceptually than what its public facing APIs were. Equipped with years of systems programming experience, I decided to jump into the heart of the Objective-C runtime, which is open source. A month later, I shared what I learned.

Objective-C: Under the Hood 'Its all Just Memory' slide

The talk starts at pure C and explains what C arrays and struct access looks like in memory. From there, we discussed how to achieve the same effects without type safety. Once we are free from type safety, we build a small bag of tricks that allow us to build an object-oriented library on top of portable C. Using this bag of tricks, we can better understand the conventions that Objective-C uses to allow inheritance, polymorphism, message dispatching, method swizzling, and more.

There have been a handful of requests for my slide deck, so I transcribed the more important bits and released it as a PDF. I hope you find it useful. If you find any errors in the deck, please let me know. I’ll issue an update and give you credit in the transcript for your find.

Job Satisfaction

Dan was one of my favorite professors in college. I was fortunate enough to be one of his students in his last year teaching. He had been through industry and academia long enough to have seen just about everything. He didn’t have the strongest voice, but he always had a captive audience. He knew how to tell a good story, and he always had good stories to tell. I think it was intentional that Dan’s most indelible lessons were about career development, not software development.

Dan thought his most successful student was an alumni who managed to run an IT shop from the tropics. Unlike most students who evaluate jobs on on the trifecta of base pay, bonus, and equity; this student started from the larger question, “What do I want to do with my life?” He wanted to surf. Really. He decided to create a job where he could work remotely and he could be paid for his specialized knowledge rather than his time at a desk. With a razor sharp focus on his priorities and a waterproof pager, he spends most of his workday on a surfboard. His job isn’t his life, it’s just how he makes a living.

Most of us are not such extreme cases. I want to code; it’s what I love. But I want to be happy with my career. Dan’s advice was simple: there are three things that people need to sustain job satisfaction, and pay is not one of them. People derive job satisfaction from the quality of their coworkers, their work environment, and their project. Most people need to be happy with two of the three to feel fulfilled in their work.

I had only worked at Google for one year when I quit to join Parse. My friends and family thought I was crazy. Many pressed for an explanation how Google could be such a bad company. “It wasn’t,” I reply to a surprised audience, “Google just wasn’t the best fit right now.” My commute was one to two hours each way. I loved the technical challenges of my project, but there was no emotional sense of triumph. We joked in Image Search that our highest calling was to help men find better porn; I needed better. I enjoyed my coworkers, but that was only one of the three necessities for job satisfaction. I needed to find the crazies who really dedicated themselves to something that might change the world. I wanted to join them, and I wanted to spend more of my time on that passion instead of commuting to work.

Hello, world!

First blog posts are hard. Regular posts are the result of my inspiration–something which moved me to the point of sharing. First posts are more akin to that uncomfortable part of an interview where the candidate and the interviewer waste each other’s time on some sort of pitch. Let me get the pitch out of the way and explain who I am and why I created this blog.

I am an addict with frequent disconnects from reality. I live in a world of data diagrams, logic tables, circuit boards, and blinking lights. I tinker and solve problems. I dream audacious dreams and dedicate my life to making those dreams happen. I consider myself to be very good at what I do, but sometimes I find myself lost in my work. This is where you come in.

I learn many tips and tricks in my journey to 10,000 hours. But life has more important lessons than “always prefer a pre-increment operator over a post-increment operator;” there’s lessons like “object models which explicitly track their state machines tend to be more brittle, harder to test, and decay more quickly than other, more reactive, designs.” A tireless week of coding might give me a gut sense for one of these broader lessons, but articulating my thoughts tends to clarify them. So thank you, audience, for being my rubber duck. I thank you for participating in the post-mortem of my day-to-day career.

Musings on software development, product design, and cocktails