This connection, whether taken as a priority or not is Developer Relations.

In simpler terms, Developer Relations is everything that's done to make it easier for developers to use a product, acquire new skills or be a part of a community - relationship with developers.

Pick your favourite developer facing companies and think of how they have tried to make it easier for you to use their product and you'd realise that it all falls into developer relations.

A practical example

For us as part of the Developer Relations team at Flutterwave, we are often focused on creating and improving resources. This could include libraries, SDKS, articles and documentation etc for developers to easily use our APIs.

We maintain a line of communication with members of the general community that use us through providing support and also taking feedback to the actual team that builds the products and can make the changes needed.

What does the role look like?

The role is different in many companies and can be pretty broad. Some companies consider Developer Relations as developer marketing so that would also influence how the role is perceived.

In most cases, there is usually a team called the Developer Relations team and in there, you could have:

• Developer Advocates: People focused mostly on public speaking, technical writing, documentation and other advocacy tasks. Can also include engineering and more.

• Developer Experience Engineers: They can also be advocates but they work more on building tools like the SDKS and libraries and may not be as visible as the advocates.

• Integration Engineers: This could be called anything but it's mostly people that are simply focused on direct support of engineers that want to integrate a platform or use a product.

This is not an exhaustive list (See title) but it's a nice place to start from. The Developer relations team serve as a bridge that connects the product to the rest of the developer community.

Getting into the role

I usually recommend that anyone looking to get into this role should have a few years of experience working as a developer. It's the easiest way to be able to understand how to communicate with and understand issues other developers are having. If you have this experience, you are more comfortable diving into unknown territory and also growing into the role.

I also recommend starting advocacy on your own. If you want to get into this role, a great way to start is to start working on it in your own capacity. Are there products you use regularly or are interested in? Talk about them, write about them, help other developers out with them, share your experience and if possible build tools leveraging on the platform that can help other developers.

With this step, you are able to identify which aspect of Developer Relations actually stands out with you and you can double down on honing that skill.

PS: I'm looking to generally assist or provide a platform for people to be able to get into this role. I sent out a tweet to this effect and I'm looking forward to connecting with people that are looking to get into the role. It's also great that other people experienced in the role are also offering assistance so check out the thread.

Hard things about the role.

In complete honesty, one thing I particularly struggle with in this role is metrics. And it doesn't help that this role varies from one company to another so in most cases, you have to be creative and intentional about the metrics that determine success for your own company.

You could also have to constantly prove to management and the rest of the company the effect of the work you do on the constant growth of the product and why your team is important.

One way I've tried to address this myself is to read about other people's experiences, speak with other advocates and take ideas from what has worked in other places. A few people I spoke to or looked at for help at various times include:

• Aaron Gustafson - Web standards & Accessibility advocate at Microsoft
• Alex Lakatos - Developer Relations Manager at Fidel API
• Christian Nwamba - Senior Advocate at Microsoft
• Sarah Drasner - VP of Developer Experience at Netlify
• Ada Nduka Oyom - Developer Relations (SSA) at Google
• Nathaniel Okenwa - Developer Evangelist at Twilio
• Prosper Otemuyiwa - Developer Advocate and Co-founder, Eden

To succeed here, you also have to be willing to network and learn.

My personal experience.

I started my journey by helping developers out in communities like DevCenter Square. I realised it was something I enjoyed and it did help me learn more about tools I used. With time, a lot of people would see my work or reach out to me for help.

A few years later, I got recommended to Ingressive as someone that could work with Developers to help grow adoption and use of GitHub in Nigeria at the time. And that was my first formal entry into Developer Relations and Advocacy.

From there, I'm currently at Flutterwave where I started as a Developer Advocate but currently working as a Frontend Engineer and Developer Experience Engineer - you learn more about yourself as you continue in the role. 😬

Conclusion

As mentioned, this role varies across companies, so I implore you to keep an open mind. And if you're already in Developer Relations, I'd love if you could also help share your experience and support other people trying to get into the role.

Here's a platform showcasing Developer Advocates you should check out as well. https://avocados.dev/

I have decided to use this platform to share some of the "subjective" opinions and practices I follow or have followed in the past in my journey as a software engineer.

I hope we get to learn from one another, share experiences and have conversations around these practices and techniques.

For this article, I'll be going about the steps I take when trying to bring a small idea to live in the form of a side project. I'm assuming a lot of people have different approaches but I'd be outlining mine here.

Step 1 - Ideation

At this step, the light bulb just turned on, and I had just gone "What if...?". This is when the first version of the idea pops into my head, and you see me staring into the clouds trying to picture how this could come out.

At this step I often come up with a name instantly and pen just the name down to my todo list on Microsoft Todo.

I used to use Todoist but Aaron introduced me to Microsoft's Todo and it's been great but you can use any tool of your choice.

Step 2 - Outline

At this step, I document my thoughts as it comes to me on the overall purpose and flow of the application. Steps users need to take, resources I need to get some things done - this may include third party APIs and even use cases that the project may apply.

Below is an example of these steps for a recent side project called - CleanRepos.

Step 3 - Build and Deployment.

Not much to say here, this is where actual development is done following all the things already outlined. At this stage, I already know what I intend to do and what I need to do it.

Step 4 - Promote.

For your work to speak for you, you need to give the work an audience. This is important for the project to get the visibility that it needs.

I struggle with this recently, but it's important to shamelessly promote your project so that it can accomplish what you set out to achieve with it. Share on your social network and among friends.

Following all these steps, the next things is usually moving on to the next project or focusing on maintenance.

Throughout my adventures, I've had to make choices on tools, technologies and platforms I use to have my ideas come to life. Here they are:

Ideation

* Todoist

Once an idea comes through my mind, no matter how unstructured it is, it usually comes with a default name to call it, this name can be changed later, but it helps me quickly add it to Todoist as a project to work on with a short description. I used to use Trello for this. Before coming up with CleanRepos, the idea came with a "Repo Deleter" tag.

* Dropbox Paper

Paper comes in really handy for pretty much everything these days - writing articles and also writing out thoughts. Once I am ready to dive deeper into an idea I have, I open a blank Paper page and start typing how I picture it to work, the flow, technologies and resources I'll need and also a basic idea of what pages should be available.

Local Environment

For a long time, most of my career actually, I have just preferred to go the easy way out when it comes to setting up my local dev environment. I've tried a lot of tools as needed but I've mostly settled with using a stack. I am currently on Mac so I went with MAMP but now trying out Valet.

Version Control

Everybody uses Git... no? I used to use Bitbucket when there were no private repositories on GitHub but now, GitHub for everything. Public and private.

Domain names

For a long time I used Maddogdomains for my domain name management and I still have a couple domains there. But now, I have moved to Namecheap and they are my go-to.

Hosting

I don't do much of shared hosting anymore. When I used to, I used QServers and Gigalayer for clients. Moved to Azure because of BizSpark benefits but that's exhausted now. I use Heroku (free) for my quick deployments and then DigitalOcean (paid) when needed.

Platforms I've built for

• Web
• Windows
• Android
• iOS
• FirefoxOS
• Windows Phone
• WordPress Plugin
• Browser extension - Chrome & Opera

I'll continue to update these with different sections as I come across them and if you need me to clarify any section especially those not mentioned here, feel free to drop a comment.