The Tech Content Creator Series is a monthly interview series where I chat with folks in various technical content creation roles (technical writers, documentation engineers, developer advocates, and what have you) about their careers. I hope their stories will impact, inspire, and motivate you.
For this episode, My guest was Fortune Ikechi, a Developer Relations Engineer with Storyblok. At Storyblok, one of his primary responsibilities is to document APIs and ensure developers have all the information they need to effectively use Storyblok's API. This is why I reached out to him to chat about what goes into API documentation, his transition from frontend developer to Developer Relations Engineer, and everything else in between.
Fortune's story reinforces the importance of consistently putting yourself out there and obsessing over quality delivery. I hope you enjoy it as much as I did putting it together!
Me: Hi, so tell me about yourself.
Fortune: My name is Fortune. I'm currently a developer relations engineer at Storyblok, primarily involved with the documentation engineering team. Asides from that, I also get to do a lot of demos for clients — mostly enterprise-level customers — and create content on how to use Storyblok.
Me: So, how did you get into tech? Have you always been a documentation engineer or …?
Fortune: I got into tech precisely in 2019 while pursuing my biochemistry undergraduate degree. Before then, I had attended a couple of tech meetups like Google Developer Students' Group, and I also had some acquaintances who were in tech. I began learning PHP on my phone and later received assistance to buy a laptop.
Me: What was your first gig?
Fortune: So, after learning some PHP, I went on Twitter and tweeted something like, "Hey guys, so I've been learning some PHP, and I'd really like to get my hands dirty. So, if anyone needs a job or an internship — even if it's unpaid — I'd be happy to take it on". Then this guy that was based in London reached out like, "do you know WordPress?". I replied yes. The truth is, at that point, I didn't actually know WordPress, but I'm a fast learner. I spent about 3 or 4 hours that night reading up on WordPress and how to build stuff with it. I found out that WordPress uses PHP underneath, and I was so excited.
I started working for this guy, and he paid me 25,000 naira per month. It was well worth it because I learned a lot from this guy. I was building various WordPress sites. After a while, he told me he would increase my earnings to 50,000 naira monthly, but I had to learn React. I spent four months learning JavaScript and React, and worked on some React projects.
After that four months, I decided to quit because I felt I needed more time to structure my learning and go in-depth. I felt I knew a lot of things, but I couldn't call myself a full-stack engineer or a software engineer.
Me: So, how did you get into technical writing?
Fortune: My path to technical writing was very unplanned. It happened in 2020, during covid. I was back home and was crazy depressed because I was broke. I'd already stopped working for the London guy for about six months to devote more time to my studies, and I was yet to find a new gig. I couldn't go back to the London guy to ask for my old gig.
One morning, around 4 am, I went on medium and just wrote and published this article about the story of my life: how frustrated I was, what it's been like growing up, how I've been learning tech, and everything in between. By a stroke of luck, after some weeks, someone from Smashing Magazine reached out (via a message on medium). He said he had just read my story and could see that I had the potential to be a good writer and that he would teach me how to write technical articles. But I needed to know React. I told him I already knew React. Then he told me I'd be paid $200 per article; I almost passed out from excitement. That was going to be my first time earning DOLLARZ!!!!!!!!.
We went back and forth for three weeks before settling on my first article topic: Using MobX as a state manager in React applications. And then it took another back and forth over 4 drafts for my first article to be published in Smashing Magazine! That guy was literally my angel!
People will always ask me how I got into Smashing Magazine, and I'd always say I didn't even apply. It's funny because before this guy reached out to me, I had applied countless times to Logrocket and a couple of other dev publications and was always rejected. With my article now published in Smashing Magazine, I sent the link to the head of content at Logrocket, and I was accepted as an author on Logrocket within three days.
And that's how I got started in technical writing. I just kept going from there. So many people would reach out and say, 'Wow! I read your article on Smashing, would you like to write for us?'. That's what I did for the majority of the Covid period. It wasn't until 2021 that I returned to the job market to resume coding.
Me: So, DevRel. How did that happen?
Fortune: After covid, I went back into the job market and got a job as a frontend engineer for a company based in the US. While at that job, I realized I wanted to do more than write code all day. Writing code is fun for me, but I wanted to do more. I wanted to write more about what went into the features I was building.
I started talking to people I met on Twitter, like Dillion. He was the one who told me about the DevRel niche. We spent 3 months researching the field and how we could get into it. Then we challenged ourselves that before the end of 2021, we were going to get DevRel jobs. From there, every day, we'd apply to over five DevRel jobs with personalized resumes and cover letters. It was exhausting, but we both persisted until we landed our respective DevRel jobs.
Me: So, your interview with StoryBlok. What did you do to stand out and land the job, considering you had no prior DevRel experience?
Fortune: I believe it was my knowledge and experience with writing technical articles for well-known platforms such as Smashing Magazine. On one of the calls, I said something like, "oh, I write good articles too. I have some articles published in Smashing Magazine, and here are some links to them." That piqued their interest, and they were impressed because they already had a relationship/partnership with Smashing Magazine. I also mentioned that I had community experience (I used to lead the Google developer student club at my university) and that I had spoken at a few local conferences.
So, basically, having experience with documentation helped tremendously, and even more was having experience managing communities because when I joined, I was managing the community on Discord, for a couple of months, before I moved on to focusing more on documentation cos that's my core strength.
Me: Now, let's talk about API Documentation. You talk about that a lot on Twitter. So say someone wants to learn or specialize in API Documentation. Where should they start?
Fortune: First and foremost, you should understand code. I see many people say technical writing is a non-coding field, which is pretty misleading. As an API documentation engineer, you'll probably know more about endpoints and APIs than other people in the company because you'll be like the custodian of the company's API. You can't be an excellent API documentation engineer without a basic understanding of how to write code, how developers use the APIs, and how to test-run multiple APIs.
Me: In your journey as an API documentation engineer, have there been notable resources or tools that have been of help to you?
Fortune: The API Documentation course from Tom Johnson is definitely one of the (if not the best) resources out there. The API Course by Shalvah is also good. Then there's this book, docs for developers.
Also, remember that there's no singular format for API documentation. So the format you see in these courses may not be what your company will use, but the fundamentals are still the same.
Next, learn about your users and the community. The community/users change everything. You cannot write the same API for, let's say, a FinTech community the same way you write for a SaaS community or a community of Kubernetes folks. It's just like totally different, right?
The end.