From Python to Technical Writing: A Cloud-Native Documentation Journey with Michael Uzukwu

Speaker A: In all this I found what I call, uh, should I say maybe I would say my calling because I enjoyed it. While I was writing I was breaking down complex technical terms, making it clear, making it actionable, I found enjoyment in it. So uh, that was why I continued and I've never looked back.

Speaker B: How do you think AI will change open source documentation?

Speaker A: AI has even changed the way documentation is designed, documentation is consumed, documentation is used. This question is vast and it's been around a front burner in so many forums, so many discussions now, now I say that because AI for me as a technical writer, uh, I see AI as uh, just a tool. Don't wait until you have all the skills in the world. Do not think that having all the skills in the world maybe trying to be ready and all those stuff like that. No, I just feel that anybody that is interested in making an impact, just go ahead, start and do something.

Speaker C: Welcome to the Knowledge Based Ninjas podcast where Gauri Ramkumar of document360 finds the best SaaS self service knowledge bases in the world world and then interviews their creators. Let's get started with today's episode.

Speaker B: Good day everyone. Welcome to Knowledge Based Ninjas podcast. With me today we've got Michael Uzuku, technical writer and software documentation engineer at Armtech, um, Nigeria Enterprises. Hi Michael, welcome to the podcast. How are you doing?

Speaker A: Hi Gauri, I'm fine. I'm very, very happy and good to be here to chat and to talk about uh, the topics that are uh, dear to me and um, that I'm passionate about. So I'm very, very happy to be here to talk to you and um, to everyone at large. So thank you for having me.

Speaker B: Thank you for spending your time with us Michael. And um, yeah, just to highlight seven plus years in this technical writing space is not a joke. So we just wanted to maybe dig a little bit deeper into how you got into this as uh, your career. Ah, who's your inspiration or. Yeah, just tell me a little bit about your background Michael.

Speaker A: I would say going into technical writing it was not so linear like some other persons would uh, maybe in their own journey some other persons, they, they just had clear mindsets, clear vision and, and where they wanted to go, clear direction. But I, I didn't have that probably because I'm kind of a person with some so much interest, you know. So I didn't just go straight into technical writing. By the time I finished college I had some interest. So I started out as uh, just a Python programmer. So I, I learned the basics, I Started with the basics of Python, just learning the syntax, you know, the data structures and all that. So but at a time then in Nigeria here there was a time when there was, there was um, so much talk about data analytics, data science and stuff like that. So I had a little bit of interest about it. So I looked at, I started using Python to solve some little problems like retrieving data, um, through web scraping and also maybe using an APIs to retrieve data. So and then I also looked at, I also looked at things like using some Python libraries like um, Pandas, Non PI just to you know, um, analyze data. But in all that it wasn't, I wasn't. So um, I wasn't enjoying it. I should use that word. I wasn't really enjoying it. So I had to uh, should I say transit. But the transition didn't just happen like that. I found myself more of um, writing about my Python, my data science projects, data analytics projects. I would write how, what the project is about, the steps I took, also some of the results and the conclusion. And that was how I kept on documenting my data analytics projects. Even some of the repos are there on GitHub so you can even find some of these things I'm talking about on my GitHub repo, how I documented my data projects. So even before then, right in college I uh, had taken up positions like if, you know, press club in colleges where they write editorials, they communicate about what is happening in the society, in the school. So taking up uh, writing, should I say assignments task in my college and I rose up to be uh, the chief editor in my press club in, in college, that is Kateville International High School then. So if you, if you watch, I had these um, communication instincts and interest already even before I finished college. So um, I would say somebody that actually now opened my eyes sometimes you could have some of these skills and uh, you may not know, but somebody around you can maybe try to, you know, influence you. So I would say I'll credit that to my other brother who is a uh, DevOps engineer. So he, he always knew I could write. He always knew that I do write. He tells me that I do write better than him. I could explain things. So he said to me one day, why, why don't you go into technical writing? I asked what is technical writing? So he explained. And then I, okay, then, and then I started writing. I started with Google Analytics, Google Technical writing course. Then I went into this um, technical writing mentorship program for structured API, um, technical writing skill course and also the uh, product documentation where I learned about, should I say a little bit about open source documentation about docs as uh, code workflows, kids and GitHub operations and all that. I even led a team of learners then I would say we are all learners then colleagues then into, should I say a project, although it is, it was fictional then as we are learning, but I happen to lead that team and we did that uh, amazing job and that job came out fed overall uh, in that a mentorship program. So from there the interest continued to build. But in all this I found what I would call, should I say maybe I would say my calling. Because I enjoyed it. While I was writing I was breaking down complex ah, technical terms, making it clear, making it actionable. I found enjoyment in it.

Speaker B: So.

Speaker A: And that was why I continued and I've never looked back.

Speaker B: Absolutely. What a great way of uh, explaining how your career path nicely shifted from one direction to another and as you mentioned, your career transition journey. I'm also curious to understand what skills from data analytics helped you most in technical writing.

Speaker A: Yes, this is, this is a very, very um, wonderful question because most times some people do not actually know that just because you're a software engineer or you are into cyber security and then you, you cannot translate some skills from that into other aspects, other technical aspects. So that actually helped me a lot in, in data analytics I did, I used libraries like I said, like a, uh, Pandas, non PI matplotlib. These libraries, what they do is that I tend to structure data. You have messy data, you have to clean this data up, make them actionable, make them clean, structure them in a way that you can derive insights and do your analysis. So that also translates into technical writing. When you are writing a technical writer, most times would be interfacing with um, um, I will call them product managers and uh, subject matter experts. These product managers and subject, subject matter experts, they are like the ones that own these projects, what we call the engineers or the brain behind the project. So a technical writer will more or less be working closely with the SMEs, I.e. subject matter experts and project managers. So you have a whole lot of information around you. But that information, you have to know how to now structure it, structure it clearly so that users can understand, can adopt it. And that is where what we call um, information architecture comes into play. But when you look at information architecture is all about structure, organizing. So the knowledge and the skill from data, ah, in terms of organizing data, uh, structuring data, uh, actually helped me a whole lot in knowing, in dealing with information architecture, breaking down, arranging these technical terms into logical flow. You know, most products now you, you come across, you will see things like after the HERO homepage, M, you see things like um, the overview or introduction, you will see a quick start, you will see maybe core concepts of the, of the products. You will see tutorials and advanced topics of a documentation. So this is how structure comes into play. Another thing, another skill is about attention to detail. You know, you know that in, in data as well. One single mistake, a single mistake in data where you don't put the correct data, you don't apply the correct rules or the correct formulas can actually hamper the result of a particular data analysis. So that also translates into documentation in that you have to make sure that when you test, you test systems and these systems, they do work and you make sure that these things are well documented. So like I said, learning structure and also attention to detail. These skills, M, I come across them and I use them in data analysis and also in documentation.

Speaker B: Got it, Got it. Now everybody's talking about uh, AI but my question slightly is um, what makes a cloud native documentation structure fundamentally different from other documentation? So what should a, as a user, how should they be prepared?

Speaker A: Okay, I would say fundamentally, I would say the main difference from what I've seen is in the target audience. Now yes, I say that because documentation, the sole purpose of documentation is to explain the product, a tool so that users can adopt, can understand clearly and make use of these products to also get to their end point. So but when you talk about cloud native documentation, we are looking at the users now, the end users in cloud native documentation, most of the target audience are ah, usually. Well the SRO is platform engineers, architecture engineers. So it's quite different. These platform engineers and architecture engineers, they are already part of the ecosystem. What I mean by already part of the ecosystem is that in terms of the ecosystem in cloud native tooling they already understand the basics. So uh, in that aspect the way you write for these audiences will be quite different from the way you write for say maybe just a normal developer. Because these persons already understand things like kubernetes, they understand things like clusters, you understand things like pods. So that is on a different level. The language you use, the language in documentation for cloud native tools is quite different from normal product tools. So I would say that is one fundamental ah, uh, should I say difference there? Another thing I would point out is the ever changing, should I say um, tooling in cloud native systems system or a tool like Kubernetes they usually dish out or they release, uh, give new releases almost every year. So in this uh, um, industry when it comes to cloud native tools, you have to constantly keep learning, keep adding more, more tools and more skills, skill set to yourself. So that is where I see the distinction between cloud native documentation and just the normal technical writing and for normal software, um, products.

Speaker B: Very nice, very nice. Now um, how do you think AI will change uh, open source documentation?

Speaker A: In fact I would go ahead to see that AI has even changed the way documentation is designed. Documentation is consumed, documentation is used. Not just how it will, it has already changed. It. Yeah, it has already changed. I, I have to say because the discussions around this particular uh, this question is, is, is vast and is, is been around the front burner in so many forums, so many discussions. Now, now I say that because AI for me as a technical writer, uh, I see AI as uh, just a tool. You know, I think that so many technical writers would, would look at AI as a tool and not um, something that will replace technical writers. Most technical writers are afraid or some persons are ah, afraid that AI is coming to take the jobs of technical writers. But in my own opinion I would say that is not the case. AI is here, but it is here as a tool. And um, technical writers need to embrace AI as well. So when I say embrace AI, it is coming and it has given that leverage for technical writers to use it as a tool. In terms of repetitive tasks. When you talk about first drafts, when you talk about first making your first draft, looking at things that are not working, AI can help you to do that. But there is a problem. We all know that AI can uh, hallucinate a whole lot. When we say hallucinates, AI can give in fake information and make it so true with confidence. So AI has uh, come and what, what it helps to do in documentation is that so many repetitive tasks that we would need to spend time to do will not leave AI to do that. AI can also serve as uh, an assistant. Yes. And also there's what we call retrieval augmented generations now I don't know if you have heard of that. That is AI agents now crawling documentation. So this has to do with how documentation is also designed. In this day and time going forward, I think industries and product managers that know what AI is capable of, capable of doing, they do structure their documentation knowing in mind that there are so many AI agents now that are being deployed that help to crawl information from the Internet. So in that I mean that when you are designing documentation, for instance you have to put that in mind because in this day and time, developers, developers now the shift. There is now a shift in the way that developers use documentation and, and the way they code and the way they do their work. Traditionally what developers do is that they, they look at documentation, they learn about a particular step, they go and implement. But this time around what they do is that they don't just look at the documentation to learn, they prompt AI for AI to give them codes. Do you get the point? Now this, what is, what is AI agent do is that when a prompt is given, the AI searches so many documentation about that specific topic and begins to pull out this information for that user. That is what it does. Now if your documentation is not structured in a way that AI can pull information in your documentation, then the information and the prompt will not work. So AI has changed the way we structure our documentation because we now have AI agents everywhere that pull documentation. This information when prompt is given. Also the second aspect is that uh, there is um, this aspect of repetitive task. Now AI can generate drafts, AI can do so many repetitive tasks. Just like I mentioned before, AI can check for incomplete documentation. But there is a caveat here. In all these humans, the human being is still the chief validator. We should not replace the place of human beings because like I've said, AI can hallucinate a lot. So human beings, after all said and done, we human beings, the engineers, the documentation engineers, we must also be there to validate. If not we may run into problem with having AI, uh, uh, contents and docs work that are incorrect. So I would say that AI, there is a whole lot of influence of AI in documentation at this time. So. Yeah, and it will continue like that.

Speaker B: Yeah, that's very, very detailed Michael. Thank you for that. Um, my um, last question before the rapid fire round is uh, can you help us understand what exactly an LFX mentorship is? Uh, because this is something new I saw in your profile and I thought let's have a chat about it and um, yeah, just help us understand what does that mean please.

Speaker A: Okay, so the LFX mentorship is Linux foundation mentorship. So it's uh, a collaboration between Linux foundation and Cloud Native Computing foundation that is LFX cncf. Now what the LFX mentorship result is is about contributors and maintenance having the opportunity to contribute to real world documentation projects that is sponsored by Linux foundation in conjunction with Cloud Native Computing Foundation. So uh, contributors to Open Source have this opportunity to work on these projects. These projects are uh, real world Project. They are real projects and LFX and CNCF do sponsor these projects. They do pay stipends to mentees and mentees do apply to this project and they get selected, haven't done review of the application. Just like any other job, um, application would, should I say go through and then once you're selected you have the opportunity to work on these very very exciting projects. Just like I applied for the one on K Gateway and I got selected for the project on documentation improvements with Open ID Connect and JSON Web Tokens integrations with K Gateway. It's just documentation surrounding the whole security documentation of K Gateway. So this is actually a very good way to learn without so much pressure on real world projects. Without so much pressure. I want to emphasize the word so much pressure because most times new, should I say techies or documentation engineers or writers, they are, they are faced with these pressures of having a real world project. But this is a mentorship that is well structured and without much pressure you could work, learn the most important thing there is for you to learn a whole lot. So and that is what it is. I've been contributing for K Gateway for some time and I was lucky to be selected this time around.

Speaker B: So yeah, nice, thank you. That uh, that's something that I really wanted to have a chat and that now gives us a good ah, perspective. Can we move to the rapid fire round questions please?

Speaker A: Yes, yes, yes, I would be happy to hear.

Speaker B: Good, good. By the way you spoke and a very detailed explanation for every single question I asked. I'm sure you must be reading a number of documentation resources. Um, so anything that you would like to recommend to our uh, audiences, Michael, at this point?

Speaker A: Okay, yes, yes, actually I, I would say first of all it is good for maybe upcoming. Not just upcoming, anybody involved in documentation technical writing. There is this platform. I don't know if you know about Write the Docs. There's Write the Docs. Yeah, just called. Right, the Docs. And um, I happen to be there in their Slack channel. So we can. Anybody can go to their Slack channel and look for Write the Docs. And in that, in the Slack channel the you can learn about conferences, new um, directions and tooling in technical writing. You can also learn about um, upcoming events in technical writing. There's also a place where you can also search for jobs as well. But the most important thing is that people do post about blogs, technical writing blogs, technical ideas in technical writing, new technology, new ways of writing, of communicating, of doing things. So I think that is a good Resource a good platform for not just upcoming technical writers, but anyone that want to grow within a community having like minds and discussion. So that is one of them. The second one, if somebody is interested in cloud native tooling and documentation would be the Kubernetes Slack Kubernetes group, the documentation about Kubernetes. So if anybody wants to go into documenting cloud native tools, I would recommend first of all going to the kubernetes documentation. The reference docs go through there. You, you would understand what kubernetes is about, about how to use, configure clusters, how to use, you know what clusters, about what ports are, uh, all about and all that. So so many information because most of the cloud native tools, whether you talk about kg, you talk about linker, you talk about volcano, they are all built on Kubernetes. So you must understand Kubernetes, how to host kubernetes, how to configure it, how to deploy it, to be able to document. Because once you don't understand these tools, you may not be able to document them. So these would be my recommendations.

Speaker B: Yeah, nice. Um, so one word that comes to your mind when you hear documentation.

Speaker A: So I would say clarity. For me, clarity, so important.

Speaker B: Now a piece of advice you would give to your 20 year old self.

Speaker A: Okay, I would say, you know there's this, which, there's this thing about young persons thinking that maybe they have to start at a particular level, maybe they have to go to a particular level before they think that they can make impact. So if any 20 year old is, will be watching this podcast, I would say don't wait until you have all the skills in the world. Do not think that having all the skills in the world maybe trying to be ready and all those stuff like that. No, I just feel that anybody that's interested in making an impact, just go ahead, start and do something. And also the second thing I would say is always try to write, just keep writing some. And um, when you keep writing, some of the things you may write may not be the way you structure them. Your language may not be too correct. But in writing you now developed, you develop this actual sense, this uh, cognitive sense of now having that writing, should I say habits, the writing habit and communication in general. So I would say just write, communicate as much as you can. Give your thoughts, whatever you're thinking about, write them, put them out there for people to see. Some of them may not be correct. You would find people that want to say, okay, this is not correct, do it like this and um, do it like this, but that's fine. But you staying back and saying maybe I'm not ready, I'm, um, not good for this, that is not the way to go. So I would say just go ahead and do something. You may not know what is coming up.

Speaker B: Very, very well said, Michael. Thank you for wonderful answers to all the questions I, I had for you today that I missed to ask you that you would like to share with our audiences.

Speaker A: Well, I would say that not much. I would just say anybody going into documentation is not making a mistake, especially documentation engineering. It is not a mistake. It looks so simple when they talk about documentation. It looks so simple. Maybe I would even add maybe ordinary to some persons. Some persons want to hear about the software engineers, the DevOps engineers. But when you actually look at it, documentation and technical writers, they actually play very, very important role to that product, that software and all that. So if you're thinking that maybe this is not, maybe you have it, you have passion for it, but you're thinking that it is not so popular or it doesn't have so much prestige, I would like to say no, that is not the case. You would actually make it. Should I say make a good career from technical writing? The, the, the, the main thing you have to do here is you just have to be good at what you do. So yeah, in summary, I would say technical writing and documentation engineering is a good career for someone that want to break into take.

Speaker B: So yeah, thank you, that's really, really wonderful. And um, all I can do now is wish you all the very best for your future projects. I personally learned quite a bit from this call today. And uh, yeah, all the very best. And uh, good luck.

Speaker A: Yeah, once again, thank you for having me and probably I look forward to having this discussion again some other time if there's the opportunity. So.

Speaker B: Sure, Michael, take care.

Speaker A: Thank you very much. Thank you. Bye.

Speaker C: Thanks for listening to today's episode of the Knowledge Based Ninjas podcast. Please head to iTunes Rate and provide honest feedback on the podcast. See you next week.