This whole article spanned out of a Twitter thread happening over the weekend, and I felt I wasn’t doing it justice with a series of 280 character posts. I’ve also embedded the thread at the bottom of this post, so it’s easier to see the whole context in one place. A few misconceptions are floating around the internet about what a Developer Advocate does regularly, and they revolve around the glamorous life we’re having, jetting around the world daily. I thought I’d share what being a Developer Advocate is for me, and what I do and don’t do on a regular basis.

What Is a Developer Advocate Anyway?

There are a lot of definitions online if you happen to google it, and all of them differ. I’d say it depends, but then you’d probably ragequit right here. Bare with me. Most companies and products are different, and the goals for DevRel teams vary, so people doing developer advocacy in those teams have slightly different roles, with the same title. So I’ll talk about the things I know and I’ve been doing for the past few years.

I’ve been a Developer Advocate for Nexmo in this time, and my role is to be the bridge between the product teams developing the Nexmo APIs and the developers using the Nexmo APIs. Whenever we develop a new product, I’ll be “customer zero”, basically the first developer to use it in a production-like manner. It’s a 2-way bridge though, so once it’s made public, I’ll also look for feedback from the developers using the product, and bring that back to our product team, so they can improve on it.

If you’ve only clicked through to see what a developer advocate is, you can stop here, they are “the bridge between product and developers”. If you want to see how that translates into day to day work, read on.

What Does a Developer Advocate Do Every Day?

I can honestly say this is one of the most flexible jobs I’ve had (and I’ve had a few). It’s a mix of Product, Engineering, Education and Community roles. No two days are exactly the same, and on any given day I’ll do one of these things or a combination of them.

Education

This translates into creating blog posts, tutorials, documentation, workshops, and webinars around the Nexmo APIs.

As a JavaScript Developer Advocate at Nexmo, I deal with creating blog posts on how to use our APIs in conjunction with other technologies. For example, I’m currently writing a blog post on how to send and receive SMS messages with Node.js and Express.

We have a team that deals specifically with Developer Experience and the Nexmo Developer Platform, and they identify areas that need improvement there. If it’s JavaScript related, I’ll hop on one of those issues and improve our documentation. For example, the Programmable Conversations docs needed “Getting Started” guides written for all the languages it supports, so I’ve written the ones for the JavaScript Client SDK.

The getting started guides and blog posts are shorter form content but I’ll occasionally do something a bit longer like a tutorial. What’s the difference between blog posts and tutorials, you ask?. I’m glad you asked. We define them slightly differently at Nexmo. The blog posts are shorter-lived content, which doesn’t get maintenance and updates over the year. But tutorials live on our Developer Platform and get regular updates, so they’re long-lived. They may start as blog posts some times, and we’ll migrate them later on if there is enough interest from the people that read them.

Written content is not only used for our blog and documentation, but it’s also used for the live workshops and webinars we’re doing. I’ve just finished writing and then running our Nexmo Convo Workshops in Australia, and I’m working on a new workshop for our Vonage Campus event happening in San Francisco in October. If you’re in San Francisco, you should definitely join me, I’ll walk you through building talking websites.

Engineering

Not all the Developer Advocate roles have a strong engineering component to them, but you’re still writing code regularly. Why? Well, because all those blog posts, tutorials, documentation, workshops, and webinars are based on code. Code you’ll be writing. The blog posts and tutorials all need the demo apps, while workshops and webinars need example apps. What’s the difference? Well, demos usually have a shorter life span, are specific to a use case (for example “How to create your own voicemail”) and could have a third party integration in them, while example apps have a longer life span, get periodic updates and are functionality based rather than use-case based (for example “How to record an incoming call with Nexmo”).

If you’ve been paying attention, those two use the same Nexmo APIs and features, but one deals with a specific use case you can build with those features, and the other one focuses specifically on explaining how to use those features on their own.

Workshops and webinars rely on the same demo or example apps that I’m writing for the blog posts and tutorials, so I can reuse them.

Documentation also needs code, so I end up writing most of the JavaScript code snippets that go on the Nexmo Developer portal. Those are shorter examples that deal with just one particular functionality of a Nexmo API. For example, “How to record an incoming call with Nexmo”, is both a blog post and a code snippet. Where the blog post deals with everything you need to build an application that can receive an incoming phone call, and then record it, the code snippet is like a Lego block and only has the code needed to record a call, without dealing with the adjacent code needed to build a full-fledged application.

I’ve said most Developer Advocates don’t have a strong engineering component to them and deal with writing demo and example apps, not necessarily production code. I’m lucky enough that my role actually has a strong engineering component to it. The Developer Relations team at Nexmo owns and maintains the Nexmo Server SDKs, which are wrapper libraries around our APIs, so it’s easier to use them. From Go, Java, JavaScript, .NET, PHP, Python, and Ruby. When I’ve joined Nexmo I’ve inherited the Node.js SDK and I’m maintaining it, and that means I get to write production-level code every time a new feature needs to be added to the SDK.

Maybe I’m doubly lucky, but Nexmo also has a CLI written in Node.js, that we use across our documentation to help developers set up their account without having to go to our dashboard. So I maintain that as well, and because they’re used by thousands of people, I need to make sure they’re production-grade.

If you look around online, there is a pattern of Developer Advocates moving back and forth to Engineering roles, because they miss building products. I think this particular aspect of my job, developing the SDK and the CLI is what makes me not want to switch back and forth because I’m already building products as part of the role.

Product

As a bridge between Product and Community, you act as a feedback mechanism. For everyone. When Product wants to build something new, or change the way one of you APIs works, who better to reach out to than someone who’s job is to understand developers’ pain points. So I get to participate in the Product development process. That usually means looking at OpenAPI specs and trying to make them easier to read or make sure they’re easy to use. Or testing out a new product or feature, and making sure it’s something that developers want to use.

Once the product is ready for release, I also collect feedback from the people that use it. I’ll occasionally sit in while people try to use the documentation and the SDK, trying to figure out the bottlenecks and remove them, or gathering feedback on how the product is used in the wild. That doesn’t really scale well though, so you need a bigger audience. That’s where interacting with the developer community at large comes in. And how do I interact with the developer community, you ask? Well, read on!

Community

There are a few ways I get to interact with the developer community on a regular basis. My favorite one (and if you ask my boss he’s probably the least happy about it) is speaking at conferences and meetups. I have a variety of topics I speak about, from non-Nexmo related ones (Hands-on Performance Debugging), where I talk about the things I’ve recently done in the broader JavaScript world, to Nexmo-adjacent ones (How I built a talking website) where I talk about the things I’ve built recently, and those usually involve a Nexmo component because I spend a lot of time building things with Nexmo. The Developer Relations people at Nexmo don’t do product pitches on stage, but other Developer Advocates will do product pitches as well, depending on the audience and the event.

One of the other ways I interact with our community is by sponsoring events and manning the Nexmo booth. I get to tell people all about Nexmo if they haven’t used it before or listen to their feedback if they have. And you know, hand out T-Shirts and stickers like they’re candy 😅. In all honesty, this is probably one of the more draining activities from the #devrellife, there’s a lot of things that happen behind the scenes, from preparing the materials to use at the booth (event page, survey, demos), to physically getting there before everyone else to set up the booth and then pack it all up at the end. It involves a lot of work, and I don’t do this alone, usually there’s a few of us from Nexmo sharing the work and being present on the day at the booth. The slightly sarcastic twitter thread about how a day of sponsoring a conference looks like is what prompted this whole article.

These are just the tip of the iceberg though as most interactions with the community don’t happen in person at events. I interact with people trying to use our APIs a fair bit on StackOverflow, Twitter, and the Nexmo Community Slack. It’s usually the same scenario, someone is having an issue with following along one of the pieces of content we’ve published, or they’re trying to build something with Nexmo and they haven’t read up on all the documentation available, so I’ll nudge them in the right direction, or answer questions about our APIs. This is probably one of the most time-consuming things I do, mainly because it’s async, and it involves debugging other people’s code, code I don’t actually get to see. So it means a lot of hypothetical solutions, seeing a lot of code snippets, and trying to figure out all the possible ways it could be wrong.

What About Those Misconceptions?

If you still don’t know what a what a Developer Advocate does on a regular basis, let me at least tell you what I don’t do.

The most common misconception about the #devrellife is that we get to jet around the world from conference to conference, traveling and living in style, because everything is paid for by the company. It could be so, but it isn’t. And let me tell you why: it’s simple math. You have a set budget every year. The less you spend on one thing, the more things you can do. Some developer relations programs are big enough and lucky enough that they can actually fly business class if the flight is over a certain number of hours. But most developer relations programs out there don’t have that kind of policy so everybody flies economy.

At Nexmo, we’re lucky enough that we can upgrade to Premium Economy if the flight is over 6 hours, and we can ask for business if we do back to back events or if we feel like we need to. Let me be clear, we’re not asked to do these things, family and health come first. But most of us choose to do more for our communities, and choose to fly the cheapest logical option, most times with budget airlines. The reason is simple, instead of flying business, we can sponsor that extra community conference this year, or host one more meetup every month. And we do that because at the end of the day, helping enable those communities to gather in person (most of which wouldn’t be able to without sponsors), heavily outweighs us being slightly more comfortable for those 6 hours.

As for the “living in style and luxury hotels” part, the same as we have a certain budget for flights, we have a daily limit for hotels as well. That is nowhere near enough for the luxury hotels. I for one don’t care for those fancy hotels anyway. I just don’t feel comfortable in them, and I don’t really have the time to enjoy the amenities like “spa day” and “golf club”. A hotel provides a simple function, and that’s a place to sleep. I have a few simple rules I use to choose my hotels, be it for traveling for work or holiday: above 8 on booking.com, as close to the venue as possible, preferably with a treadmill or gym. And that gives me enough options to choose from, I end up usually going with IHG because they’re the cheapest options.

“OK, you don’t travel and live in style, but you get to see the world”. Yes, I do. I’ve seen about 20 airports and 30 hotels this year. And the bus/taxi/train rides in between them. Even if you do get to a new city, it’s not like you have the day off to go exploring. You’ve still got a job to do, and most of the time I end up in a coffee shop with good wifi either close to the hotel or close to the airport. Learning to navigate a new city every month gets exhausting after a while, so I try to minimize the interaction as much as possible. If you do happen to have some free time in the evening, because there’s no conference function to go to, you just end up crashing in the hotel room and Skyping your loved ones.

So Why Do I Do This? Why Am I a Developer Advocate?

It’s definitely not for the “glamorous” life, or for all the “fame” and “glory”. I’m doing all this because I genuinely like to help people! And I could honestly say I’ve helped at least one person every day! I really care about the developer community, “making developers’ life easier” is not just a marketing gimmick for me. Despite being sarcastic on Twitter, I’ll gladly do this all again tomorrow, and I’m going to enjoy every moment of it. I love helping people and this is the most rewarding job I’ve ever had (and I’ve had a few).

If you find yourself thinking “I wish I could do this as well”, well, you can!. I’m more than happy to help - you can find me on Twitter, and my DMs are always open. I also co-curate a weekly newsletter with Julia called “Developer Avocados 🥑 Weekly”, full of resources geared towards helping you become a (better) Developer Avocado 🥑, give it a read. If you’ve read this article and think “I wish I could join you”, well, that’s possible as well, Nexmo is hiring for a bunch of roles in the Developer Relations team, take a look at the open roles or DM me about it.