The Developer Support Handbook (aka How I Did My Job)

When I started at Google, I was among the first handful of people in the Developer Relations team (then called "Developer Operations"). We were new to this area at Google, but I'd say that the whole tech world was fairly new to it as well. Web APIs were just becoming a big thing, and web companies were just learning about how to support and grow the diverse community of developers using their APIs. We didn't have much of a precedent about how to do our job, so we made stuff up along the way and iterated on whatever worked. There is still experimentation going on, but much of how Google works with developers today is based on learnings from those early times (where "early" equals a mere 4 years ago - the web world moves at a rather fast pace).

As I once said on Twitter, my personal policy is to "document the f*k out of everything." I like to document things - particularly processes - both because I am forgetful and like to have a reference to remind myself how to do things, and because I am a huge believer in sharing knowledge. When you share your knowledge with the world, you potentially make someone else's life easier and you also make sure that you're not the single point-of-failure for that knowledge.

So, a few years ago, I started documenting (nearly) everything that I had learnt in doing developer support at Google, figuring that both future colleagues and even non-Googlers might be interested in the learnings. As it turns out, there was a lot in my head that I wanted to get onto paper, and the documentation turned into a multi-chapter, multi-section affair, covering topics like documentation, forum support, issue tracking, communication, and nurturing top developers. You can read it all online at developer-support-handbook.org, and if you want, you can even check out its RST source and build it using Sphinx.

I am not particularly proud of the handbook as a writing piece - I had never written anything so long before, and I found it quite difficult to keep a consistent voice and format, and to present the information succinctly. But, I do think the handbook does a good job of showing what "developer support" really entails, and gives you an idea for the kind of debates you'd face in such a role. If you only read one part of it, please read the introduction, as it outlines the guiding principles behind the recommendations in the handbook, and behind the way I did my job. (Hint: The #1 principle is to care about your developers. :)

I have since moved on from developer relations at Google, but as a developer myself, I still care deeply about how companies treat their developers and I hope to see more people talking about what it means to have well-designed APIs and to support thriving developer ecosystems. For example, Christian Heilmann put together the fantastic Developer Evangelist handbook during his time at Yahoo!, and it covers how to write great code samples and give great talks. I hope to see more writing, talks, and even conferences happening in this area in the future. Developer Relations is a tricky mix of communication and technology, and it deserves a closer look.

Sightseeing in Sydney: What to See, Eat, Drink, and Yell

When I used to live in Sydney (way back 1 month ago), I often gave sightseeing tips to visiting Googlers, and I figured I'd share some of them here:

• Visit the aquarium: There are lots of weird Aussie animals, like dugongs, sidenecked turtles, and platypi. It's a good option for a rainy day.
• Go "gold class" at the movie theater: It's a pricier ticket to sit in a special theater with a small number of plush throne-like seats and waiters that bring you drinks and snacks. It makes you feel damn special.
• Take walks: You must do the classic Bondi to Coogee walk (watch out for the cemetary on the way, & skim the waters for dolphins). But there are tons more cool walks to do around the rather long and windy coast of Sydney. I recommend taking the ferry up to Watson's Bay and following this path. It takes you past the suicide cliff, then winds through an eerie forest with huge spiders, and ends up at a cute little beach.
• Taste wine: I didn't like wine before coming to Australia, but after being properly introduced to it by the Aussies, I now love it. You should try wines in the restaurants, but you should also tour wineries. From Sydney, it is a short trip to Hunter Valley for some pretty good wines. I took this van tour with a few friends.
• Eat at the Sydney fish market: Go in the morning or at lunch, order some oysters and raw fish, and eat it outside. Warning: you must defend your food against the seagulls. They are fierce.
• Try traditional "Aussie" foods: eat something made out of kangaroo (like a burger, which is fairly common), eat wedges with sour cream & sweet chili sauce (at any pub), tim-tams (if you like sweets), oysters, and savory pies with mash and peas (most famously served at Harry's Cafe de Wheels).

Oh, and my final tip? When you see a drunk Aussie walking down the street, yell "Aussie, Aussie, Aussie" at him (pronounced "Ozzie, ozzie, ozzie"). If he's a proper Aussie, he'll respond back with a raucous "Oy, oy, oy." Works nearly every time, and it always cracks me up.

StartupBus: What I Learnt & What I Loved

I've participated & organized in many different programming events over the years, but nothing as crazy as StartupBus, an idea dreamed up by Aussie Elias Bizannes (who I met at StartupCamp, a similar event). Across the country on March 8th, a mix of developers, designers, & business dev'ers boarded buses headed to Austin, Texas. We pitched ideas on the morning of the first day, formed teams over lunch, and spent the next two days coming up with a prototype. When we arrived in Austin, just in time for the start of SXSW interactive, selected teams got to pitch their startups at the semi-finals (our team SpeakerMeter made it there!) and the finals (but not there), hoping to interest VCs in the potential success of their startups.

It was an incredible learning experience to be a part of StartupBus, and a great way to enjoy a different side of SXSW.

What I Learnt:

• It's good to go slow.

  When you say "make a startup in 48 hours", the typical reaction is "wow, that's not much time." But actually, we're really only coding the prototype, and most programming events these days are shorter than that. When you're not worried about fully working functionality or doing things "the right way", you can actually build quite a lot of functionality in that amount of time.

  So, in fact, I felt like we were going at a much more relaxed pace on the StartupBus than at typical hackathons, and I appreciated that pace. It gave us time to actually think about what we were doing, time to debate the business plan, time to have long discussions with Xero's designer Philip about the idea, and time to completely revise the interface after that discussion. It also gave us time to take more leisurely meals, where we could get to know eachother more. (Remember: we were strangers, and now we were people spending 3 days squished next to eachother on a bus. Bonding's a good thing.)

• It is difficult to make webapps without a good internet connection - for more reasons than you'd think.

  I knew that we'd be driving through uninhabited desert for most of the trip with questionable WIFI, so I tried not to propose a startups that would be too reliant on internet resources - but that's hard to do, there are few web startups these day that don't build on existing data and services. Our startup brought in Twitter and SXSW data, so we had to test that functionality at high connectivity times.

  But I realized that I use the internet for much more than just connecting code to external websites when I'm building a webapp - I use it extensively for documentation and for problem-solving. Normally, a framework question can be answered in just a few minutes with a Google search, but with flaky wifi, that seemingly quick process can take minutes on end. If I was doing this next year, I'd download all possible framework documentation to disk, and maybe also download all of stackoverflow. :)

• Market research - even the most unscientific & untargeted - can be damn useful.

When we stopped by in Santa Monica, the conductors gave us a challenge: walk around the streets and record video of at least three market research interviews with strangers. This admittedly freaked me out; I am quite shy by nature and hate to impose myself on other people - approaching strangers to ask them questions is the epitome of what I am afraid of doing. But, it's a part of the startup experience, so I grabbed my more balls-y teammate and hit the streets.

We had multiple folks turn our requests for an interview done, but we actually had just as many people stop and chat to us for several minutes. They were all university students (I guess they're all happy for an excuse to postpone doing assignments), so they were not a diverse market segment or even our target market segment, but they still gave us great insight into the design and intent of our startup. In fact, if I'd really listened closely to them, I might have pivoted the startup into an entirely university-oriented one - but I stuck with the original goal of solving my own problem, not theirs.

Now that I see the utility of just a bit of market research, I'm working on a survey to send out to our target market, and we're going to use the results of that survey to figure out our next steps. (Yes, I'm still working on our startup idea, as one of my numerous side projects.)

• There is a difference between making a webapp and making a startup.

  I love making webapps - it's so easy these days to create something out of nothing (well, where nothing = existing libraries, frameworks, and APIs), and it's easy to share your creation with the world. But a webapp alone is not a startup. A startup is a team of people trying to make a product (often a webapp) that will gain users & be profitable in some way - and those last two parts are not trivial. So we didn't just spend time on the bus coding, we also spent time marketing (tweeting & blogging), doing the market research, coming up with a business plan, and drafting our pitch.

  In retrospect, we probably could have done more of the startup stuff and less of the coding, and been more successful in terms of our visibility. It's easy for anyone to make a webapp, but it's hard for webapps to gain users that they can then be profitable from, and StartupBus is a great opportunity for potentially useful webapps to gain press and users as a result.

  I went on StartupBus partially to figure out if I want to enter the startup world, or if I am content to stay in the webapp world. I still haven't quite figured that out, but at least I'm very aware that there is a difference between them.

What I Loved:

• I am now a part of the StartupBus community - and hopefully always will be.

  The StartupBus founder, Elias, always likes to say that StartupBus is not so much about the actual startups made, but about the community that forms as result. The 3 days on the bus and 5 days at SXSW are an excuse for like-minded hackers & entepreneurs to get to know eachother over a common experience. At SXSW, even if I didn't technically know someone, I knew I could approach them if they were wearing their StartupBus badge. Now, going forward, we feel comfortable approaching each other for business advice, for a place to crash during other tech events, for co-founder possibilities, and of course, just for hanging out.

  Regardless of what I decide about the startup world, it's great to be a part of this incredibly passionate & intelligent community.

Similarity Web 2.0: Remaking My First Mashup, 5 Years Later

One fateful summer five years ago, I accidentally stumbled upon the world of Web APIs - starting with the Amazon E-Commerce API. I was supposed to be working on a research project, but I couldn't resist the potential of the API. Amazon's catalog & functionality at my fingertips? And I could do whatever I wanted with it? I just had to play with it.

So I made my very first mashup: the Similarity Web. It's an app that uses the Amazon ItemLookup & SimilarityLookup API calls to let you find a book & visualize the web of books similar to it. It was a fun little app, and it even made me some money in referrals - especially after marketing guru Seth Godin linked to the "Purple Cow" web in his blog. Unfortunately, as it happens, Amazon deprecated the version of the ECS API that I was using, and the app stopped working. It's been on my to-do list for the last few years to revive it.

Well, thanks to my former employer, I found an excuse to do just that. Google is holding a contest for free I/O tickets, and a few Fridays ago, they held the App Engine contest. After I made it through Round 1 (deploying a Fibonacci JSON-RPC service), I was presented with the Round II challenge: make an app that uses one of their more advanced APIs - blobstore, task queue, pipeline, mapper. I knew that I could use task queues in a couple different ways in Similarity Web, so at 5pm on that Friday, I started remaking it from scratch and at noon on Saturday, I submitted the fully functional remake.

Much has changed in web development in the last 5 years - both in what I personally use and what the world uses - so I thought it'd be interesting to compare the technology stack for each version of the Similarity Web.

Hosting	LiquidWeb (shared hosting)	App Engine
Backend Language	PHP	Python
Amazon API	Raw HTTP calls	Bottlenose wrapper library
Data Storage	Filesystem	Non-relational Datastore
Data Format	XML	JSON
Frontend Language	Pure JS	JS + jQuery
Visualization	Flash (AS2)	JavaScript InfoVis Toolkit

The general trend? The app is built on more scalable infrastructure, more web-friendly formats and standards, and more pre-existing libraries; it was faster to develop and works in more environments than before. Web development is getting better and better. Oh, and yes, I did get a Google I/O ticket! :)

QuizCards: Learning While You Wait

As a computer user and programmer, I find myself with many "waiting" moments - seconds at a time where I am waiting for a page to load, waiting for code to compile, waiting for an app to deploy. I usually find myself using those waiting moments to read through the latest tweets in my Twitter app - but I thought to myself the other day that there must be a better use of that time. What can I do in a few seconds that might actually benefit me, instead of filling my head with mostly noise? (Not to hate on Twitter - but I think you know what I mean.) Well, I can learn something - I can learn something that only takes a few seconds - like a word or a fact.

That idea is what led me to create the QuizCards Chrome extensions - interactive flash cards that are only a click away in your browser. When you install the extension, it sticks an icon in your Chrome browser bar (next to the wrench), and when you click that icon, a flash card pops up.

Depending on your settings, you can answer it via multiple-choice (easiest), type-in with autocomplete, or type-in with no autocomplete (hardest).

Once you answer it, it tells you if you were right or wrong, and it keeps track of your statistics for that word. Behind the scenes, it uses the Leitner card learning system for figuring out which cards to show you next, so that it quizzes you more on the cards you know the least.

There are many flash cards websites out there, but what I like about my extensions is their convenience, and their omnipresence. I don't have to remember to type in a URL, I just have to click the icon when I have a few extra moments. I feel a lot better now using my time to increase my linguistic and geographic knowledge than to increase my knowledge of tweets. And now when I do read tweets, I can spend more time to find the gems and respond to the ones that interest me.

As for the flash cards topics: I started with World Capitals, since I'm frequently called out for not knowing world geography (despite having worked on Maps for 3 years), and then made German vocab, Spanish vocab, and U.S. Capitals versions. I now have an easy way of generating flash cards for any topic, provided I can easily get the question/answer data, so let me know if there's a particular topic that you'd like to learn, QuizCards-style. (If you're technical, you can also check out the code and read the README for instructions on making your own).

You can see all of them at QuizCards.info, and install whichever interests you. Give it a go! :)

Translation Telephone: Having Fun with Language

When I was a kid, I remember we often played this game we called "Telephone" where you'd sit in a circle, whisper a sentence into someone's ear, and they would try to understand what you said and whisper it to the next person. At the end, the original person would reveal both the original sentence and the final sentence. It was funny because the sentence would often mutate and take on new meanings at different points in the circle, depending on the interpretation skills of the listeners.
Well, since that game was fun, but I am sadly no longer surrounded by willing circles of friends, I wrote an online variation called "Translation Telephone". Instead of using the interpretation skills of a circle friends, it uses the translation skills of Google Translate. After you give it a starting phrase, it translates that from one random language to another, and finally translates it back into the original language. The phrase often changes meaning into something that makes no sense or sometimes makes so much sense that it seems like a philosopher poet is underlying the system.
For example, here ae some of my favorite transformations by Translation Telephone:

• It has a new take on inspirational quotes: "Life is like a box of chocolates. You will never know what you are going to get." →
  "Life is like a box of chocolates. You know how it is."
  
• It has its own opinion on political matters: "Capitalism: God's way of determining who is smart and who is poor." →
  Capitalism: the path of God, what a smart decision that was wrong.
  
• It has as many interpretations of Shakespeare as a college English class: "To be. Or not to be. That is the question." →
  "Challenges of life and death"
  "Me. There is no question."
  "World War II, EAR ICQ, or even worse, Sam songs"
  

As you can see, the funniest results are when you enter an inspirational phrase or quote that purports an opinion, as it has its way of inversing or changing the meaning in surprising ways.
Just like in our real-life game of Telephone, there are often certain mutation points in the chain where the meaning changes more, and those points tend to be where the languages are the most different from eachother, or where they introduce words with ambiguous meanings. To make it easier for people to see where those mutations happen, I added an option to view each step translated back to the original language.
For example, I was surprised to see "You are my love" transform into "I have children", but when I viewed the translations at each step, I realized it translated Portuguese "Tenho uma querida" (I have a darling) into "Ich habe ein Baby!" (I have a baby), and "baby" has the same ambiguous meaning in German as English. Be careful who you call your baby!
I'm not the only one to come up with this idea - there's a "Bad Translator" site which translates from 10 to 50 languages, and there's also someone who did something similar with the same name on their personal blog a few years ago. I have tried to add more to this idea, however, by making every translation shareable and by letting users browse the recent and popular translations. At the request of an eager user, I've also created a Chrome extension that gives you a right click menu for translating highlighted text.
To quote a review of the extension, "Translation Telephone was already a wonderful way to waste time. Now I can do it without thinking. You've destroyed any hope I ever had of being productive in my lifetime. Thank you!"
I hope you also find Translation Telephone to be a wonderful way to waste time - and maybe a little educational too. :)

Goodbye, Google; Hello, World!

Just over four years ago, I started working in one of the coolest departments at one of the best companies on the web: Google Developer Relations. My job was to help developers be successful with our APIs, whatever it took. Sometimes that meant "grunt work" like spending hours trying to figure out why our API was broken in IE6, and sometimes that meant more glamorous things like traveling to exotic countries to talk about our API. Either way, it was time well spent when I could see the end result: developers doing awesome things with Google APIs.

It was the first and only job I've ever had, and it was the perfect job for me. I got to do so many things that I love: make things (mashups), teach people (developers) and learn things (web technology). But, as you've probably figured out from the past tense, it is no longer my job.

I could come up with many explanations for why I decided to leave Google, but it boils down to this: I'm ready for the next adventure.

What About…?

I don't want you to worry that I've left anything at Google in an abandoned state, so here's a rundown of what I've worked on and who's on it now:

• Maps API: Unbeknownst to the developers that still email me every day (even today!), I actually stopped working on the Maps API a year and a half ago. The Maps API team is now quite large and includes multiple support engineers that you'll see around the forums, like the very talented Chris and Luke.
• Wave API: Since Google decided not to continue the Wave project, the Wave APIs are effectively deprecated. Most of Wave is now open-source and is moving into the skilful hands of the Apache community.
• Shared Spaces: Along with several other former Wave team members, I helped launch this in Labs a few months ago. My colleagues will continue working on the ideas in that project and hopefully integrating the collaborative platform into other Google products.
• Google Sydney Developer Relations: When I came to Google Sydney, I was the only person working in Developer Relations here, and we didn't have much of a connection to the local developer scene. I decided to fix that by running events and meeting the developers here (who, as it turns out, are incredibly smart and sincere). There's now a whole Developer Relations crew in the office - Andrew on Go, Brett on Blogger, Nick on App Engine, Chris & Luke on Maps - and I know they'll do a great job continuing to connect with the local developers.

What's Next…?

I'm going nowhere in particular, or put another way, I'm going everywhere. I want to pursue the ideas in my head, I want to travel to the places I've never been, I want to see the people I haven't seen in years, I want to learn new things, I want to see where life takes me.

I know, I know, that's vague - but on purpose. I want to make no plans, so that I can explore all the possibilities and see what makes me the happiest. Oh, and one of those possibilities includes becoming a hippie, which totally works into the "no plans" plan.

I do have to somewhat decide on my location, since it appears that governments aren't into the "live wherever the hell you want with no paperwork or employment" idea. So for now, I will move back to the states, and likely live in San Francisco for a bit. (Yes, I'm a geek and I mapped where my friends live - based on marker density, San Francisco is the optimal place to live for maximum friend visitation.)

Thank You

There were many things I loved about my job, but the thing I loved the best was the developers. I met so many different developers doing so many different things from so many different countries. To all the developers out there, thank you for constantly inspiring and impressing me, and thank you for making my four years on this job such a fulfilling experience.

And I'm Off!

To quote the greatest comic strip of all time, "It's a magical world, Hobbes, ol' buddy… Let's go exploring!"

:)