DevXPod

The link between Developer Experience and Developer Relations w/ Kurt Kemple (Founder and Principal Advisor, Forthright)

• Mike & Pauline • Season 1 • Episode 4

Share episode

In this episode, Kurt Kemple talks to us about redefining developer experience and how it is the new DevRel. This was a great conversation that highlights how very relevant DevX is today and how it's the best time to get started in it!

The hosts  ▻

Our guests  ▻

Things mentioned ▻

Let's chat some more! ▻

Pauline:

Hello. You're listening to the DevX podcast, the 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. Hi, Kurt! We're so excited to have you here. I think this episode is going to be super interesting because the perspective that you're coming from is more of the developer relations and advocacy side, which isn't something that we've talked about with a guest on this podcast before. For those who may have not have heard of you before, could you give us a bit of an introduction on yourself and maybe a bit of your background?

Kurt:

Yeah, sure. I'd be happy to, first of all, thanks so much for having me, super excited to be here as well. With that, we get a little bit into my background. What's up everyone. I am Kurt Kemple. Currently I am the founder and principal advisor at forthright, which is a consultancy that helps companies, teams and individuals create better developer experiences. So DX consulting, if you will. Before that I was developer relations manager at Apollo GraphQL and I was there for about two years. Had a really great time there building up DevRel and watching developer experience turned into a really impressive function at Apollo. Before that I was at AWS as a Senior Developer Advocate where I was on the AWS amplified team. It was really cool. Again, another very interesting product and like category to be working in. Yes, I did a lot of developer advocacy there. Prior to that, I was at Gatsby for a little bit as like a developer experience engineer slash developer advocate. And then prior to that, we're getting back a little far now. I was at a major league soccer and I was a tech lead there on, on the UI team. And that's how I got into developer experience officially. We adopted graph QL relatively early. There weren't a lot of people talking about how they were using it in production and at scale. And I said, well, if somebody has got to start talking about it or no one will. So I started writing content. I created a graph QL NYC meetup, and a bunch of other things, you know, just make sure I wasn't building in a box, so to speak. But yeah, that's kind of like my background that takes us back pretty far.

Pauline:

I think like it's going to be an interesting conversation because like we said, just before we started recording, developer experience has always been. At the center of everything you've done in all of your roles, it sounds like. Whereas I feel like there's a lot of conversation now around developer experience because people think it's like a new thing. It's a new term. It's a new area that we can all go get into and learn. But it sounds like it's always been there floating in the background. Maybe it's this is the time for it to shine. It's going to be really interesting to, to hear your thoughts on that.

Mike:

Thanks, Kurt. Really good to have a year. Thanks for the introduction on where you've come from, and I'm sure we're going to get into where you're going next. We'll keep that for a little bit later. I think the way we usually start this is kind of with the question of how do you get started in DevX, but also, what is DevX to you personally? And what do you think of the whole concept and the importance of it.

Kurt:

I'll go into two parts. First I'll talk about what I view as developer experience. And then I'll talk about getting into developer experience. I viewed developer experience as an event or an occurrence within an ecosystem that leaves an impression on a developer. You know how I came to this kind of idea, really is through my career, the different roles that I've had in developer experience. Like one of the things that I've noticed is, especially for folks who work in developer relations, but it's true of the broader developer experience field as well. We're often very much involved in the community in one way or another. And we have something called third culture. Essentially we have, two parents of different cultures. We have the community and we have the company, but we exist in both deeply innately. And because of that, we're able to see things that the other ones, the other side is not able to see about either themselves or the other side of that relationship. And that context that we have is like really valuable. Now the thing is that is not just valuable when you're onboarding or when someone's working with your CLI or when they're in your docs. That context is equally as important to marketing teams, user advocacy teams, customer success teams, sales team. And so when we think about developer experience and these impressions that developers have and how we generally work as developers, you can have that experience anywhere throughout your interaction with a given platform or ecosystem. It doesn't even have to technically be related to the company. I could in a unrelated Discord to any company or ecosystem, but interact with another person. If that is somewhere where your company happens to be, that's a developer experience. If I'm asking even another person for help and I have a bad experience, that's still kind of. I tie that to the company. Even if the real relationship is not there, right? So we can't pin developer experience down to like I build integrations or I help developers be more successful, or I provide feedback because all of those things are pieces of making sure that every occurrence within an ecosystem is not only not negative. But like, positive. Right? Because the other thing about experiences is like, you can have negative, positive, or mediocre, mid experiences. We'll call them. People don't talk about mid. They definitely talk about negative, but they don't talk about mid either. You need people to have positive experiences within your ecosystem to get people to talk. And so I think we need to, I'm really trying to work on getting people to reframe that thinking, because I also see because of that definition, developer experience is the larger umbrella. We often use DevRel or developer relations is the term to contain all of the things that we have come to known as what I now consider to be developer experience. I actually believe developer relations works in service to our developer relations. Yeah. It works in service to developer experience. Like it's a piece of that puzzle. That's kind of my definition of developer experience. I'm sorry that it was so long winded, but this is something that I've thought a lot about and actually written about as far as how to get started in it. I will say that one thing. That is true about developer experience. That's true about engineering is it can be difficult to get into the field if you don't have a lot of experience. And that is not because you can't like, because it's not doable. It's just, that is the way the industry is. And I like to just preface this with that, but I think the skills that will do the best in developer experience, aside from some roles, actually aren't even engineering skills. I think the skills that help them most one that you can't get by, honestly, almost no matter what role it is. It's technical writing. Being able to communicate clearly through written word is very important to these roles. It doesn't matter if you're giving feedback and making a demo app, writing a blog post, creating a video, like it all starts with well-written word or copy, right? Like all of those things rely on that. I feel like almost no matter what role that skill will serve you very well. The other thing is empathy, right? It's very important that we can't physically go through every experience or workflow that a developer may encounter, but having empathy for developers and understanding being able to. Understand their pain points, but then also not attach them to yourself. Right? Like being able to critically look at those and tally those up and figure out where to be useful. So empathy is huge. And then prioritization and organization, because unfortunately, our function is relatively new. And so there, aren't a ton of places that have a really good structures in place that will help you, come in and zero in on what you should be doing on the day to day. So right now I'd say prioritization is a big help. One day I hope that's not as necessary, but I think it is now.

Mike:

I think it's still it's a pretty fluid role. I think we're all in. In terms of you know, even kind of measuring what you're doing and showing the impact to leadership is hard. Like you can show that you have certain number of followers on your Twitter account at the company, but what's the impact of that. Does it actually help? Interesting. I also liked the fact that you brought up empathy. I think that is especially critical when you have things like box or stuff that gets forgotten or not develop that you can be there and be the face of the company and say that. We messed that up. We were going to look into this, we're going to fix this and actually own it and then kind of follow up. Get that done. Very interesting.

Pauline:

I wanted to actually say that if I'm being a hundred percent honest this whole time, when I've been thinking about developer experience, I've mostly been focusing on the product. So in product onboarding, the product itself, the different features that it has, like how easy is it to use the UI and stuff like that. Until you mentioned it, Kurt, I didn't really step back and think actually developer experience and developer relations. Sort of go hand in hand, like the relationship that you described because developers have an experience. When, for example, they're in our Gitpod community discord, they go in there, they ask questions, if a community member comes in and I don't know isn't very nice in their response. They can have a negative experience there, or if I don't know, it's a bit more blunt and whatever it is, the way you communicate. Super important. And obviously that also touches docs and all the other things as well, but I don't know, I just sort of like clicked for me. So thank you for that.

Kurt:

Yeah, absolutely. It's tough because yeah, we can now say all of that is developer experience, but then it's also kind of like, okay, well now what is not developer experience, right? Everything under this umbrella and for me, this is where I think when we look at developer experience, we're starting to have like very specific areas of focus under it. This function is really starting to become pretty well-defined, you know, actually. When y'all were introducing yourselves, it was like very clear, right? So like Pauline, you have a community focus and Mike like docs and education, right? Like education, community, DevRel. Those are all starting to be like solidified as like areas of focus. And then DX engineering, which could take many forms, right? Like from integrations or building like the backing web infrastructure and stuff to support developer experience initiatives. But the one thing that is clear is that like, yeah, it's broader than what we've been giving it credit for, but that opens up like a new set of problems, which is okay, now we have an even broader area of focus to concern ourselves with our job is already at times very fluid and hard to prioritize. So what does that mean? Especially in smaller teams and companies, you know, like, okay, now how do we deal with all of this. So again, that circles back to that prioritization, it's not easy by any means, but I do think that it requires us to adopt this kind of framing and be more specific in our terminology because I actually think the lack of specificity it's going to do us a significant amount of damage as companies try and understand DX and build that out as they grow.

Pauline:

My next question is actually around why should we even care about developer experience? Why should we even care? Why should this be on people's radars?

Kurt:

It's for a multitude of reasons. I'll start from the first one, which is software will only become more and more important. And our everyday lives. Developers like developments will continue to be a field that grows and grows. There will continue to be developer tooling companies that spring up because of this which means there's going to be for a very long time. I see developer experience right now how JavaScript was about eight, nine years ago. Honestly. So once JavaScript really broke out of the browser and became common in other places. And we started seeing CLI tools and APIs and everything being built with it, having an explosion of JavaScript jobs and education and all of these things focus on it. It's still one of the most prevalent languages we see. DX like as a role as a function, we're about to experience that we're only at the beginning right now. You did actually hint at something which is DX has been around for quite some time. It's very true. A lot of folks were doing it, even some people as a specific role. But generally very embedded within other teams generally in very niche areas. it's not that way anymore. It's very common, right? Like we're starting to see it's even in it as its own function and a lot of companies not even nested under another function and startups are starting to bring on a developer experience folks as either founders or one of within the first 10 hires. And that says a lot that says a lot about the need for developer experience. And so just alone, like from a career perspective, it's a very smart move. There's going to be no shortage of jobs in the developer experience space over the next few years. I can guarantee that from the conversations that I've been having, it is a fact, I, there's not enough people to meet the demand. So that's number one. Number two is if you are somebody who really enjoys, like making things better for people, if you're one of those people who wants to make a process less painful to work for, or you love seeing other people succeed at the things that they're trying to do, developer experiences. Whether that you're an educator or you work in creative fields. I think the other thing too, is that a lot of folks are starting to realize that you can work specifically in developer experience, but do things like be a filmmaker or a designer or a illustrator animator, right? The content is always evolving. There's a lot of roles that are open from that method as well. So from that perspective, it is just a very broad field, but like, why do we need DevX? I think that circles back to, there's never going to be a shortage of developers and we ideally want to make our experience. I know I want my development experience to be as pleasant as possible. I think about when I started development and the things that I used to go through to get started, you know, this is actually a great point. So like if I wanted to work on a project with somebody, I didn't even have usually version control back when I first started, we were like figuring out ways to share files where I would FTP things up through a cpanel to my website. I might've said words that people are like, I don't know what that even means. And that's good. It's good. That means the developer experience has gotten better and people don't have to concern themselves as much with that. At the end of the day, we're trying to like make something or accomplish some kind of business goal. And the more time we can spend on that, like product and business code, the less time we spend on technical infrastructure code. The better off everyone will be. Plus I think the better the developer experience, the more accessible it makes development as a field to people.

Mike:

You mentioned the fact that companies are startups start to hire people in DevX early, early in their journey. It's actually interesting. I kind of kept an eye on Twitter the first two weeks of January, which has only been two. But what I noticed is there's a bunch of people announcing their new jobs and there's kind of a higher proportion than last year of people saying that, "Hey, I'm joining whatever company in developer relations or developer advocacy." And I'm like, this is the year of developer experience. I've said the same thing for the last three years, but I think now I really feel that it is actually the year of developer experience.

Kurt:

Completely agree.

Mike:

The other thing actually is there is in my personal view, there is a competitive advantage as well to having a fantastic developer experience like the older I get, and the more experience I have, I would literally choose a company over another one. If one has a better developer experience, if everything else is equal, that would just be the killer feature right there. And it's not just me as an employee, it's also people using the product.

Kurt:

Absolutely. And to even take that one step further, and then often we try to put the lens of that on smaller teams, agencies, and startups want to be able to move faster, but like we forget that it's equally as important for enterprise companies to be able to onboard people quickly and have them ramp up. Right. So it's like, talking about competitive advantage you're right. And it doesn't matter what size company you are. And actually it might even be the better the developer experience, right? Like the more competitive advantage you get at scale, because that's even more people who have to ramp up and be able to use that technology.

Mike:

Yeah, exactly. I think the, you probably saw that when you were at AWS and I saw you definitely at Google as well, like whatever they can do to reduce another minute of your daily effort, they will do, even if it costs them like six months of development time, but with a hundred thousand employees that immediately pays off. So you can take that at any scale and it's always applicable.

Pauline:

I really liked your point. I wanted to just highlight it again around developer experience will help make tech more accessible. I love that. It will bring more people in because the more we focus on developer experience, the more people will be like, Hey, this is a good, this is a cool space. They learn faster. They onboard faster. Yeah, no, it's spot on. I really like that point.

Kurt:

Not paid at all to say this, but Gitpod is a great example of developer experience and making technology more accessible. Now with a Chromebook, right? Like a little like an, a browser. So I'm going to have internet and some programming power. I can now program in like very complicated environments and do all this other stuff that like, before it'd be relatively impossible for me to do on my own. So those are the types of things that like when you think about making tech more accessible, and then I come back to JavaScript, like JavaScript was a language that is relatively accessible to get started and it's a dynamic language. So it's very forgiving to not having to understand computer science basics before you can even really be successful in it. All you needed was a web browser and some sort of educational material, and you could start learning how to, I'm living proof that I started learning how to program when I was incarcerated. I took like a course intro to web design. I think it was even called or intermediate webpage design. I think it was called yeah, the HTML CSS and JavaScript never heard of it before. Didn't really know what programming was completely changed my life. Amazing.

Pauline:

I was going to say it actually reminds me of, we've recently onboarded, a new colleague who works in the community space with me and he actually lives in Bangladesh. He doesn't have a laptop. But the way he had gotten into tech and into development was actually through Gitpod because he has a Android phone that he's been using are using. And whenever he wants a big screen, he's managed to plug in his Android phone to the TV and then connect to the wireless keyboard and mouse. And it's just that wild. It just blows your mind. Doesn't it? Now he's part of Gitpod and helping out with the community. But it's his story is one of to him, I'm just like, wow. We've literally opened the doors for a lot of people and it's incredible.

Kurt:

Yeah. Again, I want to circle back to like, so for folks who find that type of work, rewarding, enabling other people to have access to things that they didn't have before, and not every case will be that exaggerated, but I find a lot of enjoyment in enabling one person with the smallest thing. And then you come across stories like that, and it's just like makes the work so much more rewarding. Well, I think, you know, if there's ever a reason to have DX...accessibility is, you know, enough of one in my opinion, but if you need business reasons, it's a competitive advantage. Yeah.

Mike:

I think accessibility is a good reason. What's other good developer experiences you've seen or maybe build yourself or with a team? Does anything come to mind?

Kurt:

A very long time ago, getting back into developer experience, I was working at an agency and we would constantly be spinning up like Drupal WordPress sites and things. And then there were other steps we'd constantly reuse plugins or modules, or we connect WordPress and Drupal, which can at times be pretty difficult. So I built a CLI tool, um, Bert or Burt bot. So Kurtz, I just changed it to Bert. I thought it was very funny. It was cool, but you could spin up new projects that would like have a Drupal and all of the modules that we already use and loaded stuff. And this was like, before, like that was really popular. There was no real way to do that in PHP. There's nothing like a, what is liable use composers that maybe like a, I can't remember what PHP has these days, but long story short, it is a huge productivity booster for the team. Like all that time, again, that they were spent on the technical, the infrastructure setup was eliminated. So I called that out because that was like my first real kind of like experience and understanding that like, wow, there's a lot of power in building tooling for other developers. And that was my first development job. I guess I have been doing DX from the very beginning. Actually. It was my second job. I take that back. My first one, like in the big city and not this little shop that I was at, but yeah. I would say that's definitely one. What am I excited about today? There's a couple things. I'd say one project that I really enjoy. And not because I used to work there. And there's some things that I don't like about it as well, but is the amplify CLI the reason why I like that project is for a couple of reasons. first and foremost is what it is doing for you. The developer experience that it's providing is enabling a lot of people to do things that they couldn't possibly do before. And what I mean by that is Folks who have a stronger front end leaning, but maybe a little bit of understanding of what they need to build products and build applications are able to do that with amplify without having that expertise. And even to a level of I feel like they could do this to start like a real business. And cause at the end of the day, under the hood, it is cloud formation templates, which is a very big part of AWS. I'll spare everyone, the nitty-gritty details, but you can eject for lack of a better term out of the amplified CLI and you still have like everything there. And so that goes to like my second point, which is something I care deeply about in developer experience, which is progressive disclosure of complexity. I am a huge fan of tools that work really well with a good defaults. And then can progressively expose any complexity that you need. So they're actually flexible and powerful tools, but you don't have to use them that way if you don't want to. so things that like fit under that or amplify Gatsby, even next, even things like plugins for those like ecosystems help improve developer experience. The things that I'm most excited about were the, my first intro that Bert bought, which I wonder if it's still on my GitHub, I should check. More recently things like amplify, I think is really cool things like Gitpod, which I'm really big into these Idea of being able to have like virtual environments, which is not a new thing, but I think at this level of ease of use, it is a new thing.

Pauline:

I've not looked at amplify for a while, but when I used it in my first job, we were heavy AWS users and amplify we use the form, one of our smaller projects and I absolutely loved it. Then I started following all the amplify dev advocates on Twitter that got a little bit obsessed. This is awesome. So many cool things were popping up from that space.

Kurt:

I just want to say those are just a couple of many. I feel like developer experiences is becoming very important to a lot of people and there are companies focused on different parts of the developer experience that are really doing amazing things to make it so much easier for people. There's no shortage and just because something didn't get named here doesn't mean, I don't think it's not a good developer experience.

Pauline:

We could go on that should be an episode, like a list of all the best DevX. Yeah. That we we've used them in the past. Yeah, exactly. Yeah. That would be awesome. We touched on this a little bit, but where do you see developer experience evolve? Is there a specific direction that you think is going to take?

Kurt:

Yeah, I think some things are going to become a lot more prevalent. The number one I think is like a core education. I think that like a lot of companies are understanding that there is a lot of value in producing really high quality core curriculum, not only around their product, but whatever else they're like that product that ecosystem is in. And so we see this happening at all kinds of different companies. I think that is that's accurate. I think we'll see, continue to see. An explosion of that. And as a by-product of that, we're going to see an explosion of rolls around things like they'll making a developer educator will be to the biggest, but like illustrators, animators, right? Like all of those folks. These teams are going to take this, we're already seeing it. You go on YouTube and some companies that the level of content or on their own learning platforms and the level of content is getting. Really high quality. So I think that will continue to expand for sure. I think the role of community advocate is going to become a lot more prevalent. I feel like a lot of companies are starting to realize that you cannot get away with having a community manager. And then nothing else, like no other support. I see community advocate and I've talked to people who are doing this role already. It's very similar to the developer advocate, but they are spending most of their time within the community. The bigger differentiator there is that they're really tumbling, like helping to build those connections within the community. But the big part of that is feedback. That's where it's like very similar to the developer. Advocates is taking all what they're learning from there. It's not just one sided, right? It's about enablement as well and helping the other ones. They're also in there figuring out how do we engage the community? How do we create value for them? Like holding hackathons workshops, cohorts for learning all these different types of things that people are finding ways to engage with the community. And leave the management to the manager, it's nice. It's a needed change. I think, as Mike mentioned, our roles can be very fluid or we wear many hats, so to speak and I'm very excited to see actually, another thing I think will emerge in DevX is we're going to start having to wear less hats because roles are becoming more and more well-defined. I do think that requires work on our part though, which goes back to the whole, not just saying I do DevRel be very specific about what you do, because when everyone says they do DevRel and you're doing community management and someone else in the DX engineer and someone else's a developer advocate and someone else is doing something else, like educator docs, technical writer, but you do DevRel. I feel like that's how we end up with these job descriptions where people don't know and you have nine core responsibilities. They're just saying. This is DevRel. So everyone does this. And so I think, one thing that we try to embrace as educators is that new things need clear terminology and definitions and they need to be repeated and make sure that people can absorb them. So I'd love to see that, as a focus for us, but I do think we are. And I think that as the experts, you're going to see more and more well-defined. Actually for anyone who's listening. I did write an article called like breaking into developer experience and it covers like some roles that you'll see today in emerging roles. And so it could be a really good thing to check out.

Mike:

In terms of getting into it, I think there's one thing I personally see, you probably wrote about that too, is the fact that. You can get started without having any permissions, right? Like you can always write a blog post about a tool you really enjoy. That's how I got to Gitpod eventually I just liked the product I talked about. I explained it. And then they reach out to me. But the other thing, I think you talked about job descriptions. I think what's also going to happen is that we start to see well-defined career ladders for advocates. At the moment, I think you're a developer advocate and you're charged based on your previous experience, whether that was a software engineer or an architect or whatever you do. But I think moving that more into a separate career ladder

and like:

this is what an entry level developer advocate does. This is what an intermediate does. I think this really needs to happen sooner rather than later in order to structure that better.

Pauline:

You also confirmed that my career is it's headed in the right direction. Cause I'm mostly focused on community. So like having sort of like a similar title as community advocate and doing more of the, I mean, my day-to-day is mostly in the community, but having that a clear, defined role. Yeah. And just to see other people in this space as well, to share learnings and stuff, I think that's really valid.

Kurt:

I was just going to say that I've also seen like community engineers, which is like a special focus of DX engineer, right? Like generally more on data pipelines in bot integrations and stuff and getting all of that stuff set up and yeah, like that, we're seeing that happen more and more. I think that will continue.

Pauline:

Yeah, absolutely. And I also wanted to say that, I like how you've also have been talking about other roles, so not just engineers. Filmmaking, content creators, illustrators. I love that. I love that writers. It opens up the whole space to everyone. So you don't need that. I don't know. I feel like gatekeeping might reduce a little bit. Cause you know, everyone's sort of welcoming the space a bit more. You don't need to have, X amount of credentials or whatever to, get into the space.

Kurt:

I loved Mike's point and now I'm losing my train of thought, but what did you say right? Career letters. Thank you. Yes. Thank you so much. Yeah. And that's a very good point and it's also hard to have career ladders if we don't define those roles. I think we're at a time. And where I'm like, if we were to Wordly map out a developer experience, right? Like we've gotten through like that Genesis phase and we're starting to get a find ourselves into the products. We're not quite a commodity, but we're becoming a product we're starting to have career ladders to find a roles, even consulting services to address these needs. Like it's becoming something that is known. The field and before you know it, we'll be into commodity where it is just it's as normal as marketing and you have standard roles and career ladders. But that's where we are. We're in the process of watching that come to life.

Mike:

And I'll be watching it life from a front row seat. Kind of how we to wrap this up is a fun thing or a person or something you want to give a shout out to that you recently encountered, whether that's a tool or maybe somebody that taught you something, but your chance to give a shout out, to do something um, that that comes to mind. Uh, what would that be for you this week?

Kurt:

So my shout out is to Rizl Scarlett. So for folks who are not familiar, she is a developer advocate at GitHub. She's a relatively newer developer advocate. And I love that she brings a very fresh perspective. She's doing amazing work and the thing I love the most of that, she is challenging a lot of the things that we're seeing, currently in the space and really trying to push it forward and make developer experience more welcoming to early career folks, which I think is paramount to the success of our function or really any function know. She's doing great stuff. Keep up the awesome work and yeah, go follow her@blackgirlbytes on Twitter.

Pauline:

I'm going to give her a follow up after this session. Love it. How about you, Mike? What's your shout out?

Mike:

I have to pick a tool this week and it's actually a tool that may not be necessary in the future because we don't actually log into servers anymore. But if you do have to SSH into a server, you know how it goes. You have your local setup, everything works beautifully. You have all the tools and then you SSH into machine and it's all gone. Like you cannot even type LL or whatever to list the director. So there's a tool it's called XXH. And what XXH does. It's literally github.com/xxh/xxh what it does is it basically brings your favorite shell wherever you go. So you login via SSH and it brings your set up your shell with you. And you have to sound kind of experience came across that a couple of days ago. And I'm like, I do have two servers that I need to look into once in awhile. And even just for that, it makes a huge difference. I don't have to remember stuff that's configured on the server.

Kurt:

I'm helping my brother set up something and he hasn't used a digital ocean droplet and every time I SSH into it, I'm like my goodness. I'm really going to be using this like immediately. That's so cool. Thanks for that.

Pauline:

Thanks for the shoutout, Mike. We'll end it with mine. So for me, it's actually a book this week. For me, it's a book that I'm reading by Emma Gannon, who wrote one of my old time favorite books called the multi hyphen method where she talks about how everyone is more than the job titles. They have different identities. We're not just an engineer. We do all sorts of different things. We're not just defined by work. So that was a really good read. And we have one of my favorite books, but the book I'm reading by her now is a book called sabotage. It's so good. I really am enjoying it. It's quite a quick read as well. It's definitely going to be one of the ones that I continue to read over the years. Highly recommend that. We'll leave all of our recommendations in the show notes. If you do want to check that out. But Kurt,thank you so much for joining us. I've learnt so much from you. I'm so excited for this podcast to get out and I can't wait to write about it as well and share what I've learned, but honestly, thank you so much for your time.

Kurt:

Thank you so much for having me. It's been an amazing conversation. you all have such good insight and it's just, we help each other, right? Like we get there together or we don't get there at all. I can't wait for folks to listen to it when you do listen to this, if you have any questions or anything, you know, you can always reach out to me on Twitter. Thank you so much for having me!

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 developers. And just to make sure that you don't miss the next episode, make sure that you follow us on your favorite podcast platform or subscribe to our newsletter at DevX Digest.

Mike:

You can also find out more about Gitpod on start a workspace and tell us about your developer experience. See you in the next episode.

People on this episode

Head Shot

Christian Weichel

Host
Head Shot

Pauline Narvas

Co-host