DevXPod

Building a Developer Experience team w/ Cirpo (DAZN Eng) & Lou (Gitpod)

• Mike & Pauline • Season 1 • Episode 1

Share episode

Hello, world! Join us as we talk about what this developer experience thing is all about. For our first ever episode, we're joined by Cirpo and Lou as we deep-dive in building internal developer experience teams, the right metrics, stories of improvement and the importance of communities and people.

The hosts  ▻

Our guests  ▻

Things mentioned ▻

Let's chat some more! ▻

Pauline:

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! Today to kick off our very first episode we have Cirpo from DAZN engineering. And we also have Lou who is now a Gitpodder, but previously he was working with Cirpo too. I'll hand it over to them to do a proper introduction.

Cirpo:

Hi everyone. Thanks for having me, very honored. My name is Cirpo and I'm a head of developer experience at DAZN and DAZN basically is a sports streaming company. Think about Netflix, but for sports. And we be the main difference, ours is streaming live events.

Lou:

I'm Lou, I'm currently a product manager at Gitpod, but I was previously working with Cirpo at DAZN as a principal engineer.

Mike:

I think a good start is to just kind of dive into where are you come from and how did you get started with developer experience and what is developer experience to you?

Cirpo:

I joined us on three years ago and I joined this very small team called at the time core team. It was the beginning more or less of DAZN engineering. It was a small team that was taking care mainly of the front-end pipelines. At DAZN, we started at the early days with a micro front-end approach. It was a niche at a time, still a niche a little bit as an approach. But nowadays it seems one of the new, cool stuff. The company started growing rapidly and especially on the platforms side.And the core team basically was somehow dismantled because we were also taking care of some stuff that weren't related to tooling or front-end. And we wanted also to expand a little bit more, not just taking care of the front end and there were other people also in the company that were already talking about developer experience. We didn't know what it was at that time. We had an idea and everyone was saying,"oh, that's amazing. What is it?" I don't know. We need to find out. As today, the team is growing. Today we are 12 people distributed in four different countries. At the beginning, we started very small because also we wanted to understand "what the hell is that" because there is no literature on the web about developer experience. Our mission has been the same mission that we had since the beginning is to empower every developer, to reach their goals by providing the best tool in a supportive and responsive way. Basically, that's the gist of DevX. Lou was probably the DevX number three, but he was one of the founders of the DevX team at DAZN.

Pauline:

And now we're so super excited and happy that he's joined as a Gitpod because he's also bringing that experience with him. So that's great!

Lou:

Cirpo, I suppose, gave us the backstory to develop experience within DAZN. And I suppose one thing that I've noticed over time is people think of developer experience in slightly different ways. So if you search developer experience in Google, you're probably going to get one of multiple different responses or maybe luckily, it gets someone who's trying to kind of explain the differences between the different types of developer experience. And that's one of the sort of challenges that we had when we were kind of growing the team and thinking about how we were going to structure this is: if you Google developer experience, you get such a different take on it. So like one of the flavors of developer experience is this flavor of, you know, if you are a sort of a dev tooling company, like Netlify, for instance, I know they have a sort of a developer experience team internally. I don't have much knowledge about how they are structured, but as far as I understand, it seems to be more of sort of applying user experience to a developer product. Whereas a lot of what we were doing was internal developer experience or what is sometimes referred to, I guess, maybe as platform or as tooling or as infra, and there's a lot of different names for it. And I think we're kind of at this point now where I'm starting to see a lot more companies call this developer experience internally. I'm not sure why that is necessarily. If they, you know, if they're just kind of the they're aligned with that term and the term makes sense for what they're kind of doing, but I'm definitely seeing a lot more companies kind of adopt that as an internal thing that they're wanting to invest in. And maybe that's also a reflection of companies just coming to acknowledge the fact that if they can make their developers that little bit more productive, that it it can make a huge difference in terms of the output for the company, et cetera. So it's worth actually having dedicated people that are thinking about sort of those workflows that we're using every day and improving and sort of refining on those. But of course developer experience suppliers in sort of a very broad way. So one of the challenges that we had initially as well, was working out what the scope of developer experience was for us within DAZN, like what fits within that box of developer experience and what doesn't, and also this organizational challenges that brings with that as well.

Cirpo:

There's also the funny bit in the sense that developer experience is a hot topic. Nowadays, sometimes people are reaching out to me or to Lou or to other people that seems that they have a little bit of experience in developer experience, but everything is new for us as well. And especially sometimes I feel a little bit, I don't know if the right word, sorry, I'm Italian. I feel a little bit uncomfortable to answer those questions because I have just the context of my personal experience and our personal experience at DAZN. I can not say do this and you will be successful. Absolutely not. Also because I probably, this is a theme that will pop up frequently during this conversation. It's really also a lot about people. It's not just about tooling, you know, or those two things are interconnected. So at the moment I'm here personally, and I think Lou also to share our specific experience, that doesn't mean that what we are going to discuss today will work in other companies.

Mike:

I think this is a very good point. As we go through and start to interview more people we'll hopefully get a really broad view of what different people think of DevX. One thing I want to touch on and go completely off script already... is you were talking about the different meanings of DevX in different teams and for different people. I think what's very closely related to that. And I'm curious how you do that at your workplaces. How do you measure success of your team? Like how do you tell, you know, the leadership that it's worth investing in 12 people for that team. Maybe you can share a few words about that or, you know, how you would like this to improve?

Cirpo:

Yeah, that's a common question. Can we regress a little bit talking about how engineering works at DAZN? Because I think this is also the key, right? So DAZN at the moment you have like more or less 500 people in engineering and we are growing. The fact that we are distributed in the sense that we have like five main dev centers across Europe, and one of our motto is: you build it, you own it right? The fact that every team is responsible from A to Z of their services they build from the inception, the architectural point of view, development, testing, and put in production, and also support. It's a very good model. What you can get is that you can move fast, right? You can move fast because you empower the teams, they're independent and stuff like that. What are the cons of this approach? Sometimes there's a lack of communication. So did the DevX in this case is like the glue between all the teams in engineering. So to try to avoid as much as you can, the waste to me and rebuilding things that maybe they may be each team is building or trying to understand, okay, what are the common painful points across all the teams. But if you have another company with another structure, like more, a waterfall approach or more like top-down, maybe the DevX that we have at DAZN will not work. So to go back to your question, we started very small and I'm super happy that we decided not to start with like 8 people or 10 people in a team, because we wanted to be sure that we could have an impact. Basically, what we had to do at the beginning was to gain the trust, not just from the, let's say from the stakeholders, from the leadership level, but from the other engineers and that is the thing that also helped us a lot to grow because our customer really liked our services, it's very difficult

also for stakeholders saying:

I mean, shall we invest or not? So, yeah, clearly because people were much more happier. How do we measure success? Well, our backlog could be potentially infinite, right? You can build thousand of tools. The problem is that, which ones are you going to build? We are 11 people, so we have a limited capacity. So what we do is that basically we try to understand what will be the main tools and the main initiatives that will bring them the biggest impact? And based on that, we work on those specific tools. And by the way, I want to also to mention that we do internal tools. We don't work on the main product, but that doesn't mean we are doing all the tooling. It will be impossible, right? For several reasons, capacity, domain, knowledge, et cetera, anyone in DAZN could be their own tooling team. What we are asking is that if they're building a tool, maybe to tell us, because maybe we can find an opportunity also for another team. So this is again, the glue bit, right? We listen, we monitor the chats, for example, people are keeping complaining, "oh, NPM is down or this proxy is not working or it takes ages to do this." So we listen a lot. And at the beginning we were doing surveys. Well, that's what people were complaining about the pipelines, but we couldn't really understand what was the issue, right? Because there were, you know, imagine like 300 engineers complaining, all sorts of things can can come up, I can do the metrics, I can do this and to do that. So we did a survey and then we analyze the results and we have to say, "Hmm, maybe the main pain point is the UI of this tool." What we did, we said let's go in Alcatel mode for two weeks. Let's try to rewrite this interface. Let's see how it goes. Suddenly the complaints start dropping. This is how you measure things. Sometimes there are some processes. We had an very old processes at the beginning because DAZN was born from another company. So in pain rate, a specific approval process to deploy and go live at the beginning. And it was a painful thing because it was taking like on average, I think it was three, four hours to get a green light. So we did a small tool and now we got back to like one hour on average time to response to get a green light. And then we'll say, okay, it seems that this thing's working. Can we do it better? And then we treat and we improve that tool. And then the response they know to get the green, a green light went out from four or five minutes on average, you need to measure it. And it's not always easy. That's why, for example, one of our values in DevX is a preferred data driven decisions because this is key.

Lou:

I love data and like Mike, you know, my head goes into this space sometimes. Like, how do I measure this? Like, how do I understand the value that this is delivering? And, and we've had a bunch of conversations with other people from other teams. And I suppose one way that you could potentially come at this is kind of looking at productivity as a whole across all of your engineers. You've kind of got like the dev ops metrics, but like cycle time and time to deploy and all this stuff. And maybe you could do something like that in the developer experience space. I haven't seen anyone necessarily publish a framework, sort of as widely adopted as the DevOps one, but yeah, you could go on that sort of macro level, but what we actually started with or what, one way that we kind of broke that problem down is by looking at the individual tools that we have as well as sort of individual products themselves. As Cirpo mentioned about like this change for our CI pipeline or some of these other tools that we invested in, we kind of treated those just like you would with a typical product, really. So we kind of outlined a vision for that product and then kind of success criteria for that product itself. For this particular product, what kind of metrics do we want to see changing? In that case with the CI, you know, one of our metrics was the internal sentiment and sort of reducing some of the internal sentiment or issues that we had with the CI pipeline internally. So sort of a pragmatic choice of these different metrics, but on a individual product. Taking each aspects of what we were building and just build a metrics around an individual product . Another thing that we did as well was we spent a lot of time looking through, GitHub data. There is a tool that I think is missing out there in this space. You know, we've looked at some of the different SaaS options for using GitHub data to measure all these different metrics, like contributors in specific repositories and things like that. But looking from a lens of internally, I guess, a lot of the GitHub features are external focusing. For a company like DAZN to try and analyze and understand, you know, what contributors do we have across different repositories? Are we building a sort of healthy, internal opensource culture? That kind of thing. So we started building some internal tools as well to kind of extract data from GitHub and do sort of ad hoc analysis on top of that. That's kind of how we started digging into the rabbit hole of providing metrics and value for some of those individual products.

Cirpo:

Also to be honest, even if I'm talking in very enthusiastic way, it's still a challenge for us to prove stuff by data. Why? Because you need to have initial data. If you are in a company that is even if it's a startup or a big company, a company that keeps evolving. It's very difficult to have consistent data everywhere. For example, now that we are moving from drone to GitHub action, sometimes we are missing some data because we didn't have the proper integration. I know that I shouldn't say that, but I just need to have trust and faith in the sense that sometimes when they're asking me, how do you imagine that? Well, I count how many people are smiling that day. I know they sounded a little bit cheesy that at the end of the day. So it is a factor. It is a metric. Yeah, it is.

Mike:

Reduced the number of WTF's.

Pauline:

Yeah, absolutely. Listening to both of you just gets me really excited. It seems like we're still super early and there's going to be still like changes in the space, there's no framework that established, but you know, I wouldn't be surprised the more this gains traction that in the future, someone listening to this right now and be like,"Hey, that is a good idea. We should, we should do something in that. Create a framework for DevX! Yeah. That's a good idea."

Mike:

The, you know, by now pretty older 12 factor app methodology. We need something where there's some kind of guidelines or things to do about, you know, DevX, developer experience saying that, okay. You know, follow these 12 things and you you'll see good things happen.

Cirpo:

We are talking about the developer experience as a new. As in our field, nothing is really new in my point of view. In a sense that as I keep saying all the time, every company has a developer experience. Not every company has a developer experience team. So that's the main thing. One of the questions, sorry, if I'm asking the questions to myself is, well, where should I start? How should I sit up at the DevX team? Don't do too much structure. Try to tackle a challenge. Maybe just set up a working group, like three, four people. And start building from there. There is. And which is basically our story. Yes. It's true. That it was more official at the beginning. We started as the X team, but this is also the approach that we took. Sometimes there are some initiatives in the developer experience team where we get people from other teams, temporary to work on a specific project for one month, two months, three months. Because probably they are the best people to work on their specific need for maybe they have this specific domain knowledge. Maybe they have a specific skills or experience in a specific language or technology. It should be a collective effort.

Mike:

I also think that when you join a new team, my advice is find an area and become an expert in that. And I think that could be writing tests. It could be writing documentation. It could be taking a legacy system and make it better, whatever. But I think one area here is also to, you know, just look at the developer experience, especially because you're new to the team. You just went through that onboarding of that project. Like take that opportunity and be that person who has the most recent experience. And then just improve that even if it's just, writing a script, automate a piece of the onboarding and basically just kick that off, that may change how the rest of the team perceive their developer experience for the product. And it may just go from there and turn into its own team. So I think it's a great area to add some value to any team.

Cirpo:

What is clear to me is that from the technology point of view, everything is going micro. Micro front-ends services components. Even the team structure that the organization will adapt to that model. That's why we should invest more in developer experience because it's clear to me that. We are empowering even more engineers and teams. Now an engineers in general is someone is not just writing code, but takes care of all the product, even if they also working somehow in more in a isolation for, with their product with a services... this bit of developer experience, even more important. That's why probably is more emerging today compared to five years ago, or even before. It's a trends, right?

Lou:

My mind goes into kind of weird and interesting place with this because I was quite literally chatting to a software engineer from NASA the other day. He was basically porting this super old piece of code from an old code base into a new one. And what then he was talking about was quite funny. Back in the day, yes. You didn't have a lot of tools and things like that, but you also didn't have a lot of dependencies and stuff. So you kind of like was refactoring this old piece of code taken over and rewriting. I don't know what he was rewriting it from and to, but he was just mentioning about all the different dependencies kind of being missing. That's the thing like as time has gone on, we've got more and more tools available to us. You know, the micro stuff, that Cirpo mentions about all of the changes in the way that we do stuff in the cloud, et cetera. And there's all these tools that we kind of have to glue together, which are great having. These different things at our fingertips, but then we also need to figure out how to put these all together. Otherwise, I know we've all sort of felt that you kind of have that like tooling fatigue, especially in the ecosystem or from a career perspective. But when you join a new company, there's a whole bunch of new technology that you need to wrap your head around. All this stuff, to learn all of these different tools. And I'm, I'm kind of laughing to myself now, but maybe digging ourselves out of this hole with more tools is not necessarily the fix. I don't know. Tools got us into this state, will tools get us out? I'm not sure, but the reality is the situation that we're in is: technology is complicated now. There's lots of moving parts and if you want to kind of bring engineers into your company, if you want to onboard them, if you want them to be productive, which I'm sure pretty much all companies do, then you kind of need that developer experience. As the industry has shifted and, you know, we've kind of gone to this idea within the cloud, we hand off lots of stuff to other people, but there's still a load of complexity that kind of falls on us, that we have to kind of plug together ourselves. I think it's just kind of a way that the industry is going, as we grow with these tools, we need to figure out a way to plug them all together and give people a way to be productive within the sort of modern tech environment.

Pauline:

Let's talk about what's the best developer experience you've ever experienced yourself as a developer, whether that's in your own teams or as individual engineers.

Cirpo:

So I just remember my first time with the Heroku CLI I think it was what, 10 years ago, 12 years ago? And I was amazed by that. Also seeing some colours in the terminal, I said, wow, can you do colours in the terminal? I know that today we are used to emoji and everything in the terminal. But back in the day when you were using your bash was like black and white. That was the option.

Lou:

We had a document as we were preparing for this and I was joking. And I mentioned something, I was like, I'm calling, I'm calling dibs, which is like, I guess like UK slang for saying that like, okay, I'm calling this specific one because I want to talk about it. There was basically one feature that we implemented on a specific application within DAZN. And I've kind of wanted the exact feature in pretty much every application ever since. So on our internal CI system, we basically had some for all intensive purposes, basically just an error map. So, you know, you sort of had a string match or a reg X match or whatever for a specific error. And it would give you a, just a different prompt for a suggestion. And basically if we, if we knew what the fix was, we would provide it. And if we didn't. You know, sort of defer or kind of share some documentation or something like that. And I just felt like. Sort of tooling around errors and error suggestions is like really hitting it at the heart of developer experience. When something goes wrong or when you have an issue that you're kind of being nudged back into the right direction. Or you're almost just given the solution to the problem. And I see this in a lot of tools nowadays, where I kind of want the exact same experience. You want to harness the power of a community. Cause it's kind of like a stack overflow type solution here to developer experience because what we could then do is provide that config for these error suggestions to the community. And every time the community would come forward with the same error of what we could just do is just codify that. So it could, you know, write that up in the config next time that error comes up the next user, then we'll know what the fix is to that specific issue. And you kind of like applying this like stack overflow thing to your internal tooling, which I think is for me, is kind of hitting at the heart of DevX. Anytime I see anything, with like really neat error suggestions, you know, you get an error in the CLI and it kind of just gives you the answer that you can just copy paste it. That for me is the essence of DevX.

Pauline:

So many ideas for Gitpod suddenly, they all started coming in when you said that. I was like, hang on. That's yeah, that's incredible.

Cirpo:

Why we did that? It wasn't like someone in the team woke up in the morning, so I couldn't do that. It's just because we were realizing this pattern every time platform or DX was releasing a software or a new feature, or I don't know, even a, we were deprecating a service or an API. You can write as many blog posts as you want. You can send emails, for sure, someone will not read it. This is a human beings. It happens. Right? The pattern was that every time it was the new deprecation, we were losing something new or something different for one week in the DX support chat, which is from my point of view, also talking about support is very important, at least for us. We were seeing these trend, people asking the same question over new. I said, well that, well, what shall we do? Shall we just knock on everyone's door until we deprecate that you remember? That's why this idea was born. And again, this is being some how responsive in helping and try to make our customer's life better and also how our life better, because otherwise we will just spend time in supporting things. It's not something that it takes ages of development or planning or using 10,000 different technologies. No, it's very simple and very effective.

Pauline:

Absolutely. Sometimes it's good to go back to basics and not over-complicate.

Cirpo:

Even if it's not perfect or we don't have to support, let's say all the browsers in the world... it's fine. Small quick wins sometimes they have a huge impact.

Mike:

If we take this to a more personal level in terms of what's the best developer experience improvement, that, you've made yourself to the tool now. You both worked in that field for a while, and that's what you did day in, day out. So good luck picking your favorite one, but what is something that kind of stands out?

Cirpo:

If I have to think about myself, it's not a tool, I'm really happy about what's the DevX today at DAZN. After two years and a half. For me, it was more about the community bit. If I have to think about improvement from my point of view is setting up some sort of a community around developer experience.

Mike:

I think that's extremely valuable to have. You know, the, the shared responsibility eventually as well, where you get everybody to see the benefits and jump in.

Pauline:

Yeah, and community... I mean, this isn't a community podcast. Well, if it was, I would jump in and explain to you why community is at the heart of everything and it should be prioritized. So, yeah, I'm glad that you mentioned that.

Lou:

I feel very similar to Chipo in the sense of it's it's hard for me to come forward and say, You know, XYZ is something that I did because I think over time, what we were trying to do, I suppose, in a DAZN context is really just elevate the other engineers and help them and facilitate them to come forward with their tools. That became a very sort of central theme of my role is really working with Cirpo and these other developers internally to kind of help them put forward their tools and if tools emerged and we were there to kind of support them and build on top of them. So it's a bit difficult in that sense, because really the heroes of the story with the engineers themselves, it wasn't necessarily us. Ultimately it, we would have done the best job possible if we made ourselves redundant, right? If we didn't have a job and the developers just all did it themselves. That's sort of the preferred end-states. I feel a little bit like I'm copping out in terms of providing like a super nerdy hyper-technical developer experience the feature. But as from an internal perspective, I think one of the big things is that community aspect as well, every everything we did mostly really was, it was done as a team. So it's hard to put my name on, on a particular feature that makes it difficult.

Cirpo:

It's good that we cannot put a name. It means that it will grow organically. So I'm really sad of course, that Lou left. Of course you can imagine, but the good thing, you can still see that the DevX is still working and probably that even if I'm leaving tomorrow, for whatever reasons, or if I changed my focus, I still think that the DevX at DAZN will not go away. That means that then you build something from the community perspective, that is the sustainable.

Pauline:

We touched on how developer experience it's only going to grow. Where do you see that growth going?

Cirpo:

The actual mission is it stays tools and tooling, and this is also the easiest way to sell it even internally and externally. But at the end of the day, for me, I would like to 360 degrees developer experience. Whereas those there's a culture bit, whereas the community aspect of it in inside of a company, because it's, for example, we are already doing some of those kinds of things in DX. And the problem is that it's not in our mission or it's not really our objective. But it's somehow complimentary. DevX for me is you shouldn't be just about tools, should be about the experience from the onboarding or the time you spend in the company as an engineer, what you do, how you get in touch with other people, how you foster discussions, contribution, and this kind of thing.

Pauline:

I like how you mentioned people. That's really important. And I think it's something we often in tech in general forget. So I really like honing in that message.

Lou:

From my side, it would be nice if the industry moves towards doubling down, maybe on the developer experience term. We talked about it before that there are lots of different terms for this type of thing. And from our side, it was always really hard to find resources to guide our journey and read about what other people were doing. And like I mentioned, I think a lot of other companies are going this way, so it would be very cool if the industry kind of starts to consolidate on some of this. And you know, some of the, maybe if it's developer experience that we go ahead with, that'd be really cool because it would be nice to see more communities coming out of the back of this. I can see more companies already adopting this. I'm not a hundred percent sure necessarily what's driving that change. Maybe it's just awareness from those companies. Lots of other things that we talked about early on today, but I think more companies will continue to adopt it. And you know, we're going to see more communities come up around it and more discussions, maybe more conferences, meetups, that type of thing, podcasts, hopefully like this one as well, where people are talking about developer experience a little bit more and paying a bit more attention to it.

Mike:

As we said at the beginning is this is at the very early stages of what's possible. When I look back. In the last 10, 15, 20 years, we have always had these

phases of:

"Hey, should we write tests or not?" And then at some point we agreed, maybe that's a good idea. Let's write tests. And then we had like, should we write documentation or not? DevX I think it's that same kind of, you know, is this a good thing? Should we start to focus on? And clearly we start to agree that the answer to that is yes. And I think it's exciting to see that we are heading in a direction where this becomes a real important thing for anybody. One thing I want to kind of wrap up the podcast with is- it doesn't have to be DevX related - this is completely, you know, open-ended but I'd like you to share a fun thing of the week, like a recognition and a shout out to somebody or anything that you want to get some attention to that, that you found incredible in the last couple of days.

Cirpo:

There's a book that recently came out from Luca Mezzalira he was working at DAZN as well. Now he's working as a principal architect at AWS. It's called "Building Micro-Frontends". There's a lot of bits about communities and people. It's very rare. Still nowadays to find a book that is technical in its essence, and it mentioned also the people side of things.

Pauline:

We'll leave it in the show notes for people to have a look at as well. How about you, Lou?

Lou:

This is a tough one. I could mention anything, but I'm thinking if people have made it this far into the podcast, kind of listening to about internal DX, I feel like I probably should give a little bit of a head nod towards the backstage from Spotify, because if I'm talking developer experience, this tool has to come up for this type of topics. For those that are not aware, basically Spotify opensourced this tool that I believe that they had something internal and they kind of rebuilt it or cleaned it up and put it, put it external and open source that, and it's just been a really cool because it's built a community of people around that tool that are solving a very similar problem. And I just don't think anyone else, other than a company like Spotify could have solved that problem. If you do explain that in abstracts, I don't think a lot of other people would have understood it. It's a very specific to middle to large companies that are trying to get a handle on sort of all their software. And it was a lot of the stuff that we were doing in DAZN. When they announced it and released it. And we went through their docs. It was quite striking because so many of the concepts and the ideas that they put in there. We were also talking about, you almost felt like they'd come in and like stolen our best ideas and like even built them somewhat better to some degree. As a developer experience community, we can all kind of get around that and sort of contribute to it. They're doing a very difficult job which is ultimately trying to apply a sort of taxonomy to internal tools, which is very difficult when you dive into the weeds of it, but it can be super useful. I think to the question about where developer experiences go in, it'd be really interesting to see where backstage is a couple of years from now. And I think we're a hundred percent going to see some competitors come up to it as well, some alternatives, because they are going to pave the way it's going to be clear that there's a huge market for this. And then other companies will come out with slightly different twists on that, on the same idea as well.

Pauline:

Mike. I want to flip the question to you. We're involved in this now!

Mike:

There's no way to get out of it? I'm going to make it very generic, but I think I'm going to give a shout out to anybody who is building a command line interface that makes life of developers a lot easier. I think there's an underrated aspect to developer experience where we have a CLI tool that helps you make things easier. Whether that's like things like Fig that automates your article or other completes your CLI and things like that. It's these things where that the terminal is such a central aspect of how we develop and then what we do on a daily basis. Anything we do to make our experience there better. I think this deserves a shout out, I'm excited to see what just goes.

Pauline:

And just to finish off, I'll share mine. For me, it's actually the Gitpod community! Who would have saw that coming? Over the past few weeks it has grown a lot and we've actually created a developer experience section there and we hope to grow that area a bit more and have a few more conversations from people who are interested in developer experience. I'm really pleased that we've talked about community and we've talked about people because at the end of the day, from my perspective, it's one of the most important pieces in tech in general, but also developer experience. A huge thank you again to Chapo and Lou for sharing their insights for the first ever DevX podcast episode, we'll leave some links in the show notes for you to go connect with them as well as the recommendations that they shared today. 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.

People on this episode

Head Shot

Christian Weichel

Host
Head Shot

Pauline Narvas

Co-host