DevXPod

Building the future of the terminal w/ Zach Llyod (CEO of Warp)

• Chris & Pauline • Season 2 • Episode 7

Share episode
The hosts  ▻

Our guest  ▻

Things mentioned ▻

Let's chat some more! ▻

Zach:

Again to the earlier point like how do you integrate effectively with the other tools in the developer ecosystem to make the whole developer experience better One of the things that gets me excited about the terminal is just like it is a integration point with a huge surface area And so that's like I think that's probably the way that that we you know we figure in into this system rather than trying to build like a vertical solution for everything but it's more of an integration point

Chris:

Welcome. You're listening to the DevX podcast, the show where product and engineering leaders share their thoughts and insights on developer experience. I'm Christian Weichel joined by my co-host Pauline Narvas.

Pauline:

hi Zach Welcome to DevX Pod Thank you so much for joining us I'm really excited to talk to you today

Zach:

thank you both for having me

Pauline:

So for those who aren't familiar with you and your work can you tell us a bit about yourself and maybe your journey so far and how you became the creator of Warp

Zach:

Sure I've been an engineer for a long time now I've worked on a bunch of different things Probably the biggest thing I worked on before Warp was I was a principal engineer at Google I used to lead the engineering team for Google Docs And actually most of my time at Google I was working on Google Sheets and helped build a lot of that product I'm now a second time startup founder I founded A company called Self-Made I was a CTO there Totally different space but I guess the common thing throughout is I've always enjoyed just kind of taking software that's had like not a great experience trying to improve the experience And I guess another common thread would be I've enjoyed taking productivity tools that have been sort of Single user legacy tools that people have used for a long time and trying to make them collaborative and make them work for teams and make them into a more modern experience

Pauline:

That's awesome I think you are probably the perfect guest for this podcast because it seems like all you want to do is create better dev experience so that's awesome

Zach:

it's yeah I would say not even just dev experience like I just get very frustrated using crappy software It could be like the software on my Apple tv like has like weird fast forwarding behavior Or it could be you know spreadsheet or yeah it could be like yeah I'm a developer so I use dev tools all the time So so anything to make basically any kind of software I spend a lot of time in better is something that I enjoy

Chris:

The collaborative aspect is super exciting You know looking back at Excel comparing that to Sheets immediately obvious why Sheets works better in a team So throughout this episode I'm really looking forward to dive into how this applies to developers Cause obviously software development is a team's sport and there is a lot that isn't collaborative yet

Zach:

for sure

Pauline:

Yeah I was also gonna say Zach are you one of those people that like uses software day to day and then you're like I could totally build this better and then you create an issue if it's an open source project Are you one of those people

Zach:

I don't I'm usually to be honest I'm usually too lazy I just to create issues I just get I like subtly get annoyed I'll complain to my wife and I you know I don't always I'm not so like Arrogant that I think that I could be like fixing a thing or making it better but the it is it's a fun like puzzle or challenge to try to take something that you know people regularly use that and it might be suboptimal and try to like build a better experience that's fun for me

Pauline:

Yeah Yeah no that makes sense I am actually one of those people that write feedback on Twitter and I'm like

Zach:

Oh really

Pauline:

maybe you could do this Yeah It's like I'm actually very

Zach:

that work do people

Pauline:

Sometimes like for example I have one of my favorite tools is Todoist which is my to-do list productivity app and I Send feedback there but then I feel like they know me now because I've sent feedback over the years and it's great and it's improved so much So I think it's that's a huge part of contributing in general That's a whole different podcast episode but yeah Cool

Zach:

a good citizen that's cool that you do that

Pauline:

I have to I have to contribute in some way awesome so this is a podcast about developer experience and one of my favorite first questions to ask guests is what is developer experience to you How would you define that

Zach:

Yeah I would I'd look at it like pretty broadly in terms of like if I'm a developer trying to get something built are the tools like Enabling me or are they causing friction can I do it in a way that's like delightful or am I like limited in fighting against all of the software that I'm using to try to build new software And to the extent that like the software is enabling me and helping me build and not getting in my way that's a great developer experience To the extent that I'm like spending time on Let's say like the incidental complexity of using the tool rather than building the software That's a poor developer experience

Chris:

There is the individual tool and there is also the interaction between tools how does that come into play specifically when talking about incidental complexity

Zach:

Yeah I mean I think that's like where a lot of complexity comes from is the the tools don't always integrate super well and so you know as a developer I think you you know you're I think by the way tools is probably too narrow of a way to think of it it's not just the tools it's everything that developer is dealing with all day So it's the language it's the code editor the terminal it's the infrastructure It's the Web console for controlling the infrastructure There's all these different things that developers are constantly contact switching between And actually one I actually think one thing that's interesting about developers is this like tangent is that these things are always changing They do not seem in the developer world to me at least to converge It seems like developers are such a creative group of people who have the capability of solving their own problems That the second that there is like some like problem with a thing that they're using whether it's a piece of infrastructure or database a streaming tool whatever Developers build a new version of it And so there is a constantly changing Very diverse set of tools that developers are always using and they don't always integrate together And I to me like a lot of like the most kind of unpleasant time I spend as a developer is in trying to configure or arrange or get the various things I'm doing into a coherent system so that I can actually focus Building the thing that I really want to build So I think that's a really good point Chris about like it's not just any individual tool causes friction It's a lot of it is about like the failure of these tools to work that nicely together

Chris:

That The point about convergence I think is very poignant we do seem to like to reinvent the wheel with just slight incremental improvements every so often

Zach:

Yes

Chris:

I'd argue we do converge on on some concepts right Not necessarily on tools Concepts we can agree on some one of the oldest that we probably agree to some extent and talking about that extend as the part of this episode is the terminal And pretty much every like it's one of the first things that that we as developers encounter and that seems daunting at first and want to become aware of its might And power is something you can't live without what's your journey with the terminal Been so far

Zach:

Yeah I mean so when I it's a good point It is one of the first things people encounter Like the way that I think about it and my thinking on it is like changed a bit over time is that you know the terminal or the CLI in general is like a platform Sort of writing and running text based apps and it's really like a modality of interface whereas like on the one hand you might have apps that are very like graphical you have web apps but the sort of superpower of the terminal is it's this environment where you can sort of run your text based apps And the advantage of text based apps is that you know first of all they're very easy to Probably the easiest type of app to write in the world is one that just takes texted and puts text out It's like everyone's hello World app and every language they have all these other nice properties they're all scriptable in the terminal environment They are composable So you can take the output of one and feed it as the input to another Cuz text is a kind of universal interface and so You know I think conceiving of the terminal as like just like this other interface modality that happens to be very well suited to a lot of things that developers want to do because it's so easy to write apps because developers are able to script their environment I guess to some extent because developers are good at typing Like it's a tool that I think is like you know is an important Part of that whole world of like you know if you're a developer how can you get more stuff done And then you know with Warp the idea was like okay this is an important tool this is an important interface modality Is there anything you could you know what could you do if you were to sort of think like from first principles around making this interface the best it could be and so you know we sort of pulled back we questioned some assumptions around The terminal versus the shell which is a you know it's like almost an implementation detail in my mind to how the CLI works Like developers like I mean sure a lot of developers are thinking terminal and shell but I would say most developers are just thinking like I'm using this app that I type text into and runs it runs programs and gives me output So we we tried to like holistically rethink like well what should this interface be What should this you know the terminal as a platform be like and the more that we thought about that the more we're like there's a lot of like pretty fundamental changes you could make to the user experience that would create a much better like DevX around around this the cli in the terminal And so that's like kind of long rambling answer to your question but that was the thinking of how we kind of got

Chris:

Awesome Yeah it's really interesting to see what's happening in that space Like the other day in a previous episode we had the CRA charm on and it's really exciting to see what they're building so this really is becoming a universal platform which begs the question of what if it needs to be thinking like what is the path that had you go huh Yeah I wanna go back to first principles and like let's start clean

Zach:

Yeah so we started with like the really basic most common user interactions and so I guess for a terminal user it's really it's about inputting text and getting the output in a normal terminal Just to like nerd out for a second the way that it works the terminal's just like a very dumb application that is actually emulating the behavior of a piece of physical hardware that was built in like the seventies and eighties and what that hardware did was it allowed a user to like type into a keyboard It would take character by character send each of those character codes to something on the other end of like a line like basically like a it's like a character oriented interface and it would interpret those characters when you know after you type them all in you hit enter it would this would typically be a shell parse the characters Potentially launch another program that program would send characters back And as far as like the terminals knowledge goes the terminal would have no idea what was going on behind the scenes there And so the terminal was just like a stream of characters in and a stream of characters out but that's in my experience at least not how developers think about the tool They think about it in a much Command oriented way So they think of it more like a rep like you're in the Python rep or you're in like the Chrome dev tools console You type a whole command you hit enter that something happens you get an output back And so we were like well what if we could make the terminal work like that What would be needed What would that experience be like And that led us to make sort of two big changes to just the whole terminal ux The first is the way Input works So in a normal terminal like I said the input goes through the shell and warp the terminal takes over the input And as a consequence of that we give you like basically a normal A normal input editor the experience you get of editing code in FIEs code and to really boil it down that means like the mouse works So like a normal terminal like the mouse doesn't work You can't click and put the cursor someplace selections work So you can select text and like paste it and it replaces your selection or you can hit delete and it deletes your selection Multiline editing works so it's like you can you know normal terminal it's very weird If you start hitting the up arrow depending on what state you're in you'll probably get your history You won't move your cursor up a line so it's like that works and then we can do a lot of things in warp that make the experience of entering a command much smoother So it's like We can give you syntax highlighting we can give you hovered reveal documentation And so the first thing we really did was reinvent the way the input works The second thing was we changed the way the output works because similar to like input developers are tending to look at the output in a re style And that means that like one command has one output associated with it And so in warp we introduce this concept of blocks which basically it's like If you're to look at warp it's like it kinda looks like a notebook in the output sense Like every command has its output associated with it And so that makes certain things that you commonly do in the terminal like copy pasting the output of a command or searching with within just one output or sharing it so much easier cuz you can say oh I wanna select this output and do a thing with it And so if input and output were two of the big things that we started with if I had to say a third major problem is that the terminal It In order to really be powerful you have to put effort into configuring it And so that configuration is usually in terms of like you configure your prompt or you can figure your completions you can figure your terminal theme in warp We're just like why ship and super underpowered un intuitive version of it as the default experience And so we've basically made all a lot as much of that configuration that can have like a Helpful default we've done So it's like you get completions you get auto suggestions outta the box and everything else we make very easy So it's like very simple to like change your prompt or like change your theme so yeah that's like a again another long probably longer answer than you wanted but that's my like kind of like how we've been thinking about it

Chris:

Yeah That's awesome I think a good part of the frustration that stems from at least the early experience actually having done this for many years also the later experience around terminals is the

Zach:

Ha

Chris:

You know like sometimes mouse selection works Sometimes when you are in a multi-line and you go up it will move up and sometimes it doesn't And that just depends whether I'm in Bash or Shell right now and with Warp it sounds like these things are more consistent and have same defaults to begin with and I don't have to read up on how to configure my such lsh such LRC file before I get any of this

Zach:

Yeah that I mean that's true for the most part And we do work with people's existing shells because we wanted to make it an experience where you could just like Open warp instead of your existing terminal and start working And so we honor you know your Shell's environment variables your path your aliases basically as much of that configuration as we possibly can But we have made some decisions that sort of override what the shell usually does And there's you know there's pros and cons of that From a from an experience standpoint we think the pro Outweigh the cons Obviously everybody wouldn't have done it but yeah One nice thing is you do get the same completions and work whether you're using Bachelors ESH or SSH for that matter which is like I think a really big thing that people like really you can hit a wall using the terminal when you go into some other machine and all of the whole way that that the shell experience works goes away And so we've we're like there's no There's no really good reason for that Let me put it like that So it's like we we've tried to unify that

Chris:

Yeah we've some we've seen some funky stuff where standard in standard out or is passed through a Unix pipe into a different process and all of a sudden so many of the assumptions that

Zach:

Yeah

Chris:

make own shelves just break

Zach:

Yes

Chris:

Yeah I'm curious how like the integration surface with with the shell Like how do you manage to integrate so that you can provide a good experience and yet don't need to make too many in-depth assumptions around how I know Phish works

Zach:

Yeah so this is one of our bigger technical challenges actually so the way that Warp works with the shell in general this is like super high level 10,000 foot view is like when you start a shell warp Basically it passes some extra configuration to that shell that asks the shell to send back a little bit more metadata and puts the shell into like a little bit of a different mode so that our way of doing input and output work with it unifying the behavior across the shells is like we have not yet done it perfectly Like it's a challenging Sort of endeavor for us I actually think at some point warp will probably go deeper down the stack and try to you know actually probably build a shell I don't think we will do this anytime soon because again it's like a there's a lot of existing zsh config and bash config and that type of stuff and plus You know if we assume that Warp had its own shell something like SSH would be very hard cuz you would need that shell running on the remote machine So we've decided not to do that to start But yeah the configuration of the different shells in order to deliver a consistent and really good developer experience in Warp is one of our bigger technical challenges And there's no like super universal solution at this point It's really If there's some issue with fish the way that it does like I don't know hear docs or I don't know if that's a good example but we have to like handle it and make that work And so you know we've done it to the extent that like I would say like 97 or 98% of our users don't hit issues with this but some of them certainly do Yeah It's one I guess if I had to say broader it's one of the challenges is We're trying to innovate on a platform while still being backwards compatible and I would imagine you guys have similar sorts of issues if you just go directly to what you know maybe you think is the ultimate developer experience but don't give people a bridge for moving on to that from their current setup I think it's hard to get adoption if you If you go too far in the direction of compatibility you're really stifled in how you innovate And I like I was I would guess that GI Pot has a similar set of like how do you get people into it challenges And so we definitely have those at Warp

Chris:

Yeah That rings so so close to home on on several levels Like on one hand like on a pure technical perspective you know GPO workspaces are essentially containers You can't just give people a container there's too little that he can do and too much he can do at the same time like in the wrong direction And making that work for the use case that we want to use it for which is essentially you make it behave like a regular Linux machine not what they're built for is a challenge indeed And that's somewhat similar You know what we need to interact with or integrate with that tech stack that was never built for that And then we also need to make Many of the cases work there's no silver bullet there Sometimes you find a bigger lever and then it's really satisfying to pull that But more often than not it's like a case by case thing

Zach:

Yeah it's it totally that makes total sense I mean to give another example from my career like Google Docs had this exact same challenge where There's a huge corpus of existing office files And you know one of the things we really wanted to do was make it very easy for someone who's been a lifelong office user to move on onto onto docs and sheets and slides but the The on the flip side we're like well we also really wanna innovate and we wanna do things beyond from a product experience what office supports and we might wanna do it in ways that like office will never support And so that tension of like make it easy for people to user tool when they have a bunch of legacy stuff versus like innovate on the tool is like a real challenge And I I think companies actually approach this very differently some companies will just be You know screw screw the old thing We're building the ultimate experience We'll only get people who are starting new and that I that can work I think the it's not the approach that we've taken No so it's

Chris:

I think there's a lesson here So if you're working on a DevX team within a company and you want to introduce something chances are you don't get to wait for the people who join new So think about how you get those on board that are already on the team and how you can create adoption and the more successful models of adoption specifically of GI Pod But I'm sure this applies to others too that we've seen within companies is really doing the work of the work going to an individual team make them Solve their problem and then go to the next and solve their problem and then go to the next and solve theirs And as like in computing so often we tend to we're drawn to the allure of generalization and we like to generalize you know premature generalizations the root of all as we know we like to do that And I think for specifically developer experience when we talk about humans this is more even more true than in technology Get people where they are Don't expect them to come to you especially if you're introducing developer like developers particularly opinion A especially if you're introducing that to developers I think that's even more true

Zach:

yeah for sure Totally

Pauline:

you gave a talk at DevX Conf this year about Warp and I recommend everyone who's listening to this to also watch that It was a really good talk with a demo as well I think you mentioned in that session that it was Warp was still in beta Is that right what's the status of Warp now

Zach:

we're in public beta We went in public beta in April So Warp is you can go to Warp's website and download it or you can get warp through homebrew we're still calling it beta because you know the software's truly like there's a bunch of rough edges from like a what I would consider like it's not quite at the quality bar that I would I Remove the beta label but most people who use it are super happy with it we're we're continuing to improve it

Pauline:

Awesome And how many people are using Warp now Out of interest

Zach:

So we're without really like exact numbers we're now like well into the tens of thousands of developers who are using Warp as like their main thing which is pretty cool and it's growing pretty quickly

Chris:

one of the features I noticed when trying Warp was that share the block feature and then also like the AI driven command which is really awesome you mentioned also at the beginning like making things that are a single person thing and making them A collaborative thing is your thing if that makes sense can you speak a bit about what Warp does to make something that used to be my own private space into something that is more useful in combination with others

Zach:

there's two types of things So there's one which is just like the terminal just sort of the way it has existed is like it's like predates the internet So there's no like set of like cloud features And those features can be useful for individuals or teams like the a like The search that uses natural language to give you the command is just like a it's like a cool like you call us out to Codex get a co-pilot and gives you suggestions on how to you know accomplish whatever task you want The other type of feature is like the multiplayer feature that's enabled by the cloud And so like yeah I think the best example that's in the app today is is the ability to for any terminal thing you do any command you You can get a like a link to it which is essentially like it's an alternative to screen sharing it which is much better because it gives you the entire contents of the command So if you have a long command you can't really sort of take a screenshot and get the whole thing it's like copy pastable and selectable and like permanent And so that's like our first sharing feature We're also now starting to do some design partnerships with teams where we're rolling out a suite features where you like within warp you create a team and the terminal becomes a place where you can share knowledge around what you're doing in the terminal And so the simplest example for this is like sharing of commands So if you and your team have a set of commands that you commonly use or even uncommonly use that you wanna organize it could be for things around like building or using your cloud service we're sort of dog footing the ability to natively make that command library template it and share it with people on your team And then there's even like a level up from that which is like sharing a sort of document format within the terminal where the idea behind that is like you know if you had like a sort of terminal notebook it could integrate more deeply with things you could do in the terminal So it's like you Basically like think of it like almost like a modern man page for your tools but that you can like execute things from it You can maybe see history of what you've done you can parameterize it And so have a centralized knowledge store specifically for command line related things that lives within the tool So those are like the first you know multiplayer things that we're building I think down the road there's opportunities there's like a lot of interesting opportunities to make the command line work for teams that go beyond that So like some kind of obvious ideas is just like the ability to share a terminal session in real time This would be like the very flashy like Google Doc style developer experience feature that I think actually would be quite useful for people who are Sort of jointly debugging a firefi or it's like you can imagine a teammate who is stuck on some terminal configuration thing and wants like someone more experience or someone who to like join them and help figure it out And so that that type of stuff is on the roadmap but is a little bit higher of a technical lift and and will becoming not in the next few months but probably more like the next year

Chris:

Yeah That's awesome I could imagine a ton of developer experience around that like it's also one of the feature that we see used a lot when people share workspaces like they also share their terminals and there's live typing in between us literally at the same terminal right It's the same device at the end and that that is so useful especially when you're stuck in the thick of it and you don't get that pixelated screen share thing and trying to make out what someone's currently typing Awesome There is interactive notebooks that we see coming up for like more specialized situations For example like a DevOps style disaster recovery kind of thing or like incident response how do you see terminals play a role there and what you just described

Zach:

it's a good question It's a product thing that I would say we're still figuring out but to me the thing that you want from a terminal product or platform there is some way of like reconstructing what went on across multiple users in that situation if you're doing like a post hoc analysis to understand like who did what when and having the terminal tool make that really easy I think that there's also like an interesting reliability aspect Can you have the terminal be something where when you're actually in the incident it becomes like a place where you can have better visibility into what people are doing And then I think that there's actually like a prior to the incident thing where you know you can make the terminal environment itself a less of a source for production problems And it's probably You know my last company we had an engineer who accidentally deleted our production database because he was happened to be on a machine and didn't realize it And so like doing things around like reliability and error prevention I think are another way the terminal configure into this the whole world of like how do you make your production systems more reliable Both from like a I think like framing it temper like from like a before an in the moment and then an I think that there's a role for it in actually in all of those systems in all of those

Chris:

Yeah it's almost a I guess a classic right Oops wrong box Sorry that R MRF did more than a shot totally

Zach:

there's very famous Dropbox outage where it was is basically that and if you think about it it's like the power that someone has when they're Running like an AWS command or a GCloud command is pretty crazy And the interface is not super forgiving I would say so It's like trying to make that whole flow a more secure auditable flow is a thing I think we could actually have a good impact on A little bit down the road

Chris:

Yeah this is an awesome space Like there there's so much motion in in that space The other day we We had teleport on the show who are also looking at that from a different angle And I would even go so far and say that those solutions are highly complimentary because I look at it from different perspectives Right

Zach:

totally the terminal is not necessarily the best system of record for these things it could be but I think the terminal is like the interface where a lot of this happens

Chris:

Which brings me to one question like the terminal historically is sort of my own private space It's a locked room I have full control over what happens in it now I connect it to the cloud that goes out of the window how do you create trust especially in those you know who come from like this is my box and I do what I want

Zach:

this is a huge issue for us If you look at us on like Hacker News or whatever the number one complaint that people have about Warp is that you have to log in and that you know at least in our beta have been collecting sort of usage data I wanna be very clear nothing you type into warp or none of the things that your commands output are sent to our servers right now And so the main way that we handle this today is just we don't get any of the data And so not getting any of the data Around like what you're actually like doing in the terminal is the first way that we're trying to sort of build trust We're about to remove this requirement around telemetry as we go more and more into the cloud I think the answer is probably the same that any SaaS provider gives which is like security really matters and I like kind of the less data we can have the better So for instance like I don't know common things like we we don't store login data We use Firebase for that And so to the extent that we cannot store data or we can just be a tunnel Where it's like a secure tunnel between two people who are trying to collaborate That's an option So like an end rock style thing But it you know there are gonna be things that we store and in that case it's probably the same as you guys or any other SA service It needs to be stored in a secure fashion we'll sort of explore whether sort of end to end encrypting makes sense We haven't really deeply explored that yet That could be a sort of middle ground we have to have the trust of our users if we're gonna take this tool which is you know like you said someone's sacred space and like a lot of sensitive information flows through it and move it into the cloud I will say that most other times where this has happened it's actually like a security improvement It's not that awesome in general as like a security practice to have everything on your laptop and only on your laptop It doesn't like to not have central administration over a key tool is not generally good and so like you know it's like we we would pitch Google Docs actually It's like kind of it's more secure in a lot of ways in the sense of like you know you lose your laptop you don't lose all your documents And so having a more cloud-enabled system I actually think in the long run Will be a security feature not a security concern but we're not there yet

Chris:

Yeah a hundred percent agree One of the reasons we see folks adopt Gitpod is exactly the endpoint security you don't need to execute code in the same place that your email client runs And your password manager exists and all those nice little secrets lay around So can definitely see that

Pauline:

thanks for the awesome discussion there what we usually do to end the podcast is we like to ask our guests about one thing they'd like to shout out about It could be a learning someone who impacted you and can be tech or non-tech related So over to you Zach What's the one thing you wanna share on this podcast today

Zach:

I was talking to a founder of a pretty cool dev tools company earlier this week so I'll shout them out I don't do you guys know Replay Have you ever heard of So replay is something that you guys you you might be interested in looking at It's a time travel debugger It's built by some of the people who used to be at Mozilla working on like the Firefox dev tools if you could actually make it work super seamlessly I can think of very few things from like a I waste time on then like the time spent trying to reproduce and understand the state around a bug or a crash And so I think it's a very hard technical problem and they're solving it primarily for the web right now So it's not even something we could use at Warp Warp is built entirely in rust but I do think it's a very cool thing to invest in It's one of these things if you could get the developer experience right I think it would have a major impact It's not a new idea like time travel debugging but like no one has actually gotten the DevX around it to a point where you can actually deploy it and so I think it's a they're doing something super cool with it so I'll shout them out

Chris:

Yeah When that works it's close to black magic Like you've had something that that ran in the past and you can step around you can break points you can log things that have already executed That's really fascinating Yeah I have something similar to shout out I haven't actually used the product but I came across it while walking the floor KubeCon and I found it quite interesting it's called rock Out and there are similar services and it's more like the idea it's a service that lets you put They call them non breaking break points in your code that runs in production and that will then emit log statements So you can basically put logs in place that in your production code as it's running that doesn't have logs right now And that's on one hand really exciting because we've all been in a situation where our service does something strange right now And we know that if we restart it to add that log statement or metric or whatever it is we need we're gonna destroy that state It's also terribly frightening thinking about what he can do by exfil trading arbitrary data from a production service But here it is shout out to to rock out

Zach:

That's so cool what platform does it work on Our platforms

Chris:

so it works for I was specifically interested in go and touch script slash node and it works for that they also have run times for other platforms and the really cool thing is that the instrumentation is free until you need it Like there is no runtime overhead So they told me I haven't tried this right so I'm just repeating what I heard But there is no runtime overhead until you give them break point non break break point and before that it's virtually free Similar to what I would imagine Ppro is on go right Virtually free until you needed

Zach:

Yeah I love that Super cool

Pauline:

That's so cool for me I would like to shout out our developer experience community that we launched around like a month ago And there's a bit of activity in that there now of people who are super passionate about developer experience talking About developer experience of different tools similar to the kind of conversations we've had today So if you are listening and you'd like to be part of that you can check the community out at developerexperience.us It is invite Only so you have to go through an application process But if you are really into the dev space feel free to check that out I really needed to plug that because there's some cool conversations going on and I think one of your engineers Zach is actually part of the community and we've had some interesting conversation there

Zach:

Nice I bet it's Elvis if I had to

Pauline:

It is Elvis

Zach:

Yeah

Pauline:

Shout out to Elvis awesome

Zach:

Elvis

Pauline:

Thank you so much for being part of this episode For those who want to learn more about you where can they find you

Zach:

if they really want to talk to me they can just email me zach@warp.dev

Pauline:

Okay Cool Thanks We'll also share some of your links on the show notes Awesome Thank you so much again for joining us Zach we hope to have you on here maybe again at some point Thank you

Zach:

Cool All right Thanks so much Bye guys

Chris:

Thanks for being here

Pauline:

Thank you for listening to this episode of DevX pod. Want to continue the conversation about developer experience? Head over to our community Discord at gitpod.io/chat. We have a dedicated channel there for us to talk all about DevEx.

Chris:

To make sure you don't miss the next episode followers on your favorite podcast platform or subscribe to our newsletter DevEx Digest. You can also find out more about Gitpod on Gitpod.io. Start a new 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