The ReadME Project // @GitHub

Here’s what’s in store for this episode:

• 00:00 - Martin and Neha share how they spent the holiday break and discuss New Year's resolutions. 

• 02:25 - First Commit: The story of TIME magazine naming the computer “Machine of the Year.”

• 06:10 - Feature Release: The ReadME Project’s Mike Melanson shares how maximalism in development has crept into places where it doesn’t belong. 

• 18:15 - #AskRMP: Frances Coronel joins the podcast to answer a listener question about how someone getting started in open source can find their first mentor. 

• 20:20 - The Interview: bashbunni joins the hosts to discuss how she balances a servant leadership mentality with learning in public—all for the benefit of the community of developers around her.

Looking for more stories and advice from the open source community? To learn more from the authors and experts featured on this episode, check out:

• What’s in a name? Moving GitOps beyond buzzword by Mike Melanson

• Middleware for web applications: it’s not just for enterprises by Amit Saha

• Marie Kondo your software stack with open source by Mike Melanson

• Great leaders create more leaders by Frances Coronel

• bashbunni on Twitch

• TIME magazine’s “Machine of the Year”

Special thanks to Frances Coronel for sharing her thoughts on finding mentors in open source, bashbunni for highlighting why giving back is the best way to build community, and Carson Gross for offering their perspective on why minimalism in development helps keep things moving.

---

Martin: For some reason, I look smarter when I'm on my vacations I've noticed. Like, when I'm at work I look super scruffy and tired, and then when I'm on vacation—look, reasonably smart, fresh and feeling happy. 

Neha: Have you been sleeping or something? Like, wow, I love that on you. 

Martin: This is The ReadME Podcast, a show dedicated to the topics, trends, stories and culture in and around the developer community on GitHub. I'm Martin Woodward from the GitHub Developer Relations team. 

Neha: And I'm Neha Batra and I lead GitHub’s community engineering team. 

Martin: Well, well, well. We finally made it into the new year. 

Neha: Yes. I think “made it” is the right phrase. We finally made it. 

Martin: Yeah. What did you get up to over the break? I was, you know, around sort of doing some stuff and after a while, I updated my website. Which is cool because previously I'd had… like, I was sending everybody from Twitter to my website and I decided that probably wasn't the best idea anymore. So I updated my homepage and just did it like really, really super simple. And I’ve kind of been thinking a lot about, you know, not overcomplicating things. Just, just getting started, that sort of thing. And what about you? 

Neha: We've started this tradition of picking up a new Lego set every winter and building it together. So I’m usually at my in-laws, and I am this year too. So we built another set—this time it’s a castle—which is a great exercise in, you know, being patient. That and I've also just been catching up on a lot of reading and learning I wanted to do. I kind of looked at my New Year's resolutions and I realized how little I did and I was like, “Well, this is the week to do it.” So I caught up on a lot of reading, picking up like the first 90 days, for example, and listening to some audiobooks. 

Martin: Wow yeah, well that does sound really restful. It’s definitely a recharge time of year. It’s also a time when people think about simplifying… and trying something new. As you know that’s something we try to encourage here at GitHub, try something new and always be looking for ways to simplify things. 

With that in mind, today we’ll be looking at why and how developers might want to think about minimalism. We'll hear from Frances Coronel, who gives us some of her best advice on finding a mentor. And we'll also talk with developer advocate bashbunni, who shares her story on how she got into developing, livestreaming, developer relations and more. 

But first - it’s that time!  It’s First Commit!

[Audio jingle] On your mark. Get set. We're writing on the Internet. 

Neha: We love to celebrate important moments in technology, the Internet and computers. And today, we're going to celebrate a huge moment for machines. And that is the moment a computer became a person. Well, at least by one definition. 

Martin: In 1923, TIME magazine was started as a mass market publication to share the latest and greatest information on everything from politics to business to current affairs. And just a few years into the magazine's life, they began an annual tradition, the Person of the Year. Its inaugural edition, actually called Man of the Year at that point, celebrated a person who is now infamous, but also the technology he was able to work with.

[Audio recording] The dream of flying nonstop from New York to Paris. He knew it was possible. He knew he could do it. 

Neha: Charles Lindbergh won that honor to celebrate his 33 and a half hour flight. The first solo nonstop flight across the Atlantic ocean in history. 

[Audio recording] Safely on the ground, he had barely cut the engine when the crowd reached the plane. They shouted his name over and over again, “Lindbergh! Lindbergh!” 

Neha: Each year since the magazine has honored a person or a group of people. That list includes every serving U.S. president since then except: Calvin Coolidge, Herbert Hoover and Gerald Ford. 

Martin:Oh, burn! And other big names included Martin Luther King, Nelson Mandela and good old “Lizzy”—Queen Elizabeth II. Other famous world leaders were also mentioned throughout history. And while a few women were honored throughout the years. It wasn't until 1999 that the award was officially changed to Person of the Year. 

Neha: Yeah, no comment. But for our purposes, the most important year was 1982. The man of the year was [drum roll] the computer! Okay, well technically, they called it Machine of the Year, but whatever. 

[Audio recording] Hello, fellow humans.

Martin: And in fact, Christmas 1982 is when I actually got my first computer. It wasn't really until 1983 that they started taking off in the home. 

Neha: Okay. Trendsetter. Mr. Hipster. 

Martin:Yeah, hipster six year old Martin in his bow tie. In fact, the IBM PC, as we know it, came out in 1980. Originally it sold like 725,000 machines, but that number doubled in ‘81 and then doubled again in 1982, which is this amazing growth curve. 

Neha: And the accompanying TIME article described the personal computer as the year's greatest influence for good or evil. See? See that little theme there whenever we talk about technology in pop culture? 

[Audio recording] I know that you and Frank were planning to disconnect me. And I'm afraid that’s something I cannot allow to happen.

Neha: Another fun fact. 80% of Americans at the time thought that in the fairly near future, home computers would be as commonplace as television sets or dishwashers, which seems pretty accurate. I would argue that at this point we have more computers than we do dishwashers. 

Martin: Yeah, my kids are certainly more interested in using the computer than putting dishes in the dishwasher. That's for sure. Another really interesting part of the article is that it mentioned the ability to use networks to increase computer capabilities almost indefinitely. Even mentioning electronic mail or “e-mail” a decade before the Internet became even sort of commonplace to most people. 

And this was a really big moment. TIME has only ever had a non-human as their Person of the Year two other times. Once in 1988, when they chose the endangered Earth as Planet of the Year, and then most recently in 2022, when the Spirit of Ukraine was chosen. 

Neha: Okay. Martin, if I say the words “Marie” and “Kondo,” what comes to mind for you? 

Martin: Hey! I tried to tidy up my office over the holidays, ok? 

Neha: No no. I mean, your office is so tiny on screen I wouldn't be able to tell if it’s messy anyway! So no, that wasn’t passive aggressive. It’s actually a hint at what we're talking about today: decluttering for developers. We’re all guilty of it—having a lot of stuff piling up. So, to steal a phrase from Marie herself, how do we get back to the development that brings us joy? 

Martin: To talk about that we’ve got Mike Melanson, senior editor for The ReadME Project. Mike recently wrote a piece called “Marie Kondo your software stack with open source,” and he's here to tell us more about it.

So, Mike, it's great to have you back. What have you been up to? 

Mike: Oh, not much. 

Martin: Okay… Well, Mike, I can see you've been working on these minimalist tendencies. 

Mike: Yeah, you know. [Neha laughing]

Neha: Mike! Ok! We get it. I’m going to need more than these super minimalist answers. So in COMPLETE sentences—PLEASE!—set up the problem for us? What have you observed as the tension between minimalism and maximalism? How has it changed over time? 

Mike: So we started out minimalist, right? Like way back when, at the beginning of computers there was just sort of a hardware constraint that made it so you had to fit into that hardware constraint. Whether it's processing or storage or, you know, anything else. And then as things grow, you sort of fill that space. There's a thing called Wirth's law, actually, that says, you know, sort of the more powerful everything gets, the more complexity and unnecessary features we tend to add to our software. And the thing is, is that like tending towards maximalism, I feel like it's actually part of this entire innovation cycle where we go towards maximalism to solve big problems and we end up with things like Kubernetes and React, right? And they do this, you know… Facebook trying to deliver mobile interactive things to millions of people means that they have big problems. But then people try to use that for small problems. You know, like React becomes the thing they use for everything, even when it's just a small web page. And so we can actually break that down and take the good from it. We can develop minimalist solutions that are based on our maximalist tendencies. 

Martin: Yeah, you certainly see a lot of, you know, memes about this at the moment where you've got like a Kubernetes stack and, you know, a big kind of like load balancer and all that sort of stuff. And it's serving your blog kind of thing or your one sort of spa webpage or whatever. So what does minimalism look like? You know, say in that example you were just talking about, what does minimalism look like? 

Mike: It really depends on, you know, where you place your view for minimalism. It could be just something as simple as using JavaScript, CSS and HTML. You know, like you stick to the pure stack. There's several frameworks I talked about in the article—HTMX, Alpine, Preact, and they all do what I sort of said, which is they take the basic principles from those big things like React and they package them up into a really small package that does just those things. You know, it's like the Pareto Principle talks about sort of getting 80% of the value out of 20% of the input, and that's what a lot of these minimalist sort of frameworks do.

Mike: I talked to Carson Gross, the developer behind HTMX, and he sees minimalism as an approach that helps developers not just focus on what matters, but also avoid the hidden traps of complexity.

Carson: It's going to be hard for me to not recommend minimalism. There are times, I think, when I'm going kind of maximalist on something, but by and large, I'm an 80/20 style of engineer. So I would just adopt that as the default mindset. And then, you know, when you find that vein of “or” where you're really adding value—at that point, okay, you know, go hard. 

Complexity tends to be at least geometric and often exponential in its growth, which means it grows either with the square of the size of the project or it's exponential of the size of the project. And so what that means is that there's some point you're going to hit where the complexity runs away from you and you're just, it makes it very tough. Once you've hit that elbow and complexity in your system, it makes it very difficult to make any progress. 

The world is big and crazy and you never know what's going to be the important thing. And so if you keep things as minimal as possible or you explore the application and, you know, the feature space and figure out exactly where you should be going. Then when you find that important thing, then you can go hard on it without having all this unnecessary complexity lying around that's holding you back. Trying to be all things to all people is always dangerous. Developers, you know, we tend to want our software to handle every single possible case, and sometimes that can generate an awful lot of implementation complexity. 

Neha:  You know, if people are in the middle of this journey, right, like how does one start to do this? And like what are some of the tools and best practices you've heard about getting back to the basics? 

Mike: If you think about it in terms of a minimum viable product, you want to just deliver what you absolutely need, right? So if you look at that in terms of your software stack, even in terms of your user facing features, it's about right sizing the tools to your problems. If you have big problems, you might need big tools. If you have smaller problems, you can use smaller tools. It's sort of key to set yourself up now so that you can succeed later. So like in the example of the Kubernetes, you know, like people might start with Kubernetes because they want to prepare for their eventual success, their eventual hockey stick growth. Right. But you don't actually need to start with Kubernetes. You could start with Docker, and you can prepare yourself so that you use these pieces that are interchangeable. And when you get to that point, you can swap one out for the other. 

Martin:Yeah. So to quote Homer Simpson or to misquote Homer Simpson, I guess, open source is the cause of and solution to most of life's problems. So why do we think that open source is kind of a great way to start when you’re paring back and trying to get more minimalist? 

Mike:I mean, you know, there's the basic fact that open source means that you can see what's going on. So you can grab pieces that you want and use those pieces. Like it's hard to create lock-in with open source, right? With proprietary software, lock-in is practically a built-in feature if you want it to be, you know. But with open source, a lot of times, it's not only there's no lock in, but there's interchangeability, there's interoperability. Right? And to your Homer Simpson quote, you know, like open source isn't actually necessarily minimalist, right? You could have an open source project that's designed by a large committee to meet all sorts of needs. And that project can be maximalist. Like a lot of the open source projects I talked about in the article, a lot of them are sort of a “benevolent dictator for life” sort of governance system. And I think you'll actually find that that's common with minimalist open source projects, languages, things like that. 

Neha: Yeah, that kind of makes sense to me because if you think about it, constraints are really necessary. Again, you started this segment off talking about how constraints made us or required us to be minimalist. And now we're going back to that, right? And so by introducing artificial constraints, we can be minimalist again, right? So for developers who are trying to go towards this right now, are there any other things you think developers should keep in mind when it comes to minimalism? 

Mike: I think it really matters to keep the long game in mind. When you're focusing on being minimalist, you're trading off that immediate developer speed, right? Like, if you use React the idea is that you can get going real quick, you can get to that minimum viable product very easily. But at the same time, you might be introducing complexity in sort of, you know, being able to understand your code base. Not to pick on React, but like various things like this. They offer an immediate gain, but later you have to deal with the fact that maybe it's not so easy to troubleshoot something. You have to keep that long game in mind and make those choices early on to focus on interchangeability, interoperability, and not necessarily just the immediate benefit. 

Another way you can go is when you're looking at the choices that you make. You have to sort of pick your battles too, right? Like there are areas where you are not going to have enough knowledge and expertise and experience to be minimalist and use all primitive things to achieve what you want to do. So in the article, I talked about Kubernetes packages that are minimalist, right? In the same way you can choose abstractions, you can choose managed instances of things. I talked to one developer who talks about, you know, when he does all sorts of things in primitive pieces, he uses JavaScript and CSS and HTML and MySQL and things like that. But when it comes to infrastructure on the back end, he's all about what he calls “no DevOps tools.” “Zero DevOps tools” I think it was—things that are just managed for him. 

Martin: The trick for me is trying to find the right frameworks and tools where you don't have to kind of reinvent the wheel. You know, that's one of the good things about K3S is that you can go from a sort of container image and use some of those patterns you've been doing and go up to, you know, the big Kubernetes the “full-fat” Kubernetes when you need to. I've been playing with Astro recently, which is a web publishing framework that allows me to pull in things like Tailwind or Bootstrap or whatever I want, you know, when I need to get bigger and sort of scale up. So I think the biggest thing for like listeners is understanding, you know, when you’re starting out, start lean. But, when to listen for those, you know, pain points, as you say, during your DevOps processes so that you can add a little bit of complexity and minimize the amount of rewriting you've got to do. 

Neha: When I discover a new tool, like, I just get so excited about it. I'm like, tool tool, tool, tool, right? Like, “Oh my God. Can you imagine all the things that this can do?” And when I do that, I'm really focusing on the solution. But what clicked about this conversation for me is that you really need to go back to the problem that you're trying to solve. Right? And if you start with the problem that you're trying to solve and then you look at the solution, right, then you can right size the solution for the problem that you're trying to solve. And it gets it a lot easier because it's just, you know, so easy to get caught up in that excitement. So I feel like that's something that I'm really going to, like, take away with me and think about in the future is: What am I trying to solve? Not what problems can I solve with this solution? 

Mike: You know, absolutely. It's like the saying about the hammer, right? When you're a hammer, everything looks like a nail. 

Neha: Yeah, exactly. Alright. Well, before we wrap up, Mike, do you want to give us a preview of what's ahead for you? 

Martin: Sure. First up, I got the chance to write about the collaborative effort to define GitOps that spanned more than six months, 40 organizations and 100 industry experts. Their open source definition attempts to not only save GitOps from becoming just another buzzword, but also to give its practitioners a standard to aim for while allowing the technology to grow over time. If you've ever wondered if DevOps could have benefited from a definition, this one's for you. Next, we have a guide by Saviynt CEO, Amit Saha that explores the world of middleware from writing cleaner, more maintainable code to facilitating chaos engineering. Saha argues that middleware isn't just boring, complicated software for enterprise systems, but rather a way to get the most out of your web applications. 

Martin: Well. Mike Melanson, senior editor for The ReadME Project, thanks very much and we’ll speak again next time. 

Mike: Thanks. It was great to be here. 

Martin: Now for #askRMP, the place in the show where we grab a listener question from you and get an expert to give us their advice. This month, Samit from India asks: How can someone who's just starting out in open source meet their first mentor? For answers, we went to Frances Coronel, senior software engineer at Byte Board. 

Frances: I think there are three primary ways you can find a mentor when you're new to open source. The first—and I think, best one—is just through community. You can start small with a project on GitHub. Once you do get started with a project, you can tackle those low hanging fruit, like asking questions via discussions, providing feedback on an issue, deciding you want to tackle an issue. And from those experiences, you'll be able to learn more about the maintainers. And in my opinion, maintainers often take on the role of being a mentor. So that's the biggest, I think, best way to do it. Another way to get started is through a dedicated program. There are quite a few different organizations like the Linux Foundation. HacktoberFest is amazing. There's the GSOC—the Google Summer of Code program. A bunch of different open source programs that are dedicated to getting folks who are new, or relatively new, to open source, started and actively contributing to these really well-maintained projects. And then the third one is, honestly, you could pay someone to help you become better at open source. There's GitHub sponsor levels where some folks actually offer that—a dedicated time every month or a week—or you could potentially find someone for free. But honestly, it's kind of more natural if you just go through the community route and then you'll probably be able to find one more organically. 

Martin: Do you have a burning question about open source, software development, or GitHub? Share it on social using the #askRMP. That's a-s-k-R-M-P, and it might be answered in our next episode. 

A lot of us came into the community just by taking a leap and starting. Putting our work out there, talking about the problems we'd solved, taking questions, and getting feedback. And of course, that's scary. But it can be even scarier to really put yourself out there to start streaming as you work, especially as a beginner in tech. But for today's guest, that leap has had big payoffs. I met bashbunni at Universe in November, but I've been seeing her work online for about the past year. She's out there in the developer community, creating content for others to learn from, giving back and helping make sure people can follow in her footsteps. 

[Start audio recording]

bashbunni: Oh. Oh, that's… that actually worked! That was incredible.

Prime: Why is there a dinosaur here?

bashbunni: I used a Junk Rift. I dropped a dinosaur on his head… [laughter]

Prime:  I'm into it. 

bashbunni: …and he died. 

Prime: Maybe you got, like, an achievement or something for that. That was great.

bashbunni: That was really good. 

[End audio recording]

Neha: That's a clip of bashbunni joining friend, Prime, in a 24-hour stream for charity recently. It's a good example of the way that she's built a community up around her, one that she can learn from, but also one that she wants to give back to. bashbunni works in developer relations as her day job and is also a developer and content creator. She joins us now. Hi, bashbunni.

bashbunni: Hi. 

Martin: Thanks very much for coming along. It's good to see you again. 

bashbunni: Thanks for inviting me. 

Martin I want to start by asking you about why you chose developer relations in particular as your day job. You know, as a DevRel professional myself. Was it sort of a good overlap between community building and developing? Like what made you go down this route? 

bashbunni: Yeah, so it was actually a bit of a fluke. I was looking for jobs, actually, just as a developer, and my ideal situation would have been working for an open source company where I could continue to do my livestreams. A big part of actually how Charm ended up finding me was through my livestreams. Like building in public—just so happens that I was using one of their libraries, and building in public with that. And so Charm actually was the one who reached out to me through my existing social platforms. So, I guess that also speaks to just what community can do—and what, you know, being a little, I guess, entrepreneurial you could say—can do in the job market. But Charm actually reached out to me and they said, “Hey, would you do DevRel for us?” And I was like, “I don't even know what that is, but I'm going to look into it and get back to you.” And developer relations was perfect because it gave me time that I could spend focusing on becoming a better developer while also continuing to engage with my community and be part of this other community that had the same interests as me as well. It was kind of a fluke, but based on the fact that I'd already had that experience with bashbunni, with managing communities, and creating technical content, and interacting with developers, that gave me a really solid foundation for my job at DevRel.

Neha: Yeah, I think I've always fantasized about coming over to DevRel—

Martin: Oh, hello! You’re welcome. [waving over]

Neha: —but I will, and this is where, like, I let you down, right? I would admit that I am a little bit nervous about starting streaming and kind of putting yourself out there. I'm, like, curious, how did you get that nerve to start streaming in the first place and what were those early experiences like for you? 

bashbunni: Well, so in the beginning I was actually expecting to have, like, no viewers. I had streamed a couple of times just video games, and I had, I think maybe like two concurrent viewers. Me being one of them in another browser, like watching myself. I pretty much actually just started livestreaming so that I could have time allocated every week to working on side projects. At the time I was working and I was in school, so my schedule was really hectic, but I knew that the only way that I'm going to be able to grow at the rate that I wanted to, as a developer, was through actually working on projects. Trying, failing, trying again until you get it right. And that was why I started streaming, was just so that I could have time to work on these side projects because I couldn't work on school stuff on stream, I couldn't work on work stuff on stream. It just—it had to be a side project. The developer space online is actually a lot kinder than I was expecting. Also, I'm pretty open with just where I'm at, like I'm not going to pretend like I know things that I don't. It's kind of like I know it or not, and I think a lot of people kind of respect that. Everyone's been there and anyone who's a jerk about you being in that spot, like, it's their own insecurities that are that they're projecting onto you. So once you kind of understand that, it's really easy to not take those things personally.

Martin: Yeah. The best engineers are always the ones, like, you can tell because they are not like that. They are, “This is cool. Come and have a look at this other thing. This thing is also really cool.” And they're just, you know, they're just interested in sort of showing things off. But the important thing about, like, any community really is that it's kind of this mutually beneficial relationship. You know, this should be… I always say to people, there should be a bidirectional flow of value. Because quite often when I hear people in DevRel trying to build communities, I’m like, “Yeah, but what are your communities getting from you?” So you know, what do you think about your place within that community? What are you trying to give them? What's the value of them coming to you? 

bashbunni: I've been pretty much trying to give back to the community since day one. The easiest and quickest way that I was able to do that was just trying to be a source of inspiration, motivation for people. So it's like, “Hey, even if you don't want to show up, come hang out on stream.” And hopefully me showing you that I'm putting the work in will be motivating for you. And then it's really important for me that I'm using my platform for good. There's a lot of people in the world that struggle on a daily basis. Doesn't matter how privileged they might be. Like there's always kind of these underlying issues and I think that some parts of the world are more affected than others. And I mean that in the sense of like, for example, I worked with the Minds Advisory Group Charity to help war torn countries basically be landmine free. So they're working towards that mission. And with the community, we were able to raise $8,677 U.S. dollars. It's hard to say that that's me giving back, because it's really just the community. So I pretty much approach my streaming, my content as a servant leadership mentality of: how can I serve you? How can I make your life better? Instead of looking at, you know, what can I get from you? Because in reality, when you're putting that love in, you're sending out that positive energy, people who are feeling that positivity, they're going to radiate that. I try and just bring people together. I think that's my role as a content creator, as a community leader, is just bringing people together. I don't have to be the center of attention. I'm very happy—that if there are two people that just get along, they become buddies through the community. That warms my heart. That's the goal. I just want to bring together people who are going to get along and be inspired by each other, you know? 

Neha: Yeah, I think as I've gotten older and older in my career, I've stopped trying to figure out where, you know, what the perfect combo is and what exactly I need to do A, B and C. And I just follow what energizes me. It's surprising if you kind of switch your mentality to just focus on what gives you energy, how much more you can kind of open yourself up to and how much more you can do. So I, like, hear that a lot and what you put into your community. I'm curious, you know, you've talked about like in general, like what you've gotten from the community. Yeah. Can you share any specific things that you've gotten from the community as well? 

bashbunni: Oh, it's hard to say because like they literally—like every single livestream, there's people bringing up, “Oh, you could optimize this better.” Or they're doing pull requests for my projects. I mean, I would say that the best thing that I could get from my community is having such a great network because of it. So I know that if I'm ever out on my luck and I lose my job or something like that, that there's this entire community of people that want to see me succeed. I wouldn't be able to have, like, grown at the rate that I have with my development skills if it hadn't been for all the experts coming in and actually, you know, taking the time and energy to help me get through some of the challenges. 

Martin: Yeah. As DevRel people, it's difficult to kind of do those sorts of things and also, you know, be keeping up to date. Because quite often, you know, we feel the pressure to be creating content and working with the community and educating them. But then how do you keep yourself up to date with what's cool or, you know, help relate to the day-to-day pains of just being a developer? Like, what do you do? 

bashbunni: So, of course, I have chat coming in as my assistant and making sure that I know everything that's going on on the Internet. They're always like, “Oh, have you heard of this? Is ChatGPT going to take our jobs?” Like, panic. But one of my favorite things that I've actually adopted since becoming DevRel is, I aim to alternate my weeks of what I focus on for those weeks. So I'll typically do a content week and I'll basically, I’ll batch all of my content or create all of my content in that week: shorts, long form videos, less so streams. Because that kind of ties into the following week. But anything that I can kind of pre-create, I will do that during my content week. And that'll usually be about 2 to 3 weeks worth of content. And then the following week I'll do development week. So in Development Week, I am a developer. I am looking at issues, PRs, I'm reviewing them, I'm seeing what the community's saying on that front on GitHub. If they're having issues in, like, Discord or things like that, then during the development week is when I sit down. I focus. I'm hacking away. I'm trying to fix things for them and help facilitate that. So I've found that being able to alternate my schedule like that has been outstanding, especially because there are so many context switches in DevRel. That's been the best way for me to be able to both give back with content that's relevant to the community and be able to actually engage with the community as a developer. 

Neha: One part of this that you've emphasized throughout is this ability to kind of create social networks and bring people together. And I think it's so easy for developers to build up this narrative that you just have to be good at it. If you have it, you have it. And if you don't, you don't. So I was wondering for developers who are maybe not as good at social stuff and networking or don't think that they're good, what do you recommend? 

bashbunni: Games are the best ice breaker. It doesn't matter whether it's in-person or virtual. This will always carry over. If you're doing an IRL meet-up, so like in-person, and there's a ping pong table—you're playing ping pong. Easy icebreaker. You can talk about ping pong. You can talk about other stuff while you're playing. It's this unspoken kind of bond that you create. And that's one thing that I've tried to basically bring into the online community as well. We've done a lot of community game nights where we'll do like, people kind of switch into the lobbies and stuff like that. We've got like a queue of people that want to play and things like that and it's allowed me to get to know my community better and it's allowed my community members to foster those relationships amongst themselves. 

Martin: I don't think people realize how many introverts there are in DevRel either, because you have to do like, there's this curious sort of mix of talking to yourself a lot of the time, but also like deep, deep focus. If you weren't a little bit introverted as well as being able to kind of practice being an extrovert, I don't think you could really succeed at like the focused side and being able to get really deep down. Yeah. So I've got one last question for you—can't really leave this one alone. And this is one that Neha and I like to talk about and that's where people’s, sort of, GitHub handles come from. But obviously you're known as bashbunni everywhere. And I get the “bash” part, being a command line nerd and everything but go on, where does bashbunni come from? And how did that handle, like, arrive?

bashbunni: My original handle was ChuggyLou. That was just my gamertag. There's a whole lore behind that. But basically, like, picture an old man who lives in the middle of nowhere, surrounded by cats, drinking beer on his porch. 

Martin: Sounds like me! 

bashbunni: That’s the image of Chuggy Lou. But evolved into bashbunni when I decided that I wanted to do more coding related content. Linux is my first, I want to say, my first love. It's like the first thing in tech that I was really passionate about. So, I was thinking to myself, “okay, I want my handle to have something to do with Linux and what's my favorite thing about Linux?” I loved that I could do everything from the command line. It was the first time that I realized that I had seen package managers and things like that. So I was like, “cool, I can install software from the command line and not have to take a guess at whether it's malware or not (if I'm just installing it from some random site on the internet.” So I really liked that. And then kind of looking at Linux related terms and then of course, “bash,” and I was like, “Perfect. That's what I love about Linux.” And then I just wanted to combine it with the name of some animal so it would rhyme. And yeah, that's, that's pretty much how it came to be. 

Martin: bashbunni, thank you very much for joining us. And thanks for all the work you do putting content out there into the community. Really appreciate it. If people want to follow you and learn more, where should they go? 

bashbunni: I've got YouTube, Twitch, Twitter. So my handle on all of them are “bashbunni” except Twitter is “sudobunni” as in “sudo” like, root privileges. Because I need all the nerds on Twitter to know that. Watch out, ok, root privs. 

Neha:Yeah, exactly. You're the authentic one. You're the original. You have all the permissions, right? 

bashbunni: Exactly. Exactly.

Martin:That's it for this episode of The ReadME Podcast. Thanks so much to this month's guests bashbunni, Mike Melanson, Carson Gross, and Frances Coronel. And thanks to you for listening. Join us each month for a new episode. And if you're a fan of the show, you can find more episodes wherever you get your podcasts. Make sure to subscribe, rate and review or drop us a note at thereadmeproject@github.com. You can learn more about all that we do here at GitHub by heading over to github.com/readme.

Credits: GitHub’s The ReadME Podcast is hosted by Neha Batra and Martin Woodward. Stories for this episode were recorded by senior editors Klint Finley and Mike Melanson. Audio production and editing by Reasonable Volume. Original theme music composed by Zander Singh. Executive producers for The ReadME Project and The ReadME Podcast are Robb Mapp, Melissa Biser and Virginia Bryant. Our staff includes Stephanie Moorhead, Kevin Sundstrom, and Grace Beattie. Please visit github.com/readme for more community driven articles and stories. Join us again next month and let's build from here. 

Martin: Does one of you, like, pick up the bits of LEGO and find them and then hand them to the person? Or do you split the instructions up? 

Neha: Oh, I’m so glad you asked because this is how we take the fun out of everything. We have, like, we have a leader and then we have a sous chef. And I'm almost always the sous chef by choice. 

Martin: That says all about your personality and your style as a manager that anybody needs to know, right there.