Hello, world! Join us as we talk about what this developer experience thing is all about. For this episode, we're joined by Jamon, CTO and Cofounder of Infinite Red as we reflect on how the developer experience he grew up with as a young coder has since evolved.
The hosts ▻
Our guests ▻
Things mentioned ▻
Let's chat some more! ▻
Hello, world! Join us as we talk about what this developer experience thing is all about. For this episode, we're joined by Jamon, CTO and Cofounder of Infinite Red as we reflect on how the developer experience he grew up with as a young coder has since evolved.
The hosts ▻
Our guests ▻
Things mentioned ▻
Let's chat some more! ▻
Hello, you're listening to the DevX podcast a place to learn all about developer experience hosted by me, Pauline Narvas
Mike:and me Mike Nikles from Gitpod. It's great to have you join us. We'll be doing a deep dive on DevX along with industry experts, asking questions, like what even is DevX, what is good DevX? What is bad DevX? And most importantly, why should we care about developer experience?
Pauline:The aim of this podcast is to answer those burning questions and hopefully get you as excited as us about this growing developer experience space. Let's learn together to help bring back joy and speed to our developer workflows and get the job done. Let's do this! Tell us a bit about yourself ,Jamon.
Jamon:Thanks for having me on. I'm Jamon Holmgren. I'm CTO co-founder of infinite red. We are a consultancy, like react native consult. Based mainly in the U S we have a couple of stragglers here and there outside of the U S but I live in Washington state, just across the river from Portland, Oregon in the Pacific Northwest. I have four kids and I live on three acres. I have a little tractor that I drive around my three acres, which is fun. And I've been coding since I was 12. And I'm 40 now. So I've been doing this for quite a while.
Pauline:Wow. That is a long time. Oh, I started coding when I was young as well. So I always like it when people say, ah, I started coding when I was 12 or 10. I love it. I'm encouraging a lot of young kids these days to do the same, because it's definitely changed my life. Welcome to the podcast.
Jamon:Yeah, thanks so much. I appreciate it. Pauline and Mike. It's very cool that you're doing this podcast. I love content, I love media, especially about the stuff that I nerd out about, it's really cool.
Mike:Really excited to have you on the podcast. I think there's a lot of talk about, we're still early in this journey, but there's a lot of demand, I think for people who want to join. Super excited to have you here. To get started let's kick things off with the first question. So how did you personally get started with developer experience and more broadly, what is developer experience to you?
Jamon:I think developer experience of course, is you're always going to have a developer experience. The question is whether it's going to be good or bad or indifferent. When I first started, I was doing, you know, Q basic, I didn't even have the internet. I had to look things up either in books or like Q basic, what they called online help, which was not online help. It was just like help that you could hit F1 and you'd, you'd get a help page. And there were little things too, where like Q basic would do things like if you changed the capitalization of a variable, it would go through your whole project and update all the capitalization of that same variable in your whole project. It would do that automatically. So that was a developer experience thing. From the very beginning, because it was just me. I could craft the developer experience the way I wanted it. Then later when I started getting into web development, you know, much later, I of course I was starting with PHP and there were a lot of really rough edges in PHP. There would be things where all of a sudden, you just have a blank page. It just wouldn't render it all. And there was, there were no errors whatsoever. They would just swallow errors. And wouldn't tell you why. And you had no idea where to go and look and try to figure this stuff out. Okay. I lost many hours over many years. I've been professionally coding for 16 years. And I can't tell you how many hours I've lost because of bad error messages or tooling that doesn't have good documentation, or the API is unintuitive. I guess just from my own standpoint, I wanted good experiences with the tools that I use. I would use various tools and they would actually have good experiences and I'd be like, yeah, this is possible. You can do this. So I guess it's been infused through my journey entirely throughout when I've been coding.
Mike:You mentioned the F one button that was, you know, certainly my go to as well when I started probably around the same time as you did. And I think what I've seen recently is the command K, or control K, coming back on websites where you either get a search or a command palette. And I'm like, oh my God, this is such an, you know, a small thing, but it makes a huge difference when you can start using the keyboard and just be so much quicker. A small thing, but a huge impact.
Jamon:Yeah. Having things right at your fingertips is super important. Even things like here's an example of something that seems small, but can be a pretty big deal. And that's, you have a read me and you mentioned something and you link to it. You know, you don't make them go Google it, you don't make them figure it out. Maybe you give them a little definition of what it is or you link to it. So it's easy to go and just research more. You don't assume knowledge, you don't assume context. Uh, you, you kind of like, oh yeah. If you, if you don't know what this tool is, here's a link to it and go research it here or you provide your own exploration.
Mike:I think that also goes for error messages. Like I love error messages that well, first of all, if they tell me what to do even better, but at least have a link to a page where I can see that's the error. That's why it happened. And this is how I can mitigate it.
Pauline:Yeah, I was going to say so I was coding a bit later when you folks start, but, um, I, Wait, that's not it!
Jamon:I'm joking, I'm joking!
Pauline:Omg!? It's really tricky because every time I talk I'm 25 years old just to say out there. And every time I talk about like my experiences, when I was younger, people are like, oh, I have like, This is I, you know, I've seen way more than you have, but I saw the end of like, especially PHP. Cause I started learning like HTML, CSS and JavaScript - the basics. And then I wanted to start blogging and WordPress was the thing that I use. And so I found myself in this rabbit hole of creating PHP, WordPress themes. And I remember a similar thing where I wouldn't get any error messages and I couldn't see anything. My whole website looked like was just a blank page. And I was like, I don't know what happened now. All of my blog readers, can't see my blog. I used to also upload all the files via FTP. It was that whole painful process. But now , my blog runs on Next.js and the difference in terms of developer experience from the early days of PHP, when I was creating WordPress themes, I don't really know the state of it currently, but then moving on to Next.js. Yes. It's just blows my mind. And that's essentially what developer experience is.
Jamon:Totally. And to be clear, I'm not discounting at all your experience and your total. The things that you're doing are all the same stuff. Obviously, you know, like struggling through the early days, maybe in the nineties and two thousands and stuff, there were challenges that have informed how I do things with the debugging and whatnot. But honestly, coding has moved on and there's new tools, there's new techniques, there's new frameworks and stuff like that. And I love hearing from people of all experience levels and ages and everything. Everybody has something to contribute.
Pauline:Yeah. Absolutely. And that actually brings us in nicely to my next question, which is why should people even care about developer experience?
Jamon:If you are contributing in some way to developer experience. That would be things like documenting things properly, commenting things properly, designing APIs that are pleasant to use, developing frameworks, developing libraries, any of those things. And I've done a lot of open source. So this is something that I've really thought about. Any of those things, you're sort of like giving a gift to the user who is going to be using or the next developer, which by the way, that might be you. So like you're helping your future self out as well. When you come back and use it, you want it to be pleasant. You want it to be interesting. Coding is hard enough. Even with well-documented, well-designed libraries and whatnot. So, take the extra time to do that. I just think that when you have a poor developer experience, it increases your, the developer's mental fatigue throughout the day. You can't do as much if you're just banging your head against something and like having to Google and look through articles from 2018, that don't seem to apply anymore and stack overflow questions that have two answers that neither have anything to do with the question. These are things that we've all dealt with. They increased the fatigue. They increased the frustration level. All of those things, coding is hard enough. Let's not add more to it. Now I will say that, it's not easy, like designing a really good developer experience takes intentionality and it takes effort. If you just try to get it done and move it out, the default is probably going to be kind of poor.
Mike:I really liked that you touched on the the fatigue or I think a more broader term, like team morale and how developer experience impacts that. Back in the days when I was hiring people for teams, you noticed that right away. If you have an experience where people joined the company or the team, and they're up and running very quickly, that just gives such a different impression. It's a lasting impression too, right? If you take a week to set up your project, and then you just have to mood of like, "ah, this is all slow and old and antique. So I love that you brought that up. This is very important.
Pauline:Yeah, and I don't mean to plug Gitpod. I don't want to do it, but in this case, it's right there. It's just reminding me that it's happening. I don't want to bring Gitpod too much into this, but it reminds me of the days when I first started as a DevOps engineer in my first tech job, I spent almost two weeks onboarding onto the platform team. And I remember banging my head against the wall, just really frustrated over the fact that I couldn't get my developer environment set up. It wasn't a good experience for me because everyone was just sending me all these random Confluence links that were like years old, that no one had updated just like feeling like, "oh, maybe I'm not a good DevOps engineer. I can't be a good DevOps engineer because I can't even onboard myself," but then the whole process of onboarding it isn't very good. Whereas like now that, when I switched jobs from being a DevOps engineer to then moving into Gitpod, I literally onboarded in a day that blew my mind. And for me, that moment was just like, wow, that was really good developer experience there's there was moment for me where I was like, this is how everyone should do it.
Jamon:I love the idea of Gitpod. Haven't used it extensively myself, but one of the things that really caught my eye about Gitpod was the fact that you could just have a button on your GitHub repo and you just click it and it sets up an environment for you. Like how, how much more like that? That is amazing. That's like incredible.
Pauline:Every day I use it I'm just like what, how, and I'm learning from our like engineering teams, every single day of our, how it's made, all the different components. And that just blows my mind. It's incredible. But yeah, for me, that has been maybe I sound really biased, but it has been the best developer experience I've had this year, since I onboarded. Yup.
Mike:Very smooth. So let me move on. I'm moving on.
Pauline:Let's see. I didn't plan that. I just, it just came in and just sparked when you were talking.
Mike:One thing I'm curious about is from your experience, what is the best DevX or developer experience you've ever experienced? Whether that's something you build or your team, or that you've seen somebody else do, but what can I S you know, mind blowing in your opinion?
Jamon:You know it's this kind of interesting little library for react native, and it's called react native pop overview. And this is just, I mean, I don't know if it's the best, but it's definitely the one that really caught my eye. React native pop overview, and it's by someone called Peter Stephie and it has a fantastic README. Like you jump into it, it's got like a really nice little pitch for why you would use it. It has a table of contents, the features that you can use with it, and then has a demo app. Like you can just download a demo app it's already included. You can play around with that installation usage, a really nice API. And then what's really cool after that, is that it just sort of builds in the usage examples. It has a short like paragraph and a code example, and then it moves to the next thing. And each time it's like building on the previous one. Okay. Now you want to show a pop over from an element and allow manual dismiss. Okay. Boom, here this is how you do that. And by the way, the code example, doesn't just show what you would add. It shows the whole code example. So you could just scroll to it. Copy just that you don't have to let go and piece together things. It could be the greatest README I've ever seen it has props, that show the type, shows the default value, a description and then change log and whatnot. Very, very well done. I try to structure my READMEs a little bit more this way now. I liked the fact that there was an expo app included with that. So you can go in there and spin it up and see how it looks and whatnot.
Pauline:That sounds really cool. I need to check that out. The way you described it reminds me of the DevX Digest newsletter, our latest edition where we took content from Ellen who gave a talk about the psychology of developer experience. And she said something about how a good developer experience is when something like a tool or framework, whatever it is, isn't too difficult to onboard yourself. Isn't too easy because developers would just switch off and it also takes into account different learning styles. So there's like videos, written documentation, whatever it is. And also this concept of progressive disclosure, which provides developers bits of information at a time, not everything at once to overwhelm them, but bits of information, every single time so that it helps developers get into this into flow states and they're more likely to then want to find out what's next, if that makes sense.
Jamon:The concept of progressive disclosure is a very key one when you're doing documentation too often, it's like, they want us, they want to drop right into like, "Hey, here's the entire philosophy of why we would build this thing." And it's like, "I don't even know what it is yet. Why are you hitting me with this?" show me something that catches my attention that gives me a little bit of like, "Ooh, that's cool. I want to try that." And then gradually when the timing is right, like unveil the next thing. I
Mike:think the really good example of that is games, right? Where you learn how to walk with a character or whatever, and then maybe after two hours of gameplay, you learn how to ride a horse and then you learn how to ride a dragon. I recently played Zelda, obviously. So Well, talk about that. I'm way behind it anyway, but the point is you know how to introduce it very slowly. And I think that the parallels here, I started to see a lot more of that. And I read about game theory and stuff earlier this year. And it's just a very fascinating to apply that to developer experience generally, or product onboarding or so many other concepts. They really nailed how to do that well, and I think many of us can learn quite a bit on, on how to do that, especially in developer experience where there's so much to learn certain intervals.
Jamon:And there's only sort of like a rate of absorption in your brain, you can't learn too fast. We may have different like rates of learning, but none of us can just dump it all in our brain and then be like, okay, we're good to go. You have to pace yourself a little bit. And people have to realize that about things like READMEs. So I recently released a library myself. And it's called React Native ColoLoco. You're writing components in JavaScript, jSX TSX. But you can also drop down to native code, so you can write it in objective C for iOS or swift, and you can also write it in Java or Kotlin for Android. And then you can take both of those things and then expose those new components or whatever to JavaScript, and then just include them in your JSX. Like you would any other component. The problem is that often you have to go to XCode and load up XCode, you know, apples gigantic IDE you have to load up Android studio. And not only that, but the folder structure of figuring out where to put these native files and linking them up and exposing them to JavaScript. The documentation isn't great on the react native site. There's a lot of old articles, it's a nightmare. Like you, you try to go in there and try to do that. Speaking of developer experience, not great. So React Native Cololoco is we're going to co locate. That's where Cola comes from. We're going to co-locate our native files with our JSX files. So our JSX, you know, like my component dot JSX, you're going to drop in my native component dot Kotlin. Right. And then it becomes available automatically. The whole idea behind React Native Cololoco is to improve the developer experience around writing native modules and bringing those into your JSX. So when I wrote this, I really wanted the documentation to be fantastic. And I actually spent Literal hours. And this is not something I normally do, but literal hours on the README and I like really try to make it like impactful. So for a react native developer, when you come in there, I explain what it's about and then I have a screenshot of your TSX file, for TypeScript and right next to it, there's this Swift file. That's something that I react native developer would be like, what, how do you do that? And it just sorta like peaks their interest. And then I have a screenshot of it working. So you can actually see the native module working in the simulator. And then of course, installation usage, and like gradually adds more and more information around it. So it's not perfect, but a little things like there's some manual instructions, but I didn't want them to take up the whole README. So I hid them behind a details expand, you can click on it to see them, but they're out of the way. I didn't want the README to just be full of stuff that you didn't really need to do if the automatic installation worked. I spent a lot of time on that and I felt like, it's a lot of time that I wasn't coding, but it was worth.
Pauline:I'm glad you shared that tool and your process with it, because I think it is really important that people hear this because I think it is, developer experience is still quite a new thing, although it's like a new term that everyone yeah thinking about, but it's a thing that has been around for a long time, except now we're shining more of a light on it because we don't want to experience those pain points again. And it sounds like you really took a nice and meaningful approach towards that, which is great. And I hope people who use it will find that super useful and I'm sure they will.
Jamon:Yeah. That's my hope as well. Also my hope is that people can find the edges of it and then contribute. And that's another piece of dev X that I think is probably missed and that is what happens when you have a problem? Not only like the error message, I think that's important. And I've built in some really helpful error messages into the tool, but also what happens? Do you tell them where to go? So like in my error messages, I haven't done it a hundred percent in this one, but I try to be like, if you still need help, go to community.infinite.red that's our slack community. And asking there, I do that on our ignite react native boilerplate, and people will join the community and ask questions in there. And because it's a self-reinforcing thing where the questions kind of are people can answer these questions if there's a problem. Also, how fast do maintainers respond to issues and discussions? Now I maintain a lot of Open Source. And there's some open source libraries that I respond to quickly. And there's some that I probably haven't looked at in way too long. You only have so much time in the day, but trying to give them some venues, some ways to get help and even like, how would I pay someone to help me out with this? Because sometimes that's a viable route. So all of these, like it's almost like the ecosystem of your library or your code base or whatever is a part of the developer experience as well.
Mike:And you really have two different kinds of users, right? Do you have to, one stat want to build a react native application that need your framework or plugin, but then you also have to people who want to help you contribute, so how do they get up and running? And what's the process for them to be able to do that? I've had that many chats in myself where I see something I'm like, well, I can contribute a fix to it. I started reading a CONTRIBUTING.MD. No, it's just, or it's it, or it's documented. I'm like, no, actually. I followed a process, but then it doesn't work and then I'm definitely done. So that kind of, you know, it's really so many angles to the whole concept of developer experience.
Jamon:That's a fantastic point. I feel like that's one of the things I tried to do and it sounds like Gitpod sort of almost like productized this idea. All the developers that I taught and mentored was if you're going to make an app or a S or a library or anything, try to build a set up script. And make that setup script. Even if it's just literally you can start with it, just echoes out the instructions of what to do. Like that's all it does. You just run, set up and then it does that, and then you can start automating pieces of it. So it's like it checks to see, do you have the right version of NPM? Do you have the right version of node? Is Ruby installed or whatever you need? Then it can give you helpful error messages. So imagine if the instructions are closed down, the library run, been set up, that would be amazing. And that's really cool. Or, you know, click the, Gitpod button. That's another option, but like these are things that really increase the likelihood that someone's going to contribute back to your library. If you're having problems where. I have these bugs, people are filing issues, but they're not contributing pull requests probably it's because you're contributing experiences, not as good as it should be.
Mike:And did the real challenge we have as maintainers of the open source projects, is that we cannot really measure the amount of people we lose by not having a good onboarding experience because they just never show up. But if there was a way to read people's mind when they leave the project website and be like, why did you leave? Oh, you actually wanted to contribute. And then couldn't. That would really give some more meaning to the whole developer experience slash onboarding. And we could probably get more funding for that kind of stuff as well in the industry to make it better across the board. Yeah, interesting
Pauline:times. Yeah. I also just wanted to point out I like this word it's stuck
in my head now:the ecosystem of developer experience. So it's not just the tool. It's not just the tech and it's also the onboarding experience. It's also the community and you don't want to lose that community. And I always liked how people and community like make it into these conversations cause this happened in our previous episode as well. Where do you see developer experience evolving?
Jamon:I think that we're seeing, the developer experience moving more toward, uh, I mean, honestly, and you know, I know this is sponsored by Gitpod, but that is an example of something where the industry is going. Another example of this would be a code sandbox because sandbox is a good example of this, where you're like, "Hey, I want to spin up a new app just to try something out". And you just go and you click on a box and it spins it up. And just encapsulating environments, making it more one-click. The other thing is prioritizing error messages. I think originally, I noticed that Elm the language Elm was really interesting because a first-class citizen was we're going to have great error messages. And then I noticed that like languages were copying that maybe they weren't the first, it was the first that I noticed though, where error messages were a priority. And they would actually take pride in having these beautiful error messages that would tell you exactly what was going on and how to fix it and how to get help and all of these things. And they were color coded and they were like nicely designed with spacing around it. So it wasn't just jammed up. How many times have you had error messages where it's pages and pages in terminal, you're scrolling back and it's like massive paths to things that don't matter and back traces of stuff that you didn't even write. Like it wasn't even your code that it's showing back traces for. And then you get to the error messages. Error invalid input or something like that. It's like, oh, thank you. That's really helpful. But I've noticed that the prioritization on better error messages, more human readable error messages, that's where the industry is going for sure. And I guess certainly documentation has always been a big. But like making documentation, be more approachable written for experts about approachable for beginners. There's more to it than just the shallow surface level. And it's certainly not just like super complicated, experts only stuff because I've been coding since I was 12. So I guess that makes 28 years now or something. But I don't want to read documentation that's hard to parse. Like I don't have that many brain cells to use for this.
Mike:Yeah. I have a soft spot for interactive documentation. Having that interactive documentation, or even onboarding to a project where you have these like tutorials that kind of walk you through and they blur everything out except for the stuff that's important right now. I think, yeah that's a newer way of doing documentation. That's still documentation, but it's just so much easier to digest. So yeah, what we like to do towards the end is let you share, a fun thing of the week or somebody you'd like to recognize or something you'd like to recognize. Just something that caught your eyes in the last couple of days that you think is worth sharing with a wider audience. What would that be for you?
Jamon:Yeah, so I've been streaming lately on Twitch and it's been a lot of fun and I want to just do a little shout out to people that have been joining me on that. It's been super fun. I've been learning a lot from the people who come in to chat and hang out with me. I'm on Twitch at Jamon Holmgren. You can also find it on YouTube. If you go to youtube.infinite.red. I don't really do it necessarily as a way to promote infinite red necessarily or even myself. It's just I enjoy it. I guess it's the type of media that, that really appeals to me. I do a podcast as well, React Native Radio, and of course I enjoy coming on podcasts like yours. But like for some reason, the live experience with live chat and just coding for two, three hours, it really hits the right part of my brain. So yeah, check it out react native live is what I called the show. And you can find it on Twitch or YouTube.
Pauline:Oh, that's a really good shout out. I've seen it on your Twitter feed and I've been meaning to tune into a few. Cause I'm exploring a similar thing where I want to be more like open and I want to do more live streams, but I have this like fear of messing up live. So if I code something and it's clearly wrong, I'm scared of someone being like that is wrong, even though I shouldn't. Cause it's a fun learning experience for everybody, but that's just my fear. I'll
Jamon:tell you what Pauline I love it when chat says that's wrong. It's the best. It's the best. I love that. That is like, uh, I'll I'll go to chat and then you're going to be like, dude, you forgot to comment and be like, oh check, thank you. Or I make fun of chat if they don't catch my error, I'll be like, "chat, how did you not catch me missing that cell? Semi-colon I'm very disappointed in you." You just gotta be a little bit like that. Don't take yourself too seriously. Live coding, do not feel like it needs to look like a YouTube video. Do not feel like it needs to be like a podcast. That's not the medium. It is totally chill. You should move about half as fast as you think you should. Like you should seriously slow down, have fun with it. Vibe to the music. Read chat, go off on rabbit trail tangents. It's totally cool. That's what the audience wants. And there's no way like live life. I feel like. Shows should be two, three hours. At least some people do six hours. That's kind
Pauline:of long and I've seen six hour ones.
Jamon:I've done them and they're exhausting. But you know, the only way you can do that is, is if you pace yourself. If you ever have questions or want to get help get started on that, Pauline just hit me up because I have a lot of advice there.
Mike:I also think this is, I also think this is part of the experience because a lot of people. They're cool to watch a YouTube video where everything goes well, but it won't happen in real world. And if you see other people do debugging and you learn from them, there's a lot you can learn and save time later when you run into similar situation.
Jamon:Totally agree. YouTube videos are it's their fifth take and they're doing it super fast. And there is a place for that, for sure. Like sometimes you just need the information condensed, you know? But if people come on mine, they'll see me like editing the wrong file accidentally. And then, oh shoot. You know, I was in the wrong file. I need to like, copy this over or whatever happens. Yeah,
Pauline:that's actually really nice to know, because I did one of my first ever live streams I did with someone else. It was like a collaboration one. And I was doing all these cool things on, Gitpod editing all these files. And I realized that I hadn't taken a fork of the repo. Like why isn't this working? And then everyone in chat with like, oh, I think you ha you forgot. And I felt really embarrassed, but at the same time, like I shouldn't have done because it was an honest mistake. You know, it is live you're correct there. So I'll share my fun segments of the week and it actually goes back to the Gitpod Community. We started hosting our Gitpod office hours and we've got a few more community members and our recently appointed community heroes to join in. I'm big on community and I just love how everyone's coming together to talk about Gitpod but also just other stuff as well about themselves. So it's not just about tech, so I just feel like we're really growing a really positive community. So that's my shout out of the week. How about you, Mike?
Mike:I've got something as well that I've kept an eye on for awhile. So it's called code hike and it lives at codehike.org. And it's this little tool that, well, it's not a little anymore, but it started as a little tool, like everything did. And it gives you that interactive way of documenting your code, where as you scroll through the docs on the side, you have code that slowly built up. Just exactly like Jamon talked about that README where it starts with the basic, and then you keep going. This one here is a bit more interactive, whereas the code always stays on the side and it slowly built itself up as you go through it. So I think this is really something I want to look into also for, you know, us at Gitpod for the configuration file, things like that, where there's certain steps you have to go through every time. And that applies to many projects using something like code hike really makes this, I think, more fun and also more relatable because you can go back up and down and see the code update depending on what you read.
Jamon:Oh, my
Pauline:gosh. Yeah, I'm just looking at it right now. And this again, relates back to what we were talking about earlier. Progressive disclosure. This is, this is fun. This is good. Yeah, we should definitely do this. It looks cool. Thank you so much, Jamon, for joining us for this developer experience podcast. It was so lovely to get to know you a bit more after following you on Twitter for a few months now and like seeing what you're up to. I'm excited to continue following your content, watch you onTwitch, get some ideas there. So yeah. Thank you so much for joining and sharing your developer experience wisdom.
Jamon:Yeah. Thanks so much, Mike and Pauline for having me on it was fantastic. Really love this idea of the developer experience focused podcast and you two are great hosts.
Mike:That was good fun.
Pauline:Thank you for listening to this episode. Do you want to chat some more about developer experience? Why not jump over to our community discord server at gitpod.io/chat. We have a dedicated channel there for us to talk all about developer experience and just to make sure that you don't miss the next episode, follow us on your favorite podcast platform or subscribe to our newsletter DevX Digest.
Mike:You can also find out more about Gitpod on Gitpod.io. Start a workspace and tell us about your developer experience. See you in the next episode.