June 16, 2022
Introducing the DevsInTransit series. DevsInTransit is an interview series that highlights the stories of developers who successfully transitioned into other adjacent roles (e.g devrel, tech writers, managers, e.t.c). Author bio: My name is Linda Ikecchukwu. I’m a frontend developer turned technical writer. When I’m not writing technical articles or documentation, I’m telling the stories of content creators in tech via #TechContentCreatorSeries or #DevsInTransit
For the first episode of #DevsInTransit, our guest is Dillion Megida. Dillion is currently a developer advocate at Stream and is based in the Netherlands. Before joining Stream as a developer advocate, Dillion used to be a frontend developer based in Nigeria. This is his story.
My name is Dillion Megida, and I am a Developer Advocate at Stream, based in the Netherlands. My work at Stream is basically to create content that shows developers all the fantastic things they can do with our SDKs. This content can either be articles, demos, or videos.
Asides from work, I also create content on my own platforms. I have a personal blog where I write about JavaScript, React, and tech in general. I also have a YouTube channel. On my YouTube channel, I make videos about my life, my career, the different things that have worked for me, mistakes I’ve made, and how I’ve been able to access the opportunities that I currently have.
Before moving to the Netherlands in December 2021, I was based in Kwara State, Nigeria. When I first moved here, my first challenge was the weather. Moving from an average of 30 degrees in Nigeria to an average of 1, 0, or -1 here was the biggest shock. I mean, I was told how cold it would be, yet, it was surprising. But, I have adjusted with time. Thankfully, we’re approaching summer here, so the temperature will be up to an average of 10 degrees.
The second challenge I had was food. I’ve never really been the kind of person to experiment with new food. I just stick to what I know. Luckily, I found an African store not really far from my place. I go there, get Nigerian ingredients that I’m familiar with, and cook my own meals. But, I’m also trying out some of their own food, like the sandwiches and bread (sidenote: they eat a lot of bread here :)).
My third challenge was in terms of communication with friends and family. I had to shift everything to social platforms like WhatsApp because international rates are not so friendly.
And lastly, there’s the culture. I wouldn’t call it a challenge, but it was new. Ninety percent of the people I’ve met here have been insanely generally kind to me. It was scary (but in a good way). I would always wonder if they were so generous to me because they wanted something.
One of my favorite things about this place though is the public transport system. It’s very organized. So, yeah, I’m four months here, and I’m loving it.
I had the option to either work remotely from Nigeria or move to the Netherlands. I decided to move to the Netherlands because it was an opportunity for me to try something new and experience a new perspective.
Another thing that really motivated me was that I felt like I’ll be exposed to more opportunities here than in Nigeria. I could attend more conferences and make new friends.
A year ago, I didn’t even know what dev advocacy was. However, what really made me want to leave my frontend role was that, as much as I loved frontend, I also wanted to create more content.
But, I didn’t have as many opportunities as I wanted as I am more focused on delivering updates and fixes to projects.
While searching for a role that embodied my interests, I found dev advocacy. I realized I was already unofficially doing what a developer advocate does. I still do frontend stuff in my current DevRel role, like when I’m creating a demo application, and I also get to create content — it’s truly the best of both worlds.
Yeah. While applying for these DevRel roles, I saw that different companies had different requirements. I also have a friend who is a DevRel but doesn’t like the DevRel job at his company anymore because there are just so many things he’s asked to do.
Thankfully, my company is quite a big organization. We have a marketing team that handles content, strategy, analytics, etc. Then we have eight people (me inclusive) on the DevRel team. Each DevRel person handles a different SDK platform like iOS, Android, or Swift.
For me, I handle creating content around our React SDK. So far, the content I create depends on the company’s plans and what I’m comfortable with. For example, the company’s plan might be to improve the YouTube channel, then we’ll work towards creative ideas that we can transform into videos. Other times it could be that we need more articles on a particular framework or SDK, then we focus on creative ideas that we can turn into articles.
To be honest, I didn’t use any specific resource. I mostly did a lot of research on who a DevRel is and what they do. There was this particular video that was very helpful. I also signed up for the DevRel-focused newsletter, DevRel Weekly. I went through some of their archives, and I read so many things about the DevRel industry.
In terms of technical preparation, I didn’t do so much. I already had so much frontend experience, and I was only looking for DevRel roles for frontend products.
The first stage was the introductory meeting, which is the best part of most interviews. They got to know me, and I got to ask questions about the company and its role. I also asked what I’ll be doing, if I’ll have the opportunity to create videos or just articles, and if the company was working on any fancy project. Then, they asked me questions about my content creation process.
Next, there were two technical stages. For the first technical stage, I was asked React-related questions. I was asked to present a React project of my choice, and if I didn’t have one, they would provide it for me. Thankfully, I had a React project that I had built. They went through the source code and asked me questions like: “why are you doing this?”, “Why did you not do this?”, “How did you handle authentication?” and so on.
The second technical stage was where I was actually tested on DevRel skills. They asked me to develop a creative use case for their product and then build it and write a tutorial about how I built it.
Stream mainly offers chat messaging APIs and SDKs, so I built an eCommerce application with a chat feature for a buyer and seller. Basically, when a buyer sees a product, they can initiate a conversation between them and the seller of the product. A conversation channel is created for the buyer and seller for that particular product, so they can negotiate.
I built the project with Node.JS, React, and MongoDB for the database. Then I wrote a step-by-step tutorial on how I built it. After that, I wrote a detailed readme for the project’s repository on how to set the project on your own computer. I submitted it, and they loved it.
We track page views and chat trials. We have a free and trial version of our product. When any new article is published, we track the page views, number of sessions, and the number of visitors that applied for a trial through that article. We also track the number of visitors who contact sales or fill out the contact form through those articles.
I don’t really have a direct say in that. I just come up with different ideas based on what I’m comfortable creating. I dump all these ideas on a shared doc. We have a content team they do their SEO research and find out which ideas are high in demand. They would also compare against an already written article that got a lot of traction. So, the decision lies with them. I just wait for their feedback on whether to push through with an idea or keep it in the backlog for later.
So when I have approved ideas from the content team, I share that with my manager, and I ask which I should start with. Sometimes, I get to make that decision. Other times, he decides. Once we come to an agreement, I would create a card for that idea on our notion board, where we track content that is in the pipeline. I would also provide a deadline that I think is feasible for me. Of course, my manager would still review and point out if he thinks the deadline is too short or too long.
In summary, ideas go into the idea dump, the content team and manager approve, then I create an outline. After creating an outline, I share it with the content team to get their feedback. If the outline is approved, I create the first draft. After the first draft, the article basically goes through a series of revisions till we are satisfied with the outcome. The process is the same for our videos.
For my personal work, I also have a dump page where I dump ideas as they come to my head till I’m ready to pick them up. For each idea, I state what I want to explain and maybe websites that I want to reference for further info. When I finally want to write about an idea, I go-ahead to create a draft and grammar check it with Grammarly. I sometimes use Hemingway when I feel like Grammarly did not do enough work. After that, I create cover designs with Figma, then I publish them on my website.
For videos, I start with writing a long script of things I should say and do at different points in the video. I may not have the strength to do the video on the same day. But, when I’m ready, I just follow the script and then edit.
Currently, to record my videos, I use my iPhone’s camera and a ring light. I have an iPhone 13 pro. I also have a shaw 7x microphone. I use GarageBand to record my audio. And to edit my videos, I use the paid version of Final Cut Pro.
For articles, I use VS Code if I’m writing for myself because I write in Markdown. If I’m writing for the company, I use Google Docs, so others can comment and add annotations. Then there’s Grammarly for grammar check, Figma for cover designs, and Notion for idea dumps.
One of the most important principles I tell everyone is: if you want to get better at this thing, you have to do it consistently.
Secondly, when I write anything, I try to read it from the reader’s perspective and try to identify sections that may be difficult to grasp, hence need simplification or an illustration or code block. I try to make sure that everything I write has as much context and is as straightforward as it can be. Another thing is to try not to create content for everybody. Focus on your audience. Some people will find your content helpful, and others won’t.
For videos, my most important principle is remembering that the video is secondary while the audio is primary. Your video can be nice and everything, but if the audio is not clear, then I doubt many would get the message successfully. Secondly, focus on value and not on getting people to subscribe to your channel.
So the way I do my videos, at the start, I immediately tell you what my channel is about and what I’m going to do in that particular video before I even get to ask people to subscribe. I would also mention consistency again and also experimenting. When I first started video, it was quite difficult for me. I used to record, pause, play, rinse and repeat. But now, I can go at a stretch and then cut out any part of the video that I don’t want.
As you mentioned earlier, Dev advocacy is a nuanced role. Different companies have different requirements. I would say to anybody looking to transition, build some experience in any form of Dev advocacy, be it community, written content, video content, podcasts, or open-source. And, if possible, have a basic idea of other forms. That’s what will get you hired.
For example, when I joined my company, I made it clear that writing was my domain and I wasn’t necessarily good at video creation but that it was something I was willing to get good at. Since joining, I’ve been able to create two videos for my company. You don’t really have to meet all the checkmarks of a DevRel before you can be employed. With solid experience in one domain, you’re good to go.
And that’s all from Dillion. If you want to learn more about Dillion, check out his YouTube channel or website, or reach out to him on Twitter. Till I come your way next month with a new guest for #DevsinTransit , stay jiggy!.
Recent Posts
December 17, 2024
What’s Cooking in the 29th edition of Developer Nation survey: A Letter to Our Community
See post
December 17, 2024
The Intersection of AI and APIs: How Technology Enhances Business Operations
See post
December 17, 2024
Preventing Human Error in Development: Essential Tools and Strategies for Error-Free Code
See post