What does a developer advocate do during a time without any physical conferences or meetups to attend?
If you let social media solely inform your perspective, you probably think the role of DevRel is solely to fly to exotic locales and offer keynote addresses at tech conferences. It's the role for airline miles collectors, hotel rewards enthusiasts and airport lounge inhabitants.
The truth is that has rarely been the case.
This global pandemic has made evident that conference engagement was only the tip of the iceberg of the work of developer relations.
What then does the work of DevRel primarily entail, if not conferences and travel?
My personal DevRel mission statement is to enable developer happiness.
I am in this field because I like to make other devs happy. There are lots of ways to make developers happy. I focus in on the areas that I have capacity to effect: developer productivity and developer community.
Developers are happy as professionals when they can get their work done with clear documentation, workable and easy to understand code snippets, and tooling (like SDKs, JWT generators, etc.) that ease their work and not overcomplicate it.
Developers are happy as human beings when they feel like they have opportunities to connect meaningfully with others who share their interests, within amounts that feel satisfying and not overwhelming. Providing opt-in voluntary opportunities for social engagement can increase joy, and the Rubyist in me says most things that can increase joy are a good and worthwhile thing.
What am I doing these days to impact these two areas of developer productivity and developer community?
On the developer productivity front, I am busily engaged in two big projects.
One is converting the codebase of our documentation portal from a highly specialized and customized Rails application, into a white-listed standalone gem that can be used to deploy any documentation into its own documentation portal.
This requires a complete disambiguation of content from platform, and an abstraction of all the utilities inside the platform to be used for any documentation and its particular needs. At the end of the work, a project deploying with this gem should never need to know nor care that its underlying architecture is a Rails app. Their entire usage of the portal will be the process of installing and deploying. What is a Rails app under the hood today, could become another framework tomorrow, without impacting the usage experience.
The other project is an ongoing effort to iterate on and continually improve the experience of working with our Ruby SDKs. I want the experience from installing an SDK to getting up and running with using it to be as seamless as possible. To do that, I want our codebases to be explicit and well documented. I want the interfaces to be defined clearly, and testing of success and failure routes to be thorough.
On the developer community front, my efforts have focused even more on online avenues for community building.
One definitional understanding of community is a collection of people that have chosen to come together because of shared values and shared interests. In that vein, there are plenty of opportunities to catalyze community in that framework.
Recently, my company sponsored an international hackathon focused on building creative tools to address issues caused by the Covid-19 pandemic.
The hackathon was a chance to connect with 1,600 developers working in nearly 100 different teams. I served on the "Ideas Ambassadors" volunteer team that connected individual developers together who shared a common interest to work on to create diverse teams to build in that area.
We also launched last week a Virtual Event Space that can be used by others to create virtual online meetups at no-cost for up to 800 attendees.
On top of the above, I continue writing the tutorials and other blog posts that demonstrate use cases with our APIs.
Understandably, there has been a large spike of interest in our Programmable Video API nowadays. I am working on a sample Ruby on Rails application that leverages the video API with a blog post that explicates all of the steps to make it easier to reproduce.
An intrinsic part of DevRel in a wider company is to also engage in the ideation and planning of new features with the larger engineering teams. That work, too, does not involve any conferences or conference travel, and is rarely visible. Yet, it is so fundamentally important. I continue to do that as the Voice API specialist in the DevRel team, working closely with the product managers to help make developer experience first and foremost in the design of upcoming new features, and improvements on existing features.
I would be not entirely forthright if I said I did not miss conferences and in-person engagement.
True, my work was never focused primarily on conference travel.
Yet, maybe I am old-fashioned, but there is something that is hard to replicate without physical engagement. I may be in the minority here in this opinion. After all, I still also enjoy reading from physical books, as well!
In my view, there is something that defies concise encapsulation that occurs when people spend time together in the same physical space engaged in the same intense experience united around a shared interest. Conferences were for many of us that kind of experience.
My language advocacy has focused since I entered DevRel primarily on the Ruby community, so my view is informed by that unique experience, and Ruby conferences are indeed, unique. They are passionate. They are very community driven. They are a blend of the social and the intellectual. There is a special element to them that is hard to duplicate without them.
I do hope we return to a time where in-person engagement can resume. Not because of the travel or any the other things surrounding it, but because of that magic that happens when people gather together in common space.
However, I also hope that during this time of cessation of physical gatherings, a greater appreciation for the larger work of DevRel can be gained. The work that lies beneath the tip of the iceberg. The work that is less visible, but actually foundational and critical to the entire field.