Kube Cuddle

Rich: Welcome to Kube Cuddle, a podcast about Kubernetes and the people who build and use it. I'm your host, Rich Burroughs. Today I'm speaking with Divya Mohan. Divya is a Technical Writer at SUSE. Welcome.

Divya: So glad that we got this chance to catch up. Rich. Thank you so much for welcoming me on.

Rich: I'm really happy to have you here. You know, I've been, um, kind of aware of you for a little while now, through Twitter and then we met at KubeCon Valencia really briefly. Yeah. And I've just been, um, really impressed by the things you're doing for the community. So, um, really happy to have you on to talk about it.

Divya: Thank you. You very kind.

Rich: So, um, I was looking at your LinkedIn and I saw that you started off originally as like a systems engineer and then a systems administrator. And that was kind of my background as well. I started off like, as a system administrator, um, a lot longer ago than you did, but, but I feel like that's a really good, solid background for somebody to kind of get into this cloud native world and especially to deal with Kubernetes in terms of like the kinds of things that you learn and, and have to do in those

Divya: Absolutely. I think, um, my background is what set me up for success in the cloud native world. And I genuinely attribute a lot of my, um, knowledge to, uh, what I laid as. I mean, it was not I who laid the foundation, but my, you know, job that laid the foundation, um, of, the various basics, whether it be networking, whether it be all Linux fundamentals, whether it be, um, even, uh, stuff like, um, you know, the common commands that we use in Linux, which typically a lot of folks who get started do, do not, you know, seem to be aware of.

I mean, I'm not, you know, throwing shade at anyone here, but it typically takes a longer curve for developers to get onboarded to Kubernetes, because they're trying to work on code and I'm not again, no, no throwing shade at anyone here, but, uh, it typically takes a longer onboarding curve for them. Uh, so I I'm really glad I started out with systems because it really helped me, um, grasp things better.

So it was easy for me to sort of, um, like in Kubernetes to a lot of things that I'd already learned and patch that in my mind and make it easier for me to learn. So yeah, I, I completely attributed to the solid foundation that my initial, uh, roles laid. And of course, I don't think, um, I would have been here had those, um, you know, foundational, um, elements, not being this strong, so yeah.

Rich: Yeah. I, I feel like, uh, I mean, this is something that I've been kind of concerned about.

I really wonder about people who are coming in like right now and there're learning Kubernetes, or they're learning about cloud native stuff, and they don't necessarily have that lower level background, you know, with like some of those Linux primitives, like storage and networking and things like that. Is, is that something that you're kind of hearing about in the community?

Do you think that's something that's going

Divya: Yeah. And I think a lot of our, uh, you know, a lot of my fellow, um, con I wouldn't call myself a content creator because I just blog. I cannot, you know, for the life of me.

Rich: You, you just blog

Divya: Just blog. Uh, but I can't for the life

Rich: That's, that's a lot more than a lot of us do,

Divya: I can't for the life of me sit, uh, sit and, you know, um, uh, create a video and, you know, do all the stuff that a lot of y'all do.

And I completely appreciate your patience and your tolerance for the craft. I am really not that patient, but, uh, I think that's a lot of the, uh, you know, a lot of our fellow content creators are trying to address that, uh, with the kind of content that they put out on the, um, you know, various platforms that they use for distribution. But, uh, I definitely do think that that's a major, major concern with a lot of the newer folks trickling in because. Uh, it's like they want to get involved and it's in all good faith and it's in all enthusiasm that they want to, and it just breaks my heart.

Honestly, when they say that, you know, I don't understand this. And I'm like, but you have to, you can't go be, you can't go, uh, beyond this point, if you do not understand that particular thing, I mean, it's dependent on the foundation. Um, foundational, you know, primitives that we were speaking about earlier.

So, I mean, you have to understand that, to understand Kubernetes. So that's, that's something, I think that a lot of folks like maybe Kunal, Saiyam, Anais, all of them are doing a wonderful job, even Nana. Um, I hope I got her name right. But all of those folks are doing a wonderful job at educating people and telling them that, you know, Hey, Kubernetes is not like a standalone, uh, tool and you know, you need to know a lot more than just Kubernetes because it's an entire ecosystem built on top of another entire ecosystem. It's not like a standalone, you know, island. yeah,

Rich: That's a great way to put it. It's a great way to put it. I mean, a lot of us, um, you know, by the time I came to Kubernetes, I'd spent many years like working with Linux and been through some pretty hairy performance troubleshooting situations and, and, you know, networking too. And, and I mean, I, I wanna make it clear to folks that are listening.

Like if you are newer, we're not saying that you have to be an expert in all of those things. Right. And in fact, even back in the day before Kubernetes was around, most people tended to specialize, right? So I think there, there were system administrators who were total generalists, but there were also people who would dive really deep into networking or security or something like that.

And maybe not be as strong in some of those other areas. So, so to be really clear, I don't wanna scare anyone off. We're not telling anyone that you have to be an expert at everything, but I think that like having some, some context, you know, for those fundamentals is like really

Divya: Yeah. At least the basics. And that's that's, even when people come and ask me how to get started, I was like, see, these are the basics. You gotta get them clear because, uh, if not now, um, going ahead, you will need them. And then when you stumble upon them, in some part of the documentation, you're gonna, you know, have that aha moment.

And it'll not be an aha moment at that time. It'll be like an oh shit moment. I'm sorry for cursing it's be a little oh shit moment, because you know that, you know, that that was required and you just skipped it because it was too much work. So getting the foundations right is a very, very important thing, before you embark on Kubernetes or any, like anything you start off with, you have to have a solid foundation.

If you don't, you are just basically setting yourself up for a lot of rework and a lot of trouble in the future.

Rich: And I mean, the problem is when you don't know something, you know, you don't know that you don't know it.

Right. Like ,it's, it's that problem. But I, I really like, you know, um, I've seen, uh, Kelsey talk about this Kelsey Hightower about the fact that like one thing that's that's nice is that those, those basic concepts are always gonna be there, right? Like the tools change, but like there's always gonna be storage, there's always gonna be networking. You know, these, these things don't go away. And so, and so it's worth, it's worth investing some time into like learning those basics, I

think. Um, yeah.

You mentioned some great content creators. Um, I'll, I'll link to them in the show notes. Um, some of them are from India as you are. Um, it, it seems like there's a lot of people there in India who are really excited about cloud native and really hungry to learn about it.

Divya: Yeah, I, I think it's fairly, um, a new thing. I, I won't say new in the sense that it's like one month or one day new, but maybe it's, it's more, um, to do with the fact that open source in general is gaining a lot of traction in the subcontinent, it's not just India, but in the subcontinent. I have seen a lot of interest coming up, uh, with respect to open source and, uh, with respect to cloud native, uh, people are looking to get involved in open source and in the cloud native ecosystems.

And, uh, I, I will, you know, not, um, diminish the importance of, uh, Kubernetes by saying that, you know, people don't wanna contribute to Kubernetes, people absolutely do, people want to learn about Kubernetes. Um, but it's also, uh, like, Hey, you know, how can I get involved in Kubernetes, uh, as a project and, you know, contribute to it and learn about it.

They want, you know, the trifecta, they don't want to just be doing one part of it. And I think that's also because, um, a lot of the companies in India, um, they are onboarding these technologies. And of course, you know, a lot of the good work that again, content creators are doing in terms of spreading this knowledge, because that's, that's an important part of this whole, you know, um, cycle, right?

Like the knowledge has to be out there. It has to get out and reach the actual people it's targeted. So they're doing a brilliant job of, you know, getting more people into the ecosystem and, um, you know, infusing the fresh blood that's actually required. Um, only problem is that, that fresh blood needs to also, you know, be, um, well versed with everything.

So it's like a steep learning curve for them. But, I think that's very solvable with the kind of fantastic content that we have out there. So I don't think it's a, a, you know, problem per se, but it's like a, what do you say? It's like the, the very first step is like the largest step that you have to take in every journey.

Right. So they they're like trying to, you know, cross that, you know, chasm, but I think it's okay. So, um, but the interest levels are really high, not just among college students, but among early, uh, career folks and even people who have been traditionally working with, um, uh, you know, proprietary, uh, products, all their life.

Like, um, if. If a person were 20 plus years experience, who's like a senior technical person is, you know, coming and talking to me about Kubernetes and you know, how they can get involved in the cloud native ecosystem. I think we are doing our job really well, so

Rich: Yeah, I, I just don't know how someone new does this, right? Because like I had been working with Linux for like 20 years, you know, before Kubernetes even showed up and, and I've found this whole cloud native world really intimidating at times, you know, with the, the amount of tools that there are, you know, just like looking at that landscape, my eyes kind of glaze over, you know, and, and I honestly had a lot of imposter syndrome about it and, and that's coming from somebody who already understood those basics.

Right? Let alone a brand new person who's trying to learn everything.

Divya: Absolutely. I, I can't even explain to you Rich the, um, amount of imposter syndrome I, uh, feel while even, um, you know, speaking at these various events, uh, even if it's like a, you know, uh, very, very mildly technical talk. I'm not even talking about like the deep dives or anything, but even mildly technical talks, I'm like, am I qualified enough to do this because, you know, I know Linox, I know, uh, stuff, I know a bit of Kubernetes.

I think I know it, uh, am I qualified enough to give this talk. So, um, most of the times I'm like hit by these waves of imposter syndrome wherein I'm I'm like, okay, I might not be the best person in this, you know, universe to talk about it, but I sure can get my perspective in. So I think I approach it from that perspective.

I, uh, that's how I learned to come my, you know, um, come that, uh, bad wise in my head that says that I don't deserve it. I'm like, everybody starts off somewhere and you are getting in a new perspective and that's how, you know, I try to calm myself down, but I definitely agree with you that it's like a little harder for folks starting out.

And I think our community in general does a fantastic job of allowing for a safe space for these people to come in and ask questions by saying that, you know, we have a model of there's no stupid questions. So that's, that's one thing that I really, really appreciate about everyone I've spoken to, whether it's like really, really experienced folks who've been there right from the start or, uh, you know, even folks who've just joined, uh, they, they have this like, open, uh, and transparent, um, uh, vibe about them that basically, you know, they told me when I, when I started out in the community, that there's really, really no, uh, stupid question. So please stop apologizing. And you are where you deserve to be. So just stop thinking that, you know, you don't. So that, that welcoming nature of the community, something I really appreciate, and I really am grateful for, because if for that, like me, would've never stuck, so yeah.

Rich: Well, it's, it is a great community. I think it's the best open source community that I've been a part of by far, you know. And, and like I said, I go a ways back. So there, there have been a few. Um, I, I do wanna say that, um, you, uh, are qualified to speak. So next time, next time you have that imposter syndrome, just remember, Rich said you're qualified.

So, um, yeah. And there's so much free content out there now there's, there's people, you know, like Saiyam and Kunal who are doing like whole courses on Kubernetes and the certifications and things that are, they're just out there for free. It it's, uh, it's really amazing to me, um, that, that people are so generous.

Divya: Yeah, absolutely. Like, um, when I started out, had I had all this content, it would've been brilliant, is what I'd like to preface this with. Uh, I wouldn't have, you know, stumbled so many times. But I guess it's all for the good, because I ended up learning a lot more. Uh, but for those who have this, please take advantage of it is all I, you know, advise because it's a lot of good content. It's not just Kunal and Saiyam, let's, let's be really clear, like they are, they are my, uh, uh, you know, country people and friends and all of that, but I, there are like several content creators, Anais is one of them. She's also fellow ambassador, so

Rich: She's fantastic too. But, um, but no, it's a, it's a great point, you know? Uh, I, um, I'm hugely respect of both of those guys, but I respect her too. And, and there are a lot of other people, uh, doing this stuff as well. Absolutely. Um, uh, from those newer fo folks that you come into contact with, um, are there specific things that you hear about a lot that are kind of stumbling blocks for people, like common sort of problems or questions that people have?

Divya: I think a lot of it, uh, essentially boils down to the very nature of open source. And I don't think they are to blame or the community is to blame in this regard because a lot of them come from a background where it's, um, necessary to give, um, respect in the way you address people in the way you actually, uh, you. Um, I, I wouldn't say subservient, but it's, it's like the whole vibe is different when it comes to open source. Um, you are required to show respect through action. You are supposed to show respect, uh, via the way you behave rather than, you know, address a person, as sir, ma'am, or, you know, call them these, uh, varied.

Um, you, terms of respect. But, uh, apart from that, what I've also seen is that because again, because of the backgrounds that, uh, they come from, which typically again, require you to consider a person, uh, who is senior in terms of years of experience and in terms of, uh, you know, the time that they've been there, even if it's not experience, even if it's the time that they've been there, there's like this, um, automatic, uh, God-like quality assigned to them.

And that's something I believe, uh, that goes away with time. But again, it takes a lot of getting used to because in a corporate setup or even in an academic setup, in a lot of the countries around the world, you are supposed to give that respect. And without that, you probably would not, uh, you know, survive. I wouldn't say survive because you'll obviously survive, but, uh, you probably would not, you know, be a part of the crowd. Here, this is what makes you stand apart. And that is something that I really,

really

uh, you know, want for the newer folks to understand. And we do a great job of it by telling people, please don't address us a sir, or ma'am and please don't, you know, um, feel intimidated to ask us questions because you've been told it's like a stupid question. And please don't say, sorry, when you're asking questions, because that's a really bad look, uh, because there are no stupid questions.

Everybody started out somewhere, everybody, started out, you know, not knowing everything. So you are good. You should ask questions, but ask them in a respectful way, ask them, you know, being cons, be consideredate about the other person. You know, don't think it's like a cutthroat competition, when, you know, you have to get this much done so that you are ahead of this contributor.

There's no competition here. There's just, you know, community and in a community when one person thrives everyone thrives. So that's, that's the mentality. You should look, there's no competition here. And I think that's, that's a lot of things to digest, but that's, that's, that's the thing that I've noticed that, you know, people behave as though they're in a corporate and in, in academic setup and that's completely different, um, when you come to the open source world. Yeah.

Rich: Yeah. That's really interesting. So you're saying that like, as a, as a cultural thing in India, that, that you think people are maybe less like more reticent to ask questions?

Divya: No. It's just a lot of people who have approached me as well. They're very, um, it's not shy it's I know that it's not shy. It's like they have this, you know, uh, they're like, oh my God, how do I actually ask this person a question? How do I, you know, talk to this person? I mean, I'm not a monster. I won't eat you.

I definitely won't eat you because A, I'm not cannibal, secondly, I'm a vegan, so I definitely cannot eat you. Uh, and even if I could, I wouldn't. So, so I mean, don't, don't, and I'm sure, you know, all, all the members of our community, agree with me that, you know, we are not gonna, uh, you know, school you or shout at you, or be angry with you where if you ask us questions. And that's, that's a thing that I've seen across nationalities across, um, you know, uh, career levels.

It's not even newcomers who are like, um, fresh out of college or are in college. It's just a general tendency that I've noticed among people. Because even if you're like a new entrant who's coming in from a corporate setup, you're probably a mid-level, uh, engineer who wants to, you know, understand the project.

Um, they're extremely intimidated because this is like a new world for them and it's extremely intimidating for them to get started with it. So, uh, they're like how, or do I ask people? Um, here, there are no official ways of addressing and if I just ping it'll sound rude. So how do I go about doing this whole thing?

So I think that's, that's one thing that I would advise when, uh, if I can call it advice that, uh, please don't be intimidated. Uh, when you ask questions, when you address people, just address them by their name, don't call us or ma'am. We are not, sirs and ma'ams here unless, uh, Queen Elizabeth wants to knight us, uh, in which case we, uh, you know, we have a whole different discussion there, but, um, unless, you know, we are not, uh, we are not gonna, uh, harm you or scold you or out at you or make you feel wrong about what you're doing.

So just ask

Rich: Yeah. I'm

Divya: Yeah,

Rich: I think it's, I think it's pretty common to kind of put people on a pedestal like that though, especially when you're newer. Like, when I think back to what things were like when I started out, um, before, before I was working with Linux, I, it was a hobby for me and, and those people who were like the system administrators at the big universities or at the internet providers or whatever, I, I, I was the same way.

I, I thought that was the coolest job. And I thought those people must be the smartest, coolest people, to have that job. Um, so I totally get it. And, and I mean, I, I think I probably still do that to a certain extent, you know, with someone like Joe or Craig or people like that. I mean, it's, it's easy to think, wow, these people are just geniuses and I like don't deserve to be in the same room with them or, or, to compare yourself to them and feel intimidated by the fact that they know so much more than you do, but they invented Kubernetes.

Right. So ,

it's, it's not very reasonable. It's not very reasonable for me to assume that I'm gonna ever know as much about Kubernetes as they do.

Divya: Yeah. I mean, again, uh, I'm never gonna say that I will know, but we can always try and we all have our own strengths to bring to the table. Uh, so I, I, I, I, you know, calm my imposter syndrome, like I said, by saying that, because otherwise it's just gonna be difficult because all the people we meet in the open source community are hella talented.

So. I,

I

don't

think, you know, any single person, uh, is less talented or more talented because we all, we all have our strengths and we all have our weaknesses. It's what we bring to the table that matters.

Rich: That's a great way to look at it. um, so we kind of jumped right into things, but usually I start off kind of asking about people's background a little bit. So I kind of wanna kind of wanna back up. Um, how was it that you got involved in computing, in the first place?

Divya: Oh, uh, that's a very, that's a very straightforward answer actually. So I was an electronics engineering graduate. I had no plans of being in the IT industry, but, um, I think I attempted a ton of, um, exams so that I could actually, um, you know, get into the public sector for electronics, uh, electronic companies in India. Didn't get through.

So I was like, uh, I'll give a shot. , I'll give IT a short really. And here I am. That's, that's how I got into it. Uh, because uh, campus placements are a thing. So, um, for a lot of people, I don't know, uh, if you are familiar with the way the, uh, Indian, um, engineering system works in general. So we have a lot of exams that help you get into, um, you know, further universities that help with masters and stuff. And you also have, um, uh, if you're like from a core engineering field, like say electrical mechanical, civil, or stuff like that, you have exams, uh, to get into core engineering companies as well, within the public sector. So, um, if you don't clear them, then it's a bit of a problem because you don't get to work in the field that you've graduated in.

Um, yeah, so IT was the actual last option that I had and I am glad I landed up here because I, um, you know, I am doing so much more than I would if I were just an electronics engineering graduate. So yeah,

Rich: How did you, um, how did you get specifically into the cloud native stuff?

Divya: Oh, um, so that's actually a lot, uh, I mean, I thank HSBC for, you know, having, uh, Kubernetes onboarded into our team. So , that's, that's the only thing that I wanted to understand more about. So I've worked on proprietary systems, all of my life, uh, to be really honest, I have not worked on many open source, uh, uh, projects.

I, in this context of my work, I've not utilized many open source projects in, um, you know, my day to day job. So what I did was, I was like, um, I used to work and then they're like, Kubernetes is there. So then the first thing I actually did is I was like, what the hell is Kubernetes? Why is it? You know, that every time I change this job, there's like, or get a job.

I'm like, there's, there's 10 things that are just floating around. First time it was like cloud. And then the second time I'm like, oh God, what is Kubernetes now? And then I Googled and I was like, oh, there's a lot of stuff here. And then I discovered that it was open source. Then I learned about open source and I knew that lit, there was something called as open source, which means that, you know, it was free. In my head, it was just like, it's free software and. I've I've after that, I've refined my definition of open source, of course. But in my head, when I started out with like, um, researching about Kubernetes, um, it's like, Oh, this is free. That is, that is the first thing that went into my head. And I was like, okay. So if it's free that it, that means it's being done by like voluntary contributors, because somebody would, I mean, if it were not free, then it would be basically done by people who are a part of the company.

Right. So, yeah. So that's how I got into, um, open source and cloud native. And, um, then, you know, obviously I refined my understanding a lot more, uh. That whole initial phase of thinking that open source is equal to free for, I think that was for around two months. And, uh, I think after that, I, I read a lot of stuff about licenses and stuff and, uh, I was like, okay, that it's not a, it's not all about being free.

So there's a lot more that goes behind the scenes. So, yeah.

Rich: Yeah, I think, I think for most companies, Kubernetes, isn't free. I think that they, they have a pretty big budget behind, uh, implementing and maintained Kubernetes. Um, but, but, um, yeah, I mean, I think that that was a big part of my, um, like initial kind of entry into Linux too, right. Is that this was like a thing that I could just install on my computer for free and I didn't have to pay anyone or, I could just download some images and, and be off to the races. Um, so you work, uh, a lot with documentation and, um, I, I understand that you are doing documentation for Rancher and Kubernetes and also Litmus Chaos that you're, you're just basically doing all the documentation.

Divya: Yeah. So I, I was joking with, um, Savitha, who is one of my, uh, who's one of the people I've met, uh, via the community. And I also gave a talk with her two talks with her at, uh, Spain, uh, the Spanish KubeCon, which really fancy to

say

Rich: too. I

think.

Divya: Yeah. So, uh, I was telling her it's like, I am, uh, I mean, I, I'm not gonna steal Celeste's thunder. I'm not a docs influencer. I can barely, you know, give a talk about docs, but, uh, I'm. I, I it's like docs find me wherever I go. Nowadays, it's just like, I'm, I'm going a project. Like, can you improve our docs? And I'm like, I want to help you improve your docs. It's it's like now, uh, um, it's now, I actively search out projects, and see how that documentation looks like.

So now my first focus, whenever I look at a project is like, like, how good is your doc? Let me see this. And, uh, then if anybody asks me for feedback, I was like, your docs are not right. Is that the only feedback you have? So I like, no, I've not tried your project out, but that's like the first thing that you have to have, you know, uh, pat down properly, because it's. it's an essential. I know that a lot of people are going to tell me that, you know, it's just technical writing. It's just writing. How hard can it be? Um, , it's really hard. Uh, and I'm not even, uh, you know, saying that because it's a thing that I do day in and day out. Um, like it's really hard, um, because there's a lot of context to be sought out when you write a documentation.

And even if it's just updating it, it's a lot of effort. So, um, it's, it's very difficult to have, um, and maintain good documentation for a project. Irrespective of however, um, you know, the project is licensed. Even if you are like app proprietary product, uh, like the ones I used at my day job in HSBC and, uh, the previous company I did is now acquired by [unintelligible], a lot of the projects require good documentation. At the end of the day, you can't have a project without documentation because your users won't know how to use the product. Um, you cannot have your sales people and your dev folks constantly assisting the user or even, you know, your, um, DevRel constantly on a phone saying, Okay, this is your problem, let me find you the solution. You cannot be, you know, customer support the entire time.

So you need to have good docs. And that's just a basic, and I think, uh, going through a lot of bad documentation in the initial stages of my career, set me up for this job. uh, because I, I, I was, I was so tired of having, um, having to read a lot of troubleshooting documentation before getting to that one actual step that would solve an issue during, uh, an outage call.

I, I think that's, that's what prompted me. I was like, I need to write good docs. That is my life's calling

Rich: One thing that, that used to frustrate me so much. Uh, and this is a long time ago. This is not the new Microsoft I'm talking about, but, um, but in the old days it was very much, uh, the situation that there was that registry edit you had to do to make the thing work, and it wasn't in the documentation. And you learned about it from some forum somewhere and, and, and that sort of thing was just, so it just drove me nuts that there were like these common practices that people who knew what they were doing did that just weren't even in the documentation at all.

Divya: Yeah. Those, those little tips and tricks, right? Uh, that that's, that's essential across a project. I mean, whether it's licensed, you know, for a. Uh, under a company or whether it's licensed, uh, as open source under the various open source licenses, it's absolutely necessary to have those little tips and tricks because if you end up having a project or a product that basically is just going to tell you how to install it, what about the 10,000 steps that happen after the installation? Like what is, what is it about day two that you're not going to address anything of that. Because 2 is important, right? Like when you use a product, you are eventually gonna run into problems at some point in your life. So what about those times?

You just gonna tell me how to install a project and leave it at it and I'm gonna be stuck. And then I'll have to call your, you know, in the case of open source project, I don't, projects, I don't even know who to call at this point, but if, if you know, you are a proprietary, um, you know, service provider, then you are gonna have like people just calling up your, um, customer service executives at all hours of the day.

And God forbid if, uh, you know, they don't have a 24x7 support on call or whatever, you're just gonna be stuck. So have good documentation. And, um, that's, that's like a call to action for everyone who probably listens, please write good documentation.

Rich: I'm, I'm pretty, yeah, I'm pretty sure none of the open source maintainers that I know want to be getting phone calls from users. So , I hope, I hope they're writing good docs. Um, I'm curious, you mentioned that you, you used to run into a lot of problems, um, um, and you kind of learn from the bad documentation that you saw.

And I, the, the day two thing is interesting to me because I tend to focus a lot on the day one, right? Like I think those quick start docs and things like that really need to be, um, just spot on, right. Or you're gonna lose people right away. But, um, but I'm wondering if there are other, if there are other kind of common mistakes that you you've seen with documentation,

um,

Divya: So one of the things that I see when, you know, a project typically writes out documentation is that they don't keep the end user in mind, uh, the way they should. So a person who's coming new to your project is not gonna be familiar with all the terms and, you know, all the whole ecosystem that your project is built on.

Maybe they are, maybe they're not, you, you can't assume. A lot of people just start off, um, at level 50 when they should be starting off at level zero, uh, they assume that, you know, People know what, um, a particular framework is upon which this project is built and, uh, provide no links, provide no context.

And it's like, if it's not even quick start, let's not even go to the quick start bit. The first overview page of any documentation, um, should have at least a basic context of, um, what the project is built upon, what, um, framework it uses, link it to those particular things. And don't use a lot of technical jargon.

I know that it sounds fancy. It sounds like, you know a lot of things, but no, you are not trying to prove it to anyone, uh, that, you know, a lot, bit, lot more than them. The document, so I say this, uh, in all, you know, niceness, that the documentation is your first marketing, um, you know, pitch, I wouldn't say pitch, but, uh, it's, it's the first marketing piece that you put out to your consumers, irrespective of the project.

So if your documentation is good, if you know, your user can install the document, uh, you know, the project or the product from your documentation and understand, you know, the terminologies that are there, then I think you are setting yourself up for success. But a lot of projects don't do that. They start off at level 50, like I said, have like a bunch of technical jargon on the very first overview page.

I'm not even going to go to quick start at this point, but overview page itself has like, um, this is based on XYZ framework, but what is XYZ framework? Am I supposed to know what is XYZ framework? Um, if I'm a user newly sampling upon this product, what are the dependencies that I need to know of? None of that is specified, but I think those need to be really, really clear and outright.

So link that link and talk about those. Uh, maybe not in detail, but at least, you know, have, uh, one liner or hyperlink it to the documentation.

Yeah.

Rich: Yeah, I think that, um, yeah, acronyms too. Like the first time you use an acronym, like actually say what it means.

Divya: Yes. I mean, I've, I've had so, so many of them, um, I've encountered so many of them when I used to work in, um, you know, my previous jobs. I'm like, how, how am I supposed to figure out what the acronym means? And it'll be like some very complex problem. And I used to work with HSBC and it'll be like, payments are stuck. And I'm supposed to figure out the meaning of this acronym. How am I supposed to figure out the meaning of this acronym without Googling, just have a link for God's sake. So it's like, I'm tired. I'm trying to figure out the root cause of this issue. And you're telling me to figure out, um, an acronym to figure out the root cause of this issue.

Then I go to Stack Overflow. Then I figure out what this is, then come back then, then there'll be a second acronym somewhere after like two, three lines. I'm no, please, please.

So.

Rich: Yeah, I've been in that, I've been in that situation where you're dealing with a really big incident and you just just need to get the answers. Um, what's it been like working on the Kubernetes documentation?

Divya: Oh, uh, it's been wonderful. Uh, I wouldn't, um, you know, say any less, um, about it because, it's, I've gotten to interact with so many people. Uh, and I think it's the people that make the project, people who make the project so wonderful. So I've, I've gotten to learn a lot more than I signed up for and I didn't sign up for a lot.

So I basically just wanted to understand why, uh, what open source was and what, what, you know, what went into the rationale behind releases and stuff like that. And docs has taught me a whole lot more than I signed up for. Like I now, um, so Tim, I think Celeste mentioned this in her episode, um, that Tim is one of those people who like throws away, um, nuggets of documentation wisdom, like free candy and he actually got started because he was learning, uh, for one of the, uh, certification exams.

Rich: Oh, I remember this. Yeah. Yeah. Celeste mentioned that that really clever thing he did where he actually put stuff that he needed for the exam into the Kubernetes docs, because he was allowed to use the docs as part of the exam.

Divya: Yeah. I think it's a really cool way to learn because I, I never thought of it that way to be honest. And, um, uh, I, I, I I don't know if you were there at the Kubernetes contributor summit. Uh, I don't remember.

I was not, no.

But, uh, basically I was, I was, I was eating the whole time, so I was not participating in one of the quizzes.

So, uh, Tim's team won like, uh, I was like, there were a bunch of other teams and they were all veterans, so it was like a whole room of veterans there. And I was like, um, Tim was sitting with us and a bunch of, um, you know, newcomers to the project. And we were like, oh, uh, there were questions being shown. And they won.

I mean, obviously there was just one winner, but, uh, they won the whole thing. Like if it was a effort, it was his team that had won. So I'm like, that's a very cool way to go about learning. And, uh, I learn a lot from him, uh, to be very honest. I don't understand a lot of the processes, and most of the times he is, he's correcting me.

And I'm so glad that he does that because I learn a lot because of that corrections that he tells me that, you know, You're going, I think you, you know, you need to change this, your, I think you need to do this, you know, this particular way. And he makes it so welcoming, uh, in the sense that he doesn't, uh, sound like, you know, an irritated person who's trying to, you know, Tell me what, you know, you should do this, you should do that.

He's like, think this is the way it goes. You are, uh, maybe, you know, you, what do you think? He, he always asks for your opinion. And that's one thing that I've learned, like you should ask for people's opinion. What do you think about these changes? Are you cool with them? Uh, how you see this whole thing?

So it's a lot of, you know, all these cultural changes within me that I've learned, but I, I also learn a lot technically, so it's not all, you know, uh, you know, soft skills and stuff like that, but I've learned so much, uh, from, you know, all these conversations that I've been having because of the release.

So I, I used to shadow on the release team as well. So, um, I've, I've learned so much from that experience because, um, in the release, you typically have more, um, you know, uh, technical stakeholders from the various SIGs contributing to that release. So talking with them in itself is like a huge, huge, uh, you know, knowledge exchange.

So more from their side, obviously, but it's a huge knowledge exchange. And I think I've learned a lot from that process, but SIG Docs in particular. I think I learn a lot from all my co-chairs and from, you know, all the tech leads and even from the contributors themselves, because several of them are experienced contributors and they know far more than I ever will.

I take it as a learning journey, yeah.

Rich: I've mentioned this a lot. If people follow me Twitter, that I'm, I'm a big fan of the release team. I think that that's, that's an area where like, people tend not to get credit, you know. It's one of those things where you don't notice it when it's going really well, but you do when it's broken.

Right. And, I think docs, docs are similar. Right? I think this is changing some, you know, but that there's still a lot of focus on code contributions, you know, opposed to like, you know, um, like docs or, or something like that. I actually had this kind of funny thing happen recently where, you know, you mentioned the contributor summit and, um, I would not have gone to that because I didn't consider myself a contributor because I'd never had a, I'd never had a PR merged.

And I just recently had my first PR merged. It, it was a simple little thing, but, um, but I had other people react the same way, you know, and say I was already contributing and, and that's what I think I would tell someone else too, but I just didn't feel that way about myself. It's such a weird thing, but,

Divya: No, but you are a contributor. It is, so I don't think we make that distinction, uh, like anybody else makes that distinction. It's, I think we ourselves are very hard personally, uh, you know, when we come to evaluating our, uh, you know, our contributions or our, you know, level of contributions to the community. I don't think we should be doing that, but, um, I would also like to quote Tim, because this is what he told me when , I told him that I, I, I don't feel qualified enough to be, you know, a coach. Like nobody can talk you out of, um, an imposter syndrome, but yourself. You have to do that hard work.

You have to take out that fear, that fear and that feeling of unworthiness, because you are worthy and everybody else can see that you bring a lot to the table. Everybody else can see that. So accept things for what they are. So that's, that's paraphrasing his advice, but, uh, told me that, you know, the only person who can actually, um, you know, remove any feelings of imposter syndrome from your head is you. You can't expect anyone else to do that.

Rich: Yeah. I'm definitely one of those people. Who's a lot harder on myself than am on other people. Like, I, I, uh, I'm definitely a lot kinder to other folks than, um, than I am to, to me. So I'll, I'll definitely keep that in mind. Um, so besides, um, besides Kubernetes, you know, you, you work on the Rancher docs, um, you work on the docs for a Litmus Chaos. Are you still doing that?

Divya: Uh, yeah, so I do that on a, um, you know, uh, requirement basis. So I used to be very actively involved at the start. Uh, but, uh, then, you know, the requirement for me to get involved was purely, you know, more relevant in a qualitative and a style style, style related, uh, way, because a lot the, um, Uh, you know, I, it got acquired.

So Litmus Chaos's parent company, uh, got acquired by Harness. And then we had, um, you know, whole, before that we had a bunch of releases, which I helped with, but, uh, over that period, I think, um, my involvement has been lesser, but I'm still there, like, uh, for any, you know, help or any signoffs or any approvals on the styling, or styling in a sense.

I mean, the document styles and the way, you know, messages conveyed within the docs. For those stuff from there, but from a more technical perspectives, I think I'm a little more hands off right now.

So not

that much of an involvement at this

Rich: I didn't realize it had been acquired by Harness. That's really interesting. Um, yeah, I, uh, I worked at a chaos engineering vendor before, so that's, a subject I'm really interested in. Um, do you, uh, like what have you, what did you experience in terms of people like doing chaos engineering with Kubernetes?

Do you think that that's something that provides a lot of value for people?

Divya: Absolutely. So I, um, in my previous jobs, like I said, I used to work on a lot of production calls and eventually everything is just gonna move to, I'm assuming everything's just gonna move to Kubernetes eventually. Maybe not in the next five years. Maybe not in the next ten years, but eventually, um. So I think it's a value like yes, engineering as a discipline, as a value, um, in Kubernetes even more so because the inherent distributed nature of Kubernetes makes it more, um, you know, prone to, uh, all these, even with all the observability and even with all the, um, newer disciplines cropping up, it makes it more prone to, um, all these undetectable failures.

I wouldn't say I wouldn't call them failures, but it's difficult to detect in a, uh, distributed system where the actual point of failure lies and how do, and if it's like a, uh, if it's like a crisis call where you're actually figuring out where the failure is during the crisis call, then, you know, you are sort of, uh, setting yourself up for a lot of pain, uh, especially in a,

Rich: it's kind of too late by that

Divya: your trade system. Yeah.

So chaos engineering holds value in distributed systems, in my opinion, because of this whole concept of, uh, you know. Monitoring and observability will continue to evolve. No doubt about that, but it's always good to be prepared. In fact, it's good to be over prepared. I would say, uh, if you ask, uh, me. But it's always good to be at least prepared and, you know, understand where those, uh, you know, potential failure points could lie, even if you don't have an exact, um, even if you don't have an entire listing, rather. If you, even if you have like a broad idea and I'm sure, you know, the tools that are out there in the market are more, you know, getting more sophisticated day by day.

Um, and they will continue to, um, those, uh, tools would give you that brief idea. And that is, I think a good starting point. You can evolve from there. You can even, you know, um, Uh, similar to your own chaos, but I would not recommend that because then it would just probably be more chaos than chaos engineering.

So yeah, because

Rich: Yeah, if there are listeners who aren't familiar with chaos engineering, basically the idea is that you're injecting faults into the system intentionally to, to see that, you know, how it behaves, you know, um, not sort of taking it for granted that the system is gonna work the way that you think it will, or that you, you know, the, the diagram you drew out, you know, is actually gonna be how things.

Divya: Yeah. And you don't go cowboy on production by the way. Uh, you don't start implementing right on production, please. That's also one caveat that I would like to sort of add there. You don't start off breaking things in production. Nobody should do that. That is madness. That is chaos. That is literal chaos.

Don't do that. But, uh, yeah, I think as in, as in, as a discipline, I think it would, it would be, you know, evolving in, you know, uh, most of, and it would be more sophisticated. The tools that would come out would be more sophisticated. They are already pretty sophisticated given, you know, the relative nacency of this whole discipline.

It's not that

old,

Rich: Yeah, yeah. Yeah. I mean, people like Netflix and Amazon have been, you know, playing with these ideas for a long time, but, but for most of the market, you know, it is, you know, relatively new, just a few years. um, so I guess some of the rules that we are learning today, so, so no

cannibalism, um, you don't eat people and you don't go cowboy in production.

So, so good things for everyone to keep in mind, I think. Um, okay. So, so you are also a CNCF Ambassador, which is very cool. And I wondered if you could talk about that. Like for people who aren't familiar with the ambassador program, kind of how it works, how you got into it. Um, all of that.

Divya: Yeah. So, uh, this is like a frequent, um, you know, question on the CNCF Slack, on any of the public channels that are there, uh, especially the, um, #ambassador public channel and even, uh, #hallway and, uh, #random. And, uh, before #general, I don't remember if #general was ever open to the public, but if it was, I used to see How do I become ambassador, and it's as simple as you apply for it. You think yourself worthy, you apply for it. And that's what I did. Um, you can, of course nominate like, uh, existing ambassadors can of course nominate themselves for,

um, uh, can so not nominate themselves, nominate others into the, uh, ambassador program. Uh, but it's largely a self nominated effort, which is how at least I got in, and a bunch of folks who I know also got in.

And, uh, there, um, there are, I wouldn't call these perks, but they are perks. So, uh, there are a lot of perks of being a CNCF ambassador, which, um, are more rel uh, you, relevant in the large, uh, you know, in the context of a larger ecosystem. So you are not just talking to people who are working on Kubernetes.

You are work, you are talking to a lot of folks who are working on other projects, so you understand a lot of stuff that's going on and, uh, you are connected to those people, um, and you can ask them questions and bug them. So that's, that's one benefit. And the other benefit is, uh, you get to hang out with these folks in person, if you ever come to KubeCon, which is what I discovered in Spain, Valencia.

Sorry. So,

Rich: So

Those, those sound like both sound like pretty good perks.

Divya: Yes. And, um, you know, uh, CNCF does a fantastic job to be really honest of, uh, you know, um, having, uh, of having, having to wade through all these, uh, ambassador, um, you know, nominations every, um, couple of months. Because a large number of people apply and, uh, it's it's with good reason because you know, that, that tag means a lot because it's, it's also a lot of responsibility.

So this is not the only thing we do. We also do a bunch of things like, you know, promoting cloud native, um, in, uh, you know, various areas, whether it be by blogging, whether it be by speaking at events, whether it be by generally posting educational content, uh, there are a lot of ways you impact, um, people's view of cloud native and the general, you know, open source, cloud native ecosystem.

So you gotta do the work, not saying no, but it's also a lot of fun. So, CNCF does a fantastic job because I'm very sure it receives a lot of applications and to continuously vet through them and, uh, go through, uh, and, you know, select them, basis, the uh contributions they've made is a very tough job I'm sure.

So I'm not even going to, you know, comment on that aspect of it. Uh, you know, I, you, if, if you are desirous of getting to this program, uh, you just need to apply, um, and with all the, you know, contributions or everything that you have done within the cloud native native ecosystem and folks vet it on and every, uh, on a monthly or on a quarterly basis, as far as I'm aware.

So, um, if, if you feel like, you know, you have even more accomplishments to add in that short timeframe, you can resubmit it. Um, but, most of the time, I think, um, you know, it's not required because they, like everyone in cloud, native knows everybody else is what I have realized right now. It's like same, uh, same team, different companies, like the motto of cloud native, more than anything else.

So, uh, you know, we, we know each other, so if you are here, we know you are here. So, you know, it, it, it obviously comes to light if you are doing fantastic work. So never thought it necessary to reapply,

but,

Rich: Yeah,

Divya: Yeah, that's, that's the gist, I guess.

Rich: I'll, uh, I'll find that application and put a link to it in the show notes. I've seen that before. I know, but, um, just in case any of the listeners are, are interested in looking into that. Um, so you did, uh, you did do one talk that I saw in Valencia. It sounds like you maybe did a

couple

Divya: Yeah. I actually had three talks,

so yes,

I hit the

Rich: [laughing] I can't, I can't get a talk accepted at all and you're doing three that's

Divya: yeah. So yes, I did one, uh, so one, was at a co-located even so I'm not sure it counts. Uh, so one,

yeah, so one was for Cloud Native WASM Day. Um, and, uh, it was about, um, the binary and textual format for web assembly. That was one and the other one was burnout. Um, or with which I did with, uh, Savitha. And the third one was the one you attended, which was Saiyam , Kunal and Savitha,, which was about navigating the CNCF landscape, uh, the right way.

those were the three.

Rich: So I, I, I did see that third one. I, I enjoyed it. Um, I will, um, make sure to link to that in the show notes. I think that, um, if there are people who are listening, especially that are new to, to this stuff, um, I think you all did a, a really good job of covering a lot of the topics that people might not understand.

Literally like looking at the landscape right at that, at that image. And like, what do all these icons mean? And what does it mean, you know, the, the way things are grouped and, um, you even went into things like, you know, what's a TAG and what's a SIG and, and all this stuff. And again, we were talking earlier about all the acronyms and, and like, there are a lot of them even just with the CNCF, right?

Divya: Yes. It would be really confusing if somebody were to just like, look at it, like, What is this landscape for? And it's growing. Like it's not even like it's a stagnant, uh, or a static image. It just keeps on growing. Uh, so it's even more relevant in the current context that, you know, you be aware of how to actually navigate the entire landscape and how to make it work for you rather than, uh, you know, you just getting lost in that whole scheme of things and not being able to figure it out. So we've tried making it as big enough and as friendly as possible. And I have to give a shout out to, uh, Matt Stratton's talk as well because I enjoyed it personally. He also did a similar talk, but it was from an educational perspective. He did it in the students track itself, but, um, I really enjoyed his talk as well.

So that's a big shout to him and, uh, Whitney. So his co-speaker was Whitney and they both did a fantastic job. I really enjoyed their presentation on the same topic, but it was from a different perspective and it was very educational and really, really would, you know, compliment our talk, uh, rather than, you know, I didn't see it as competition because I was like, oh my God, this is like a perspective I never thought of.

So both our talks, uh, go well together or you can choose, pick and choose also. That's also okay.

Rich: I didn't, um, I didn't see, Matty's talk, but he's, uh, one of my favorite people, so I will link to both of those in the show notes so that people can have a chance to watch them. Um, I, you know, I think of myself as a little bit of a veteran of this stuff and I, I still learned some things from your talk.

Like there were some things about, you know, the, the landscape that I didn't know. Um, so, um, what kinds of things, um, do you think that people maybe don't understand about how the CNCF works? Like, are there things, questions, you hear people asking a lot?

Divya: Oh, I think a lot of questions centered around, uh, you know, existence of the foundation in the very first place. Like, uh, why, why is there a foundation? Like can't Kubernetes just exist on its own? Like, , that's a question. I've I've. I've heard people say, what is the CNCF? So when, um, I think a colleague of mine actually got certified and, um, I, I think it was in 2018 or 2019, I think it was 2019.

Yeah. So a colleague of mine got certified in, um, the, uh, one of the Kubernetes certifications, I think it was CKA if I'm not mistaken. So he got certified and he is like, um, what is the CNCF? I was like, uh, that's, uh, that's actually, you know, the home of, you know, the Kubernetes project. Oh, but why is it there?

I was like, uh, it's there because, you know, it's, it's housing, uh, a lot of vendor neutral, open source projects. Um, and it's basically, you know, building out and open source, vendor neutral platform for the cloud ecosystem, which is a different way of actually, you know, building and deploying applications. So that's why it exists.

So then of questions that particular you just gave the CKA, so shouldn't you know.

Rich: That's really funny. Yeah. I, I, I can understand that though. And I think that like, um, probably again, people who've been around longer, maybe take it for granted that everybody knows what the CNCF is and, and what it does. Um, . Um, Well, Divya we have been, uh, talking for a while. I think I probably need to wrap things up.

Um, I really have enjoyed getting to chat with you. Um, I'll definitely put some links in the show notes to things that we talked about and also, um, to your, uh, Twitter account. Um, what, what is your Twitter account

again?

Divya: It's

Rich: Okay. Um, I, I will link to that for sure. I do follow you so I know I can find but, um, is there anything else you'd like to mention that you're working on or anything you want to let people know about?

Divya: oh, um, so I, um, I work on a lot of things, so probably, uh, you know, like two minutes of the last, I mean, last segment might not suffice, but, uh, if I constantly post on Twitter and, uh, LinkedIn about all of those things that I work on. And if any of that is of interest to you, please feel free to reach out.

Uh, like I said, at the start, I don't eat people for lunch, dinner, or breakfast, not a cannibal. So please, please, please, uh, you know, feel free to reach out. I won't shout and, uh, see my voice is also sweet. I don't shout.

Uh, screech.

Rich: I'm starting to, I'm starting to wonder about the cannibalism though, because you keep bringing it up and now I'm wondering if you really are a

cannibal and you just

Divya: Yeah, no, no, I, I barely

Rich: that you're

Divya: get by. I, I could barely get by at Valencia. I survived on potatoes, so,

uh,

Rich: yeah, there, there was a lot of meat to eat in Valencia wasn't there. Um, alright. Uh, well, Divya this is really been fun. Um, thanks so much for coming on.

Divya: Thank you so much for having me Rich and hope you have a fantastic day.

Rich: Kube Cuddle is created and hosted by me, Rich Burroughs. If you enjoyed the podcast, please consider telling a friend. It helps a lot. Big thanks to Emily Griffin who designed the logo. You can find her at daybrighten.com. And thanks to Monplaisir for our music. You can find more of his work at loyaltyfreakmusic.com. Thanks a lot for listening.