Segun Adebayo // @chakra-ui

OPENING QUOTE: The reason why I built Chakra UI, I would say my goal wasn't to make it open source, earlier, to start. My goal was literally to build something better than what I made before at the company that I worked for. And I wanted to go back to that same company again and say, "Hey guys, this is a better solution. Can you try it and see if it works better than what you had before? I'd love to just get your opinion and feedback.”

Brian: That’s Segun Adebayo, creator of Chakra UI, a set of React components you can use as building blocks in your own projects. He’s also the creator of CareerLyft, and this is The ReadME Podcast, a GitHub podcast that takes a peek behind the curtain at some of the most impactful open source projects and the developers who make them happen. I am bdougie aka Brian Douglas…

Kathy: And I am Kathy Korevek.

Brian: Every episode, Kathy and I invite a maintainer or open source developer into our studio to explore their work, their story, and where the two meet. 

Kathy: In this episode, we speak with Segun whose approach to computers and technology always started from an aesthetic perspective: He was interested in what the interface looked like and ways it can be improved. From his earliest days working on a computer, Segun dove deep into the Adobe creative suite, believing that what we communicate is as important as how. With this in mind, he created Chakra UI, a component library for React applications. Originally from Nigeria, Segun is now based in Dubai where he brings his skill and insight to Scribe AI. We spoke about his first interactions with a computer, his passion for design and his aspirations for the future. Let’s start with the origin story...

Segun: What was the first time I used a computer? I think that's my final year in uni. Yeah. And that's the first time. It's very interesting because most of the time, you probably would expect to say when I was eight years old or when I was 10, but this was more like when I was close to 17 or 18. So it's pretty... Took quite some while.

Kathy: How long ago was that? If you don't mind revealing your age a little bit.

Segun: Yeah. Yeah. That's probably close to somewhere between eight or nine years ago, roughly.

Kathy: Nice. So your first computer interaction, your first time really using a computer was eight or nine years ago. And you went from that, and eight or nine years later, you are building your own React UI open source framework. That is fast. That's cool.

Segun: Yeah. Yeah. Thank you. I think most of that really just came from the hunger to actually own a computer, I think since I was 12 years old, I've always wanted to get my hands on a computer. At the time in Nigeria, we probably couldn't even afford to get a computer for me or my brothers. So, I just had to wait patiently, do most of the things on my phone, just do the Google search, just do everything on this very low 3G phone.

And then when I got my hands on a computer, the first week, I think I did quite an intensive amount of overnight, just not sleeping, just, "Oh my God, this is so exciting. I have a computer. Now I'm going to search and do everything I could not do before."

Kathy: Do you remember what you did, what was blowing your mind about it?

Segun: Yeah, I think at the time, I had lots of friends that used to do a lot of Photoshop and Adobe Illustrator stuff then. So I used to be very curious to know, how did these guys do all of these nice effects and put brushes and shadows and shiny objects in Photoshop? So I think the first thing I had to do then was I tried to figure out how to install this thing called Adobe Photoshop on my system. I think it took me close to 48 hours nonstop of watching a YouTube tutorial and the basics of Photoshop and how to use it. So, that was the first software I ever used.

Kathy: That's awesome.

Brian: So the idea of your cell phone or your mobile device being your first interaction, because you mentioned leveraging the phone to do a lot of this stuff. Can you explain more about that and your upbringing and also leveraging the internet in Nigeria prior to uni and getting a computer? What was the sort of thing you had to overcome to get online?

Segun: Yeah, I think, I think one of the biggest challenges I had at the time was just getting access to good internet, honestly. I think that's usually a big one if you're coming from Africa or even Nigeria in general. At some point, everyone has a story where it was really hard to get access to good internet and even just good devices and good computers in general. Yeah.

So I would say that the way I struggled through this was basically making friends. Just making friends and building good relationships with people around you. Of course, most of the time, they either have their own laptops, or they're willing to borrow you or just allow you to use it for a few hours. So I just go to my friend's room and just sit there and chit chat with them, "Can you just borrow me a laptop for a second? I need to test something." And then I just spend the next two to three hours just doing my stuff. And then I go back to my room, and that's pretty much how it went for quite some time before getting my own laptop. Yeah.

Kathy: And you would test... You would do designs and stuff on your friends' laptops?

Segun: Yeah. I remember installing Adobe Illustrator and just installed, I would do a few design stuff just to practice. And then I go back again and go watch some YouTube videos, and I go practice again. And it just repeats itself, just like that.

Kathy: I feel like that is also blowing my mind, that you would borrow your friend's laptop, install Adobe Illustrator, and start doing some work just for a few hours. I think about how long it takes me to set up my dev machine, and it's all day. I'm like, "Oh, I got a new machine, guys. See you next week." That's totally blowing my mind that you did that.

Segun: Yeah. Yeah. Well, I think it was quite an interesting process. I guess those times really formed the foundation of my own work ethic and my life in general, because being able to see challenges as not just a way, a limitation for you, but being able to see them as a way to just figure out an alternative solution, and don't just give up because the situation seems impossible. I can still see where that mindset started forming for me.

Brian: Finding alternative solutions is one of the basic premises of open source. And Segun’s initial love and interest in design remained throughout his years at University. While he didn’t study design, opportunities arose that gave him a chance to expand and explore the tools that would eventually lead him to a whole array of projects, allowing him to hone his skills and build a foundation for growth.

Segun: I used to volunteer in a religious organization. So one of the things I had to do for them, or I volunteered to do for them, was to design brochures, flyers, business cards, and essentially any design related things that they need. So it was quite stressful. So every weekend, I literally get messages, "Hey Seg, can you help us build this nice banner design?" I'm like, "Sure, no problem. I just got my laptop, so let's just do it."

And I go, and then I make those designs. So I think that really helped me. I did that consistently for about two years. So that really helped me build the muscles that I needed. And even when I was out of uni, I came back again to teach the people that were there how to use these tools. So that really helped me master the tools even more. And that was my first intro into design.

It started off as that journey for me. And then slowly, I remember the first time someone I knew before that ended up becoming a potential client. I was literally challenged to... Even doing all of this business card stuff and banner design and Photoshop stuff, which is really nice, but I really want someone to help me design a website in WordPress. Can you maybe help me do the design for that? Let me see if you can try. It doesn't matter. It's okay if you freak out or you think you cannot do it. So I was just like, “Okay, I really don't know so much about designing websites, but let me try.” Again, I just go back to my practice. But this time, I don't have to use my phone I just use my laptop and then I go on YouTube tutorials, “how to design website UI using Photoshop” or “Adobe Illustrator.” Essentially, I did not know tools like Sketch or Figma, all of those tools did not exist at the time. Or even if they did, I probably was completely ignorant that they existed. So I stayed in my little world of Photoshop and Illustrator, and I think I did a pretty good job designing the website UI. And then they were like, "Can you maybe help us figure out how to make this come to life? We're using WordPress and we have this nice page builder in WordPress, can you maybe use that to help us bring this thing to life?" And I was like, "Yeah." So, that was where the nightmare came in for me, because I've never used WordPress and I never really want to use WordPress.

After that experience, because I struggled a lot just trying to build something that you had to know HTML, you have to know CSS, you have to know a little bit of JavaScript as well to tweak some things the way they should be. So I literally just declared bankruptcy on that one. I'm like, "Okay, I'll just do a little bit then I'm done. I'm done with this web... I'm just going to do my Photoshop stuff for now on the web UI if I need to. I'll come back to some WordPress stuff some other time." I think one of the interesting patterns I've seen is the first time when you try to do something you're not familiar with, it's freaking hard and you literally want to give up and sometimes you even give up, which is sometimes fine, honestly. The only thing though is, you have to go back to it again so you can actually build the muscle memory to actually learn the foundations and the fundamentals. So, that's my first intro to web and all of this HTML, CSS, WordPress, and all of these different ecosystem tools, yeah.

Kathy: The process for learning how to use these tools can be very frustrating but it's also so important to get the basics down so that you can start doing more complicated and dynamic things. Despite his initial reservations, Segun eventually did go back to HTML and CSS.

Segun: I remember one of the first things I had to do before going back to WordPress, when I had another client that asked me to do WordPress stuff, I literally went to Codecademy and took the HTML and CSS courses. I took a few courses as well on Udemy, just to learn most of the foundations, because I really wanted to know this stuff. This thing is not rocket science, right? Even though I studied mechanical engineering and I could use Illustrator and Photoshop, the mere fact that I could do these things fairly easily means nothing is impossible here.

So let's just try again and see where it leads us towards, yeah. Even though I ended up not going back to WordPress at the first try, I decided to learn the foundations of HTML and CSS. And I got stuck again [00:15:00] in JavaScript, so that was also another blocker there. And I was just like, "Okay, this thing is not as easy as I thought, because you have to know this jQuery thing."  And then I was like, "I just want to do JavaScript, but now I need to know jQuery. Okay, I'm done for now. I'll come back to this again some other time."

Kathy: Did you do something similar with jQuery when you were... Because there's kind of a parallel between you started on WordPress and then you went back to HTML and CSS and then you were like, "Okay, I want interactions." And you started with jQuery. Did you go back to just vanilla JavaScript?

Segun: Yeah. I went back to vanilla JavaScript, so that was my third attempt to getting... And I think this time around it literally blew up open the gate in my mind when I went back to JavaScript. Because now I feel like I want to really know this thing for what it is and at least master the foundations of this thing called JavaScript and a little bit of jQuery as well. So afterwards, I got very confident doing most of WordPress or even plain old HTML, CSS websites. Or at some point, there are other page builders, like ClickFunnels and I think there's also Squarespace. Yeah, just quite a number of things with those other tools there. And it was pretty exciting to see. I think I learned a lot.

Kathy: There are so many times where we think we may have mastered the tools but there are always new tools to learn. And for Segun, it’s important to not be complacent but to actually seek out challenges. 

Segun: If an opportunity does not come knocking at the door, you build one yourself and just open it by yourself, right? So it's pretty interesting. So I think the challenges I've seen over and over again, it's basically around, after a while when I got into design and I started focusing heavily on UI design and I kind of just dropped most of the HTML and CSS stuff for quite some time. And then I took on the full fledged role of product design. I wanted to be able to take a product from ideation to live production site as fast as possible.

That was my goal and I joined the company to do that. The biggest challenge I saw there is each time I did a UI design, it basically took almost two times or even three times the time it took me to design, it took that long for the engineers to actually produce the code, right? So it feels like, "What's going on here? I spent so much time trying to understand how to design this stuff." The time I learned Figma and Sketch, so that was pretty easy for me to use because coming from the Photoshop and Illustrator, there's Figma and Sketch. So, a breath of fresh air for those that are familiar with these tools, right? So I found it very easy to design UIs for mobile apps and for websites, but then the engineers or my engineering friends, took almost two or three times how long it took me to make the design come to life in code, right?

So this was another interesting challenge. And at some point I knew that my... Actually, I think at the company I worked in, our job was literally on the line because they were like, they're running out of money and they need to ship this product very soon. And then we're just taking this long time to ship the product. And then I had to talk to my friends like, "What is the bottleneck here? What is causing the problem? Why is it taking so long to translate design to code?" At some point they were using some UI library that's pretty rigid. I think at the time, I'm not sure if it was Material-UI or some other like Bootstrap. It was like, "It's super hard to make it look like the design that you gave us because we have to do lots of CSS and put a lot of important all over the place just to override styles and just looking just right the way it looks in design." Right. So, that's the main bottleneck I saw.

And then I was like, "How can I help you guys solve this problem?" Because one of the core principles I always have is from when you do design, we tend to think about having empathy for your users. Customers having empathy for the business, those who are going to sort of use the product. But less often, or I don't really see too much in practice that we have empathy for our colleagues. People who actually take the work itself and transform that to code, right? So that was the first time I think I learned the principle of not just having empathy for the business or the customers, but for those around you and those that you work with, right?

So I decided to ask them, "What's the problem you're having here and how can I help make this stuff a lot... Let's just make this process seamless. As seamless as possible essentially." So it took a long time, but it turned out to be that building an entire design system and a UI library in design first and then translating that to code actually saved them a lot of time. And at the time it wasn't even Chakra UI, it was just some dummy design system that I made on my... "Okay, let's just try this thing. I'm trying to learn this thing called design systems. And I'm reading lots of blogs and articles and watching videos. I just made this thing called, this UI kit in Figma. Can we just maybe use this as a guideline to help us make better decisions and actually build better UIs?"

And it started off as a suggestion. It turned out that the team really liked it and it actually helped us go faster. So I decided to, I think at that time I took a bold step to quit my job. I wanted to focus on this problem for some time because it seemed like it would be an interesting problem that not just my colleagues had, but somewhere around the world or someone else in Nigeria somewhere, or even just all over the world, it might be a fairly common problem or challenge. So let me take some time to see if I can come up with something slightly better than what I proposed at my previous company. From there on, it's sort of like the rest is history and I'm sort of here right now.

Kathy: Yeah. That's quite the path. You touched on something that I think is so cool and so important, which is not only having empathy for your users, but empathy for your colleagues. And one thing I love about that, and I don't know if you've thought about this or if this is in your philosophy for what you do with Chakra. But there's something about the way you talked about Chakra, which is we want to empower developers, not only to build things that are accessible, but also build things faster and more compliant, more secure, et cetera. But there's the design component to it. And one thing I really love with you saying, "Have empathy for your colleagues," is that I imagine it can be so frustrating.

I know it can be really frustrating when you have a lot of importance all over your CSS, for me. And I feel almost like a little bit of a failure when that happens. I feel bad about my code and bad about myself as a coder. So, what I love about that concept of having empathy for your colleagues is that what you're doing is helping them feel better about themselves as coders. And I wonder if you feel the same way or if that's part of the reason why you built Chakra?

Segun: Yeah, for sure. I think this goes way down to one common advice my dad used to get me. Which is essentially, when you find yourself in a place, you have to do everything in your part to make the place better each time, right? Which means, anywhere you go your goal is just to make a meaningful impact so you'll never be forgotten. If you just come and do the work they tell you to do, you're essentially just doing the bare minimum and you're not leaving any meaningful impact there. So it literally came from the fact that at the company that I used to work for, I think one of the common patterns I started to see, especially in the product development process is it starts to feel like design and development are sort of in some battle or they're sort of constantly involved in arguments back and forth there. And it starts to feel like a competition of who can ship this stuff faster. Design does it super fast and engineering is super slow, what's going on? And it starts to feel like there's a lot of friction between both parties. And one of the things I've learned is, instead of trying to compete with your coworkers, literally, that's why you're called coworkers or colleagues. You're meant to work together. You're meant to collaborate. So you're meant to literally feel the pulse of one another, know what's making you struggle with your work, and how can I help? Essentially, these are the two questions I like to ask a lot, even from my friends. So I do that a lot, in life as well, not just at work.

So that really informed most of the decisions that I made or I put into Chakra UI. And I'd say really, the reason why I built Chakra UI, I would say my goal wasn't to make it open source, earlier, to start. My goal was literally to build something better than what I made before at the company that I worked for. And I wanted to go back to that same company again and say, "Hey guys, this is a better solution. Can you try it and see if it works better than what you had before? I'd love to just get your opinion and feedback." And the moment I said I'll share it and show it to them, I could literally see light bulbs come off their eyes and like, "Oh my God. This is so awesome. I will never have to struggle with CSS. I'll never have to know about keyboard navigation, accessibility, and all of these different things that are so freaking hard to understand."

And what makes it hard is not the fact that it's technically hard. What makes it difficult is the fact that you have a product to ship, and you have a deadline to meet at work. And taking a detour to fix all of these different aspects, it's quite something. And you'll definitely not meet your target. And ultimately, you'll get fired if you want to start doing all of those kinds of things. So I feel like that really resonated with them. And they really loved it. And I think just that small interaction made me feel like, if you build something and you have, I call it a minimum viable audience, which is a small group of people who use your product and a few are really excited. You can literally see them super happy about what you made. I think that is enough to actually make you feel like this is a meaningful product and this is going to make an impact. So that really gave me the courage to say, “Okay. If this can make this small group of friends who have been in the front end development space for close to 5 to 10 years, if it can make them happy, there's a high chance it would be meaningful for someone out there as well. So let's just put it out and see what comes off.”

Brian: When Segun launched Chakra on Twitter, the response was resounding and overwhelming. But the process leading up to that moment wasn’t necessarily straightforward and it took a fair bit of bravery and trust.

Segun: A lot of things went through my mind just before hitting that button, honestly. And I can tell you. So, after showing this to my colleagues, I told them about the possibility of making this open source. I think one of the consistent responses I got was, "Are you really sure you want to do this? The open source space is not that forgiving, essentially. If you put something out there that doesn't make sense, you'll literally see people on social media bullying you and telling you that this is crap. You don't want that in your life right now. I think you should just do your design stuff and help people from time to time."

Essentially, what I could understand from this, the response I got, the way I interpreted that was more like, just fit in and don't try to go beyond your comfort zone. That's the way I interpreted that. And honestly, that was very anti my own personal principles. So I wanted to just go against that and see what happens. Essentially, I was fine if anyone told me that this doesn't make sense. I'm like, oh cool. At least I have my colleagues here that use it and they're happy with it. It might not be for you. So that's completely fine. So I had to literally talk myself into what could possibly happen or what could possibly go wrong before I hit this Tweet buttons.

So I wrote a tweet. I think I wrote it close to three days before hitting the Tweet button. But each day, just to press that Tweet button, literally, I just got quite nervous, honestly. And that was because before that, I never had any experience with open source, or I've never used GitHub that extensively. So, it was essentially my first time just using GitHub for what it is, and actually building in the community and building an open source project. So I'm not sure I had a project on GitHub at the time as well. So it's like, this is the first thing I put out there. And I feel this might turn out to be a huge failure.

But then I think what really gave me some comfort is essentially that, it's just a rule of thumb I always have in my mind, which is the fact that innovation and failure is essentially inseparable twins. So you cannot do anything innovative without the fear of failure, because you're trying to do something that might not work. And having the courage to do something that might not work, in the face of everyone discouraging you, it's essentially what I would term a courageous person or an innovator. So I just wanted to take that leap of faith there.

And I just hit the Tweet button. I think what I did after hitting the Tweet button, I turned off my notifications. So I literally just put my phone on airplane mode. And I told my friends that I did it. I released this library publicly. I'd love to celebrate that no matter how small it is. So we took ourselves out to McDonalds and just, let's just get some nice burgers and just celebrate this thing that I’ve made. And so I literally put my phone off because I was super nervous. I think one of my friends could see that I was super nervous, and just challenged me to just turn on your notifications. What's the worst that could happen? I mean, if most people say they don't like it, fine. You just delete the tweet and move on.

So I just decided to put it on. And what I saw was quite surprising. And I could see that quite a number of people in the community retweeted that. And I remember a few of them, I think I remember Prosper from the community, even Guermo from Vercel and… So they took that and retweeted. I was really impressed and happy, I guess. That's my first Twitter and GitHub and community experience. So, that was quite meaningful. And obviously, I mean the side effect of that being as more people start to see it, more people want to jump on it right away. And then people are filing issues at the speed of light, just because you released this new library. And I think I spent the next two to three days without much sleep, just fixing issues and trying to get it to be stable.

Kathy: Segun is so spot on. True innovation comes with risk which can mean the potential to fail. But also a great potential to succeed. Chakra was well received and inevitably that led to a lot of work. Segun knew this may be the case but it was hard to really predict and it certainly came as a surprise.

Segun: I think after spending the next one to three days just closing out issues, responding to pull requests. I'm like, this is quite a lot of work. I never saw this coming. And then the issue number keeps growing. At some point, I tried my best to keep the issue numbers below 20. And each time I try to take it down to from 20 to zero, it grows back up to 25 or 30. I'm like, what's going on here? I mean, I feel like what I built is pretty good enough and works for most use cases. But then that's not the truth, obviously. People tend to use your projects in ways you don't expect. And they have certain expectations of what you build. And if it does not work that way, to them, it's a bug. They just open issues and try to see if you could help them fix it.

I could say, I also got slightly introduced to this, I would say, semi toxic part of open source projects, which is essentially people telling you that, "If you don't fix this thing, I'm not going to use your library. You have to fix this right away." And I think, essentially, at that point I literally logged off GitHub for a few days.

And so, no one can put you under pressure for what you built. This is a free open source project. The code base and the source code is open for you to see. And you can contribute to it because I literally wrote all the code there from a much more beginner mindset, trying to solve a meaningful problem. So that means that you're not going to see any magic in the code base. It's fairly like someone that's just trying to be as simple as possible. So that's what you're going to see if you check the code base. So that means it's fairly easy to contribute to the project. So I'd just appreciate more contributions or pull requests if you want to see anything fixed. So that was my initial stance.

And when I came back from taking a break, I just evaluated some of the issues and tried to prioritize. I think that's a meaningful skill that I had to learn, which is not all issues are equal. Not all bug reports are equal. You have to tend to prioritize them, which ones are bugs. And this way, this is where GitHub really shines, it's being able to tag or label issues and pull requests. This is a high priority. This is low priority. This is a bug. This is just a question, we can close it if we answer the question. That really helped me just get comfortable just keeping the project alive for some time.

Kathy: Cool. I have so many questions about that. So you mentioned that, you mentioned this twice. When you get a little, maybe overwhelmed or nervous, you shut your notifications off. So you shut your Twitter notifications off. You took a break from GitHub. And we had another guest on the show, Gina, that talked about this from a maintainers perspective. When you get overwhelmed or frustrated or pissed off at some of the contributors or some of the responses...She actually keeps a punching bag in her office, and she'll go and take out her aggression on the punching bag. And that helps her through it. Is there anything, like I think taking a break is a really, really great thing to do. Taking a breath. Do you have any other advice for people going through a similar situation?

Segun: Yeah, it's really like, I think this is quite more like, a personal response. How you respond to stress and anger and anxiety, I think it varies from person to person. I can only tell you what I do personally, it might not work for you. That's the sad part there. But what I do essentially is to just turn off all my notifications. Right? So even to date I have some notifications turned off, even now that I'm not stressed or I don't have anxiety or things like that. So what I typically recommend is just to leave your laptop and go out. Go have some fun with your friends. Essentially, fun that will make you laugh. Because one of the things I've seen is when you're in your stressed state, you basically don't want to laugh.

You're just super straight and super cold. If anyone comes around you and they're trying to make you laugh or say something funny, you're just like, “Dude, you don't know what I'm going through.” In your mind it's like, “you cannot just be saying serious stuff around me because I'm so tired and I'm so drained.” I prefer to just do more high energy activities, go out, take a long walk. Go watch something funny or do some really scary exercise that literally shake off all of the funny feelings that you used to have there. Here in Dubai there's quite a lot of things to do. So I just call a few of my friends to meet. Just do any crazy stuff, any crazy activity around that we can go for. That literally rock everyone up and makes us all laugh, and just helps me forget all of that stress.

Kathy: Yeah. That's really cool. You said something else that I just think is brilliant. Because I'm a product manager and I loved this minimum viable audience. And I wonder if there's something to that, that you can talk about a little bit for us that might... If you release something new, a beta or whatever, to the smallest amount of people, maybe that helps alleviate some of the pressure and some of the overwhelm that might come from that. And so, the product manager in me is itching for you to expand on what that means. How many people makes a minimum viable audience?

Segun: I think that answer varies also. Because sometimes I hate to say the answer varies, because that's the ultimate answer to almost any question, “It depends.” So when you have an idea where essentially you have this idea you want to bring 

to the world, maybe you've seen existing solutions before and you're trying to make something--you want to put it out there in the world. There's usually an assumption that you make. You're making an assumption that, hey, maybe the way CSS used to work is not user-friendly.

And I want to just try to invent some new way of writing CSS that makes it really easy for people to ship product. So let's assume that's the idea that you have there. That idea makes certain assumptions, and it's only fair and it's only right for you to think that my idea might be wrong. Right? So the goal is, you're not looking for the idea that is the ultimate and works every time, you're only trying to provide an initial hypothesis to say, what if we could write a CSS this way, would it maybe make a meaningful change? Or will it help people ship products faster? Right? So the idea here is not to be right at first, you could be wrong. But the goal is to be less wrong over time, right? And true feedback and attrition, you'd probably be able to knock off all of the wrong sides of your idea and eventually transform that into something meaningful.

Right? So the reason why I said that is, because you already have the mindset that your idea might be wrong. You want to find a few people that are very open-minded, they're not super critical people that will judge you and judge your idea. There's so many people out there like that, right? So you want to find the few friends that you have that know enough to give you quality feedback about your idea and hypothesis. That's what I would say makes up this minimum viable audience. Essentially, these few people that are open-minded people, people that are not afraid to tell you whether they like it or they don't like it. And also people that are able to support you to make sure that your idea works out there. I had just, I think close to four or five friends that I could reach out to. They were all front end engineers, I think one of them was a full stack. 

So I consider them my minimum viable audience because I could trust them. I trust that when I tell them my idea, they don't try to take that and maybe trash my idea, or say I'm not a smart person, or talk down at you essentially. It's like, you want people that would help to empower you and actually want you to succeed. So that's what I mean when I say minimum viable audience, especially as it pertains to open source. Because there's a high chance that your colleague might need that open source library you want to make. So it's always good to just have a quick chat with them to get that pulse whether this idea might make sense or not. I think that really helped me when I started getting that initial feedback. Eventually the feedback turned out to be really good for me, super positive. And there's almost no negative side to that. So that gave me the courage to actually continue in this direction and just make that go live.

Kathy: Yea, that’s fantastic.

Brian: Excellent.

Kathy: Cool, thank you.

Segun: For sure, thank you so much for having me. I really enjoyed this conversation. Thank you.

Brian: It’s been so fun to speak with Segun and have him on the ReadME Podcast. To learn more about Segun and Chakra, please visit chakra-ui.com. If you’re curious to learn more about Segun, read his story on the ReadMe Project. Just go to github.com/readme.

I am Brian Douglas, and I am a developer advocate here at GitHub.

Kathy: And I am Kathy Korevek and I work in product. The ReadME Podcast is a GitHub podcast that dives into the challenges our guests faced and how they overcame those hurdles. In sharing these stories, we hope to provide a spotlight on what you don’t always see in the lines of code, and what it took to build the technology that inspires us all. 

Brian:  It's been really great spending time with you. The ReadME Podcast is part of the ReadME Project at GitHub, a space that amplifies the voices of the developer community: The maintainers, leaders, and teams whose contributions move the world forward every day. Visit GitHub.com/readme to learn more.

Our theme music has been produced on GitHub by Dan Gorelick with Tidal Cycles. Additional music from Blue Dot Sessions. 

The ReadME Podcast is produced by Sound Made Public for GitHub.

This episode is the final one in season one. We've loved talking to such inspirational, smart, and fun people. And we look forward to doing more of that in the future. So follow us on Twitter or LinkedIn to get more updates on this podcast and all things GitHub. Thanks for listening.