A look at DevX with Chris Weichel (CTO, Gitpod) and some exciting news!

In this episode, Mike and Pauline talk to none other than Chris, CTO of Gitpod who shares with us his take on what developer experience is all about, reflecting on what motivated him to get into DevX and hopes for the future. We also have some exciting news!

The hosts  ▻

• Pauline Narvas, Senior Community Engineer at Gitpod  (https://twitter.com/paulienuh)
• Mike Nikles, Senior Developer & Success Engineer at Gitpod  (https://twitter.com/mikenikles)

Our guests  ▻

• Chris Weichel (https://twitter.com/csweichel)

Things mentioned ▻

• Exhalation by Ted Chiang (https://www.goodreads.com/book/show/41160292-exhalation) 
• Calm (https://www.calm.com/)
• OSquery (https://osquery.io/)

Let's chat some more! ▻

• Gitpod Discord Community
• Start a Gitpod workspace!
• DevX Conf

Transcript

Pauline: 0:00

Hello. You're listening to the DevX podcast, the place to learn all about developer experience hosted by me, Pauline Narvas.

Mike: 0:08

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: 0:29

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, everyone. Welcome to another DevX Pod episode. This is really exciting because we've actually got Chris, our Gitpod CTO talking to us today. And we also have a bit of a little surprise, which I'll probably mention later on in the episode. Chris, welcome. And thank you for your time for recording this podcast with us. Could you give us a bit of an introduction on yourself for those who may not have heard of you before and what you're up to?

Chris: 1:21

Hi. Thanks for having me. My names Chris. I've been with Gitpod since pretty much day one. So employee number two, yeah, work a CTO these days. So deeply care about obviously Gitpod as a product, the technology that powers it. And the experience that enables, but also the organization that built it. You cannot have one without the other. My background, where I come from, before joining Gitpod, I worked at an IT startup coming out of Bosch, where we build devices and solutions work as a system architect, there for a couple of years. And before that actually spent some years at Lancaster university, did a PhD on HCI human computer interaction, which is very relevant to what we do today. Believe it or not like the field of the topic areas that have is completely different but what it applies to still matches very well.

Pauline: 2:16

Thank you for that, Chris. It's really exciting to have you on this episode. And the reason is I think we can do a little bit of a reveal now, Mike, I was going to leave it to the end, but I'm really excited about this, but Chris is actually joining us for future dev ex pod episodes as a permanent host. This is super exciting because Chris has an amazing background. It's going to be exciting to have future conversations with him. You also have Mike and I being alternative podcast hosts as well. So we have a bigger team and it makes sense because we are a distributed company at Gitpod. This is going to be super exciting. We can chat to all sorts of different people now that we cover different time zones. Welcome Chris. Warm welcome from me and Mike.

Chris: 3:04

Thank you so much. Yeah, this is really cool. I've greatly enjoyed the past episodes and I'm really looking forward to the conversations we'll have.

Mike: 3:11

Welcome on the podcast, Chris! Good to have you. I think there's going to be a lot more to come. We start to see increased interest from the public and people reaching out, trying to join and share their view. So really excited to build this kind of brand here and help people understand developer experience and all kinds of different views. Exciting. With that, I think we can move on. And I think one of the questions that we have that we'd like to talk about is how did you personally get started with developer experience and what is it to you? How would you describe it?

Chris: 3:48

Yeah, that's a good question. How far to go back? So actually you could tie this back to almost 20 years ago so much like you, Mike, I believe I did a vocational training as software engineer. And so in, in Germany, the school system is very similar to Switzerland, I assume where at the age of 16, you can basically go on to do vocational training. And one of my Jobs, there are roles, as you cycle between school and company was in a team at Robert Bosch. So I was at Robert Bosch at the time, and they were building a product data management platform team of about 20 people distributed between Germany and. Back in the old days, we're talking Oracle Solaris, C Cole wrapped in Java, total nightmare. And the company that we built this on top of, or that product, they believe that you would just configure it rather than develop with it. And the configuration was essentially Java. So you didn't know you were writing code except they didn't provide any tooling for it. All you got, like they recommended TextPad. That's how old this is. And so this clearly didn't work because we were building a platform. We were expecting 50, 60 developers working with this. So we needed to build something out. And that was actually the role I had at that time. We built an eclipse based IDE that would let you select essentially preview environments. Like we would have a fixed set of installations that you could deploy to. We would have our unit tests integrated. We would have the deployment pipeline. We kicked off continuous integration at some point because the teams would build their stuff. And then every Friday there was that poor sod who had to integrate everything that came together. Guess what that was. That's really how this all got started.

Mike: 5:38

I can see how you want it to make this better. I feel the pain just listening to it. Wonderful. Yeah. 16 when you're supposed to make life-changing decisions. Big moment.

Chris: 5:50

It is a bit strange to toss teenagers at the age of 16 into this, like, Hey, what do you want to become a life? That's become a Software Engineer, why not?

Pauline: 5:59

I was gonna say that, it's cool that you both had that vocational training at 16. When we didn't have anything like that in the UK, the only thing that was similar was when we were like 14 years old, we spent two weeks out of school to do something. And we had to organize like work experience for ourselves for two weeks. I ended up actually teaching as a primary school for two weeks. All I did that was read to children for two weeks. I like read different books to them and they loved it. They enjoyed it. Yeah. I just wanted to follow up on my next question actually. What is developer experience to you? A lot of our guests have similar definitions of it and is slowly becoming a standard in the industry, but yeah, wanted to hear your take.

Chris: 6:49

Yeah. I think developer experience is first and foremost user experience in a specific field that is the persona of the developer. So where we try to make things discoverable and easy to do. So essentially, what do you want to do? Much like any other tool you'll want to fade it into the background. You want to be, you want it to become transparent. Good example of that as a pen, when you're writing texts with a pen, you're not thinking about that pen in your hand, you're thinking about the texts that you want to write, and this is what we will need to achieve with developer tools as well. We need them to become transparent and fade into the background so that we can achieve what we actually want to build. And this is more than just the end product experience. This is also more than the documentation that surrounds it. It is the ecosystem that goes around. It is the way it is applied. It is the way you, as a developer can influence the tools that you are using. And this is really puts us in a very unique perspective. Very few people who are holding a fountain pen would ever think about modifying it or wanting to talk to the company that built it, how they would want to change it. Whereas as developers, we're naturally inclined to do this, we build stuff. This is what we do. So obviously we want to make the tools that we use that as well. And enabling this form of agency, I think is a key part in developer

Pauline: 8:13

I don't think people have actually mentioned that like ecosystem point of view before and you're absolutely right. It is really a unique perspective being a developer, building stuff, and then being like, oh, actually we can make this better. And I think that's what developer experience is all about making things better for people who use it, because we want them to have a less painful experience or just a better experience. Obviously we've talked about like how important it is to improve experiences for developers. So that's it's not as painful as like what you described before in your story, but what other reasons are there? Like, why should people even have this on their radar? Why should we even care about developer experience?

Chris: 9:00

I really think this depends on who you are and from which angle you're looking at this and three angles immediately come to mind. One is lowering the bar there is. And I think this was mentioned on a previous episode as well. There's just such a demand for developers that the only way we'll be able to meet that is if we lower the bar to entry. The other is, and it goes in a similar direction, we have so many things to do, we just don't have time to waste with bad developer experience. We, we cannot waste time on setting up a development environment for five days. We got better things to do. And the last, we're putting more and more things on developers. It's the days when it was just an air quotes, writing code, a long gone developers today are asked to do so many things. And so unless we make easier if even possible for them to do all those things. What we're going to end up doing is we're going to end up burning out scores of developers. And I really do believe that good developer experience and the agency that our defaults directly improves people's lives. And depending on if you're a developer or if you're managing developers, this is why you'll want to care about this. It directly impacts the health of your people and what your organization is able to do.

Mike: 10:22

You made a point about, we don't want to waste time. And that the first thing that came to mind is the CI/CD discussion from a few years ago. Should we do it? Should we not? Is it going to be good? And now, I see this spreading throughout everything, not like developer environments as well, and obviously given where we work, but there's this really the entire ecosystem, the entire software development life cycle is impacted by developer experience. And regardless of whether you actively improve it or not, you do have a developer experience. The question is it a good one or is it not so good? And yeah, it's super important. I think that we focus on that and, the morale of the team is such a key thing that has been overlooked for many years. We came from the industrial age trying to do software engineering. Like we built stuff in factories in the past and it's just doesn't work that way. And having that front and centers is a very important, I think

Chris: 11:17

At this point, I think the factory analogy is quite apt because when you look at someone working in a factory, you know, that we're not trying to optimize that they're having a good time necessarily, but we're trying to optimize that they can do their work efficiently, that they don't get hurt on the job that they don't have, repetitive strain injuries and that they can do what they are there to do. And in that sense, even from that angle, I think developer experience is very apt because it has, this has similar goals and even more than that, and I'm grateful for this. We're not treating developers, as it was too difficult to replace this with a robot. So we put a person down the assembly line kind of thing, but we still also with developer experience, we try to essentially avoid repetitive strain injuries. We try to avoid the stress that comes with, Hey, I got to deliver this tomorrow, but I have to fight the spilled system now. So I think the goals are very similar.

Mike: 12:16

Yeah, absolutely agree.

Pauline: 12:19

I really appreciate the point that you said about how developer experience is directly related to people burning out. So if you have a bad experience, then you're more likely to be like, frustrated about that whole experience. And you're likely to then burn out. It's really a good reason to care about developer experience in the first place, because you're absolutely right. That it does directly impact people's lives. It sort of just brought back memories of previous workplaces I've been in where the tooling is terrible and everyone is clearly fed up of it, but we just keep, we just have to keep doing it because we didn't have enough engineers to help improve the tooling. And so we just continued working the way we did. And we had a backlog full of tech debt, where we were like, we will improve this at some point and it will become easier at some point, but that day never came. That actually resulted in a lot of people feeling burnt out and some people even quit because of it. From the top of my head, I hate bringing it up because I don't, like, I have to say maybe this is an unpopular opinion, but I don't like Jenkins. I mean, I could run, I could run for a while, but, we see as Jenkins and I used to have a really bad experience with it. And a lot of other people in my team did as well, because there was just, it was slow. There were so many things that we just didn't know how to configure. It was a lot complicated for what we were trying to do. As a fact that a few of my ex colleagues just hated it so much that they would actively avoid any work that had to touch Jenkins in any way. But then that would cause other events to happen, like, more work in the backlog that no one really wanted to do and everyone was avoiding. So then that was a bad experience for the people that use Jenkins and we were the DevOps engineers trying to improve about, but then no one wanted to look at it. So then at the end of the day, all parties that were involved, other the engineering squads that looked to out to the dev ops team, to the platform team, which I was a part of didn't really have a good time. And then we had that strain in our relationship because we were, they were like, why aren't you fixing that? Like we can't use this. The tooling is terrible, but then yeah. And then both burning out I'm upset each other. It did lead to peop some people quitting because the tooling wasn't great. And another company promised no Jenkins. So of course people go, you know, if I don't have to use Jenkins, I will go that I will go to that company. I'm really glad that you mentioned that is very important.

Mike: 15:02

So hold on. We used to say. And job description three was to add what the tool stack is. It's the new trend that we say what we don't use. So people know from the beginning. Interesting.

Pauline: 15:13

I have to say, I'm going to be honest. I have asked after that role, I got another job after, as another dev ops engineer and I asked the recruiter, can you ask the engineering team what tools they use? And I specifically called out Jenkins. I was like, how much of my time will I be using Jenkins? And he was like, oh no, I don't think that team looks at Jenkins. It belongs to another team. So you would be using someone else's Jenkins and you would be using the pipelines on that. And I was like, okay, let's talk to the team lead because I don't need to. If I don't need to do any configuring on Jenkins, I am a happy engineer. So I was really picky, but it's like this isn't a unique experience. I know so many engineering friends who have said the same thing who have been actively avoiding certain technologies because of the bad experience.

Mike: 16:02

It's also that over the years, as you do that for 10 years, 15 years, whatever, then you start to build a certain expertise and an opinion on what works for you. You've tried all these tools, you've done all the languages or many of them. And at some point you're like, I am most productive in this and going somewhere where that experience is different or not up to par, it's just harder and harder to find something that really resonates with you. When you look at the requirements and what the daily life was.

Pauline: 16:28

Yeah, absolutely.

Chris: 16:29

Which is also really a chance for new products, languages, and frameworks to come in. If they improve your experience, even by an increment, let alone sort of disrupted to use that overburden term. That is a great way to make an entrance and actually to carve out a niche for yourself and to actually bring value like that.

Mike: 16:50

Yeah. I just read an article this morning and saying that, we built all these SaaS platforms that would be like horizontal, across many industries, like, you know, a project management tool that would be used by a dentist office and like a software company. And that article was saying that the current decade is focusing on the that's a vertical SaaS approach where you don't have to cater for everybody. And you can be very niche and focus on one specific use case, but build the tool in a way that really helps that industry or that niche to succeed. And that's good enough because everything is getting or a lot of things getting digitalized and having a tool that's very specific to you, it makes your life easier. It's probably enough to build a sustainable business nowadays. I think I brought it up saying that there's almost a developer experience sometimes it's a good one. Sometimes it's one that can improve. What is your kind of ideal developer experience? What are the best you've seen? Or maybe even the best of your experience or you want in your life?

Pauline: 17:51

You can't say Gitpod

Chris: 17:59

and not just because I happen to work, then I'm obviously heavily invested in it. But honestly, because I do believe this is the best I've seen the date. It really is like that. If I'm not allowed to say that I'll have to

Pauline: 18:19

no, no, I totally agree with as well, to be honest, when people ask me, I genuinely jumped to get pod because it's changed by life in terms of like my workflows. I can never go back to local development.

Chris: 18:34

Go, is actually an excellent keyword. And this might be an unpopular opinion, but frankly, I did enjoy the go developer experience from day one. And mind you, this was before the days of Go please. So what really made the difference for me is the level of integration that, that you got from it, there was a package manager built and there was GoFund built in and famously no one likes how Gulfam formats, but everyone likes that it does, there is unit testing built in the standard libraries, amazing. There's a lot to learn around it and it just works really well. The first thing that we built with that actually was a command line utility to upload code to an embedded. And make making that process easier. I was at the time, but that IT startup that came out of Bosch, we built something called the SDK, the cross domain development kit, small little box looked really need, had a ton of census, pretty much every sensitive that Bosch made at the time and the Caltex and three microprocessor. And then, you know, how do you develop software for that? This was actually a pain point that, that we needed to solve. We're coming back to develop experience. We were asking people to essentially write C plus plus code. And I know he ever dabbled in engineering, uh, embedded software development. It's no fun like software engineers. Don't like to read data sheets for some reason. And hardware engineers don't care about software. So it's really hard to find people in the middle and this is what we struggled with. And so one way to make that easier was to provide a tool that at least made the upload simpler. And we even went on to build their own programming language around which misguided, but we tried. Yeah. You know, getting started with, go under pressure to, to ship that tool was really straightforward. And so if I have to, if I cannot say Gitpod. I'd say Go.

Pauline: 20:18

That's a good one actually. It actually moves us on really nicely to where do you see developer experience evolving? This is actually my favorite question to ask guests on the show because everyone is so forward thinking and I'm so excited. We're all sitting here at the front of what feels like the start of something you know great. So, yeah, I'm excited to hear your perspective.

Chris: 20:44

Yeah, no pressure. Um, Frankly, I think we're moving with developer experience where we moved with CI CD or OCI specifically 10 years ago, 10 years. 10 or 15 years ago, it was quite normal to go to a shop and not find continuous integration. And it was just the way it was nowadays. If you started at a shop and they didn't have that, it'd be like, I mean, what's wrong with you people. And I think this will see a similar effect with developer experience happening. And there are a few contributing factors, one as said before, I think developer efficiency, which is coupled to that, we'll need to integrate. And so companies have an intrinsic motivation and projects. Like this is not just companies. This is also open-source projects contributed experience. Close-knit having an intrinsic motivation in, in pushing this. And so when you join a company or project and they don't provide good developer experience, you're like, what's wrong here. Something is off. And eventually you'll be able to say, yeah, all right. It's to develop experiences is wrong. Why are we not doing that? I think this will become pervasive and it will become pervasive for the company like internal facing companies that need to onboard developers have again, intrinsic motivation in making that better. Especially if you look at all the money in the startup world right now, and the hyper growth that we're seeing on startups, the only way you can do that is the only way you can scale to that extent is by providing good developer experience from day one and also outward facing. If you're building a product that is aimed at develop. Or even remotely touches on developers and which product doesn't. I mean, you're selling a coffee machine. You need to offer an API. You'll need to provide good developer experience for that too, because otherwise it will be a hurdle for people to adopt your product. So I think it will become very pervasive. And in a few years, one or two, if it's going to be like CI, you're not doing CI, you're not doing good DX. I don't know what kind of places this!

Mike: 22:47

I think any, anybody who ever worked at one of the big global companies school and Facebook, and you have dos, they can really relate because that's how we, or they work internally, right? Where the it's not the first time that we are looking at developer experience. If you have 80,000, a hundred thousand developers or people that use your tools every 10 seconds, you can shave off of somebody's daily work. It just scales at such a big scale. So having data at any project level, and as you said, open source is a huge factor there. If I have an open source project that I see above that I want to fix, and I look at the contributing.md and that takes me five minutes of just read through and not motivated to go in there and do something. If it's just hard to set it up and mess around with my environment that they already have. This is such a key thing in the next little while. To wrap up we usually asking our guests just to share a fun thing that you recently encountered. It could be a person, a thing, a tool, or just, if you were to give a shout out to somebody to give some credit where credit is due you kind of thing, anything on your mind.

Chris: 23:55

Yeah, that's a good one. I had a bit of a think about this and I decided to choose one of the books I read last year. And it is actually not like I've mostly read dry factual books these days, but this one isn't, it's actually a collection of short stories. It's called exhalation stories by Ted Chung. And it is a mostly scifi, but not like hard scifi spaceships and stuff, but it's really interesting stories. It's think of black mirror, less dystopian and in a book.

Mike: 24:29

Okay.

Pauline: 24:32

Yeah. That's a good, I'm really curious. Now I want to deep dive into that. Yeah. Mike, am I all right to jump in with mine?

Mike: 24:39

Of course.

Pauline: 24:39

Because I can see you struggle with your Airpods.

Mike: 24:45

That's right. I'm not kidding. My ears are built differently.

Pauline: 24:52

Oh, okay. This is a side note. I'll explain. I have a comment about the AirPods anyways. My pick for this week, this meditation app, I've had it noted down for a couple of weeks to share on dev X pod, but, I've been using this meditation app called calm. I'm sure you're you may have heard of it or familiar with it, but I've been using it since 2016. I've been like meditating for a long time, but there was a time from 2016, for 563 days, I sat down and meditated every single day for 10 minutes at least. And then I broke the street cause I felt like calm and all the benefits that came with meditation, I was like, this isn't I don't need to do it anymore. I'm better. So I forgot about it for a couple of years and recently because of the pandemic and, things still feeling a bit strange even in 2022, I was like, I'm going to go back into meditation. And currently I'm on a 60 day streak. And I'm really proud of myself. Um, I've been doing it for 10 to 20 minutes these days, and I feel like a calmer, happier version of myself. I also wanted to shout out to Johannes recommended that I stopped meditation who really inspired this as well. That's my recommendation. How about you, Mike?

Mike: 26:12

Nice. I'm going to wrap it up with a tool that has been around for a while, but I used it recently on a project because I remembered it and it felt like the right tool. So it's called OS query and it's a OSquery.io that lets you clear your operating system like SQL, so you can do select, you know, something from, and then if a whole bunch of tables, you can use that for security for all the chain or even if you just want to figure out like how many people have looked in the last couple of minutes and things like that. So I had that other use case for that and I remembered when to look at it and then I figured, you know, recording that today's perfect timing. It came in very handy standardized these things across operating systems. So you don't have to, um, you know, remember how to figure out what version of Ubuntu you're running or things like that. That's just a SQL code. Yeah. Yeah.

Pauline: 27:04

I have like a list of all of your recommendations on my notes app. And every single week, I look at them again and I'm like, oh wait, I need to like deep dive into these like someday. So it's like a long list of Mike's recommendation have a very special page for you, but yeah, that's another cool one we'll add it onto the show notes. And I think that is us wrapping up for today's DevX pod. Thank you so much, Chris, for being a part of this. And we're both really excited to have you join our team and I'm sure you're gonna an incredible host!

Chris: 27:41

Yeah. Thank you very much for having me. And I'm really excited for the conversations that we'll be having.

Pauline: 27:47

Amazing. Thank you.

Mike: 27:49

Thanks Chris!

Pauline: 27:51

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: 28:17

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.