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.
No comments:
Post a Comment