Mike has a passion for empowering people to be creative and work together more effectively. He is the Chief Product Officer at Gitpod striving to remove the friction and drudgery from software development through Cloud Developer Environments. He spent the previous four years at Slack where he created Workflow Builder and “Platform 2.0” after his company Missions was acquired by Slack in 2018. Mike lives in Denver, Colorado and enjoys cycling, hiking and being outdoors.

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.



Corey: It’s easy to **BEEP** up on AWS. Especially when you’re managing your cloud environment on your own!
Mission Cloud un **BEEP**s your apps and servers. Whatever you need in AWS, we can do it. Head to missioncloud.com for the AWS expertise you need.



Corey: Have you listened to the new season of Traceroute yet? Traceroute is a tech podcast that peels back the layers of the stack to tell the real, human stories about how the inner workings of our digital world affect our lives in ways you may have never thought of before. Listen and follow Traceroute on your favorite platform, or learn more about Traceroute at origins.dev. My thanks to them for sponsoring this ridiculous podcast. 

Corey: Welcome to Screaming in the Cloud, I’m Corey Quinn. I have had loud, angry, and admittedly at times uninformed opinions about so many things over the past few years, but something that predates that a lot is my impression on the idea of using remote systems for development work as opposed to doing local dev, and that extends to build and the rest. And my guest today here to argue with me about some of it—or agree; we’ll find out—is Mike Brevoort, Chief Product Officer at Gitpod, which I will henceforth be mispronouncing as JIT-pod because that is the type of jerk I am. Mike, thank you for joining me.

Mike: Thank you for insulting my company. I appreciate it.

Corey: No, by all means, it’s what we do here.

Mike: [laugh].

Corey: So, you clearly have opinions on the idea of remote versus local development that—I am using the word remote development; I know you folks like to use the word cloud, in place of remote, but I’m curious to figure out is, is that just the zeitgeist that has shifted? Do you have a belief that it should be in particular places, done in certain ways, et cetera? Where do your opinion on this start and stop?

Mike: I think that—I mean, remote is accurate, an accurate description. I don’t like to emphasize the word remote because I don’t think it’s important that it’s remote or local. I think that the term cloud connotes different values around the elasticity of environments and the resources that are more than what you might have on your local machine versus a remote machine. It’s not so much whether the one machine is local or remote as much of it is that there are infinite numbers of resources that you can develop across in the cloud. That’s why we tend to prefer our cloud development environments.

Corey: From my perspective, I’ve been spending too many years now living in basically hotels and airports. And when I was doing that, for a long time, the only computer I bring with me has been my iPad Pro. That used to be a little bit on the challenging side and these days, that’s gotten capable enough where it’s no longer interesting in isolation. But there’s no local development environment that is worth basically anything on that. So, I’ve been SSHing into things and using VI as my development environment for many years.

When I started off as a grumpy Unix sysadmin, there was something reassuring about the latest state of whatever it is I’m working on lives in a data center somewhere rather than on a laptop, I’m about to leave behind a coffee shop because I’m careless. So, there’s a definite value and sense that I am doing something virtuous, historically. But it didn’t occur to me till I started talking to people about this, just how contentious the idea was. People would love to ask all kinds of fun objections to this where it was, “Oh, well, what about when you’re on a plane and need to do work?” It’s, well, I spend an awful lot of time on planes and that is not a limiting factor in me writing the terrible nonsense that I will charitably called code, in my case. I just don’t find that that idea holds up anywhere. The world has become so increasingly interconnected that that seems unlikely. But I do live in San Francisco, so here, every internet is generally pretty decent; not every place is. What are your thoughts?

Mike: I agree. I mean, I think one thing is, I would just like not to think about it, whether I can or can’t develop because I’m connected or not. And I think that we tend to be in a world where that is moreso the case. And I think a lot of times when you’re not connected, you become reconnected soon, like if your connection is not reliable or if you’re going in and out of connectivity issues. And when you’re trying to work on a local laptop and you’re connecting and disconnecting, it’s not like we develop these days, and everything is just isolated on our local laptop, especially we talk about cloud a lot on this podcast and a lot of apps now go way beyond just I’m running a process on my machine and I’m connecting to data on my machine.

There are local emulators you could use for some of these services, but most of them are inferior. And if you’re using SQS or using any other, like, cloud-based service, you’re usually, as a developer, connecting to some version of that and if you’re disconnected anyway, you’re not productive either. And so, I find that it’s just like an irrelevant conversation in this new world. And that the way we’ve developed traditionally has not followed along with this view of I need to pile everything in on my laptop, to be able to develop and be productive has not, like, followed along with the trend that moved into the cloud.

Corey: Right. The big problem for a long time has been, how do I make this Mac or Windows laptop look a lot like Linux EC2 instance? And there have been a bunch of challenges and incompatibility issues and the rest, and from my perspective, I like to develop in an environment that at least vaguely resembles the production environment it’s going to run in, which in AWS’s case, of course, comes down to expensive. Bu-dum-tss.

Mike: Yeah, it’s a really big challenge. It’s been a challenge, right? When you’ve worked with coworkers that were on a Windows machine and you were on a Mac machine, and you had the one person on their Linux machine forever, and we all struggled with trying to mimic these development environments that were representative, ultimately, of what we would run in production. And if you’re counting costs, we can count the cost of those cloud resources, we can count the cost of those laptops, but we also need to count the cost of the people who are using those laptops and how inefficient and how much churn they have, and how… I don’t know, there was for years of my career, someone would show up every morning to the stand-up meeting and say, it’s like, “Well, I wasted all afternoon yesterday trying to work out my, you know, issues with my development environment.” And it’s, like, “I hope I get that sorted out later today and I hope someone can help me.”

And so, I think cost is one thing. I think that there’s a lot of inconsistencies that lead to a lot of inefficiencies and churn. And I think that, regardless of where you’re developing, the more that you can make your environments more consistent and sound, not for you, but for your own team and have those be more representative of what you are running in production, the better.

Corey: We should disambiguate here because I fear this is one of the areas where my use case tends to veer off into the trees, which is I tend to operate largely in isolation, from a development point of view. I build small, micro things that wind up doing one thing, poorly. And that is, like, what I do is a proof of concept, or to be funny, or to kick the tires on a new technology. I’ll also run a bunch of random things I find off of JIF-ub—yes, that’s how I pronounce GitHub. And that’s great, but it also feels like I’m learning as a result, every stack, and every language, in every various version that it has, and very few of the cloud development environments that I’ve seen, really seems to cater to the idea that simultaneously, I want to have certain affordances in my shell environment set up the way that I want them, tab complete this particular suite of tools generically across the board, but then reset to that baseline and go in a bunch of different directions of, today, it’s Python in this version and tomorrow, it’s Node in this other version, and three, what is a Typescript anyway, and so on and so forth.

It feels like it’s either, in most cases, you either get this generic, one-size-fits-everyone in this company, for this project, approach, or it’s, here’s a very baseline untuned thing that does not have any of your dependencies installed. Start from scratch every time. And it’s like, feels like there are two paths, and they both suck. Where are you folks at these days on that spectrum?

Mike: Yeah, I think that, you know, one, if you do all of that development across all these different libraries and technology stacks and you’re downloading all these repos from JIF-hub—I say it right—and you’re experimenting, you tend to have a lot of just collision of things. Like if you’re using Python, it’s, like, really a pain to maintain isolation across projects and not have—like, your environment is, like, one big bucket of things on your laptop and it’s very easy to get that into a state where things aren’t working, and then you’re struggling. There’s no big reset on your laptop. I mean, there is but it takes—it’s a full reset of everything that you have.

And I think the thing that’s interesting to me about cloud development environments is I could spin one of these up, I could trash it to all hell and just throw it away and get another one. And I could get another one of those at a base of which has been tuned for whatever project or technology I’m working on. So, I could take—you know, do the effort to pre-setup environments, one that is set up with all of my, like, Python tooling, and another one that’s set up with all my, like, Go or Rust tooling, or our front-end development, even as a base repo for what I tend to do or might tend to experiment with. What we find is that, whether you’re working alone or you’re working with coworkers, that setting up a project and all the resources and the modules and the libraries and the dependencies that you have, like, someone has to do that work to wire that up together and the fact that you could just get an environment and get another one and another one, we use this analogy of, like, tissue boxes where, like, you should just be able to pull a new dev environment out of a tissue box and use it and throw it away and pull as many tissues out of the box as you want. And they should be, like, cheap and ephemeral because—and they shouldn’t be long-lived because they shouldn’t be able to drift.

And whether you’re working alone or you’re working in a team, it’s the same value. The fact that, like, I could pull on these out, I have it. I’m confident in it of what I got. Like for example, ideally, you would just start a dev environment, it’s available instantly, and you’re ready to code. You’re in this project with—and maybe it’s a project you’ve never developed on. Maybe it’s an open-source project.

This is where I think it really improves the sort of equitability of being able to develop, whether it’s in open-source, whether it’s inner-source in companies, being able to approach any project with a click of a button and get the same environment that the tech lead on the project who started it five years ago has, and then I don’t need to worry about that and I get the same environment. And I think that’s the value. And so, whether you’re individual or you’re on a team, you want to be able to experiment and thrash and do things and be able to throw it away and start over again, and not have to—like for example, maybe you’re doing that on your machine and you’re working on this thing and then you actually have to do some real work, and then now that you’ve done something that conflicts with the thing that you’re working on and you’re just kind of caught in this tangled mess, where it’s like, you should just be able to leave that experiment there and just go work on the thing you need to work on. And why can’t you have multiples of these things at any given time?

Corey: Right. One of the things I loved about EC2 dev environments has been that I can just spin stuff up and okay, great, it’s time for a new project. Spin up another one and turn it off when I’m done using it—which is the lie we always tell ourselves in cloud and get charged for things we forget to turn off. But then, okay, I need an Intel box one day. Done. Great, awesome. I don’t have any of those lying around here anymore but clickety, clickety, and now I do.

It’s nice being able to have that flexibility, but it’s also sometimes disconcerting when I’m trying to figure out what machine I was on when I was building things and the rest, and having unified stories around this becomes super helpful. I’m also finding that my overpowered desktop is far more cost-efficient when I need to compile something challenging, as opposed to finding a big, beefy, EC2 box for that thing as well. So, much of the time, what my remote system is doing is sitting there bored. Even when I’m developing on it, it doesn’t take a lot of modern computer resources to basically handle a text editor. Unless it’s Emacs, in which case, that’s neither here nor there.

Mike: [laugh]. I think that the thing that becomes costly, especially when using cloud development environments, is when you have to continue to run them even when you’re not using them for the sake of convenience because you’re not done with it, you’re in the middle of doing some work and it still has to run or you forget to shut it off. If you are going to just spin up a really beefy EC2 instance for an hour to do that big compile and it costs you 78 cents. That’s one thing. I mean, I guess that adds up over time and yes, if you’ve already bought that Mac Studio that’s sitting under your desk, humming, it’s going to be more cost-efficient to use that thing.

But there’s, like, an element of convenience here that, like, what if I haven’t bought the Mac Studio, but I still need to do that big beefy compilation? And maybe it’s not on a project I work on every single day; maybe it’s the one that I’m just trying to help out with or just starting to contribute to. And so, I think that we need to get better about, and something that we’re very focused on at JIT-pod, is—Gitpod—is—

Corey: [laugh]. I’m going to get you in trouble at this rate.

Mike: —[laugh]—is really to optimize that underlying runtime environment so that we can optimize the resources that you’re using only when you’re using it, but also provide a great user experience. Which is, for me, as someone who’s responsible for the product at Gitpod, the thing I want to get to is that you never have to think about a machine. You’re not thinking about this dev environment as something that lives somewhere, that you’re paying for, that there’s a meter spinning that if you forget it, that you’re like, ah, it’s going to cost me a lot of money, that I have to worry about ever losing it. And really, I just want to be able to get a new environment, have one, use it, come back to it when I need it, have it not cost me a lot of money, and be able to have five or ten of those at a time because I’m not as worried about what it’s going to cost me. And I’m sure it’ll cost something, but the convenience factor of being able to get one instantly and have it and not have to worry about it ultimately saves me a lot of time and aggravation and improves my ability to focus and get work done.

And right now, we’re still in this mode where we’re still thinking about, is it on my laptop? Is it remote? Is it on this EC2 instance or that EC2 instance? Or is this thing started or stopped? And I think we need to move beyond that and be able to just think of these things as development environments that I use and need and they’re there when I want to, when I need to work on them, and I don’t have to tend to them like cattle.

Corey: Speaking of tending large things in herds—I guess that’s sort of for the most tortured analogy slash segway I’ve come up with recently—you folks have a conference coming up soon in San Francisco. What’s the deal with that? And I’ll point out, it’s all on-site, locally, not in the cloud. So, hmm…

Mike: Yeah, so we have a local conference environment, a local conference that we’re hosting in San Francisco called CDE Universe on June 1st and 2nd, and we are assembling all the thought leaders in the industry who want to get together and talk about where not just cloud development is going, but really where development is going. And so, there’s us, there’s a lot of companies that have done this themselves. Like, before I joined Gitpod, I was at Slack for four years and I got to see the transition of a, sort of, remote development hosted on EC2 instances transition and how that really empowered our team of hundreds of engineers to be able to contribute and like work together better, more efficiently, to run this giant app that you can’t run just alone on your laptop. And so, Slack is going to be there, they’re going to be talking about their transition to cloud development. The Uber team is going to be there, there’s going to be some other companies.

So, Nathan who’s building Zed, he was the one that originally built Adam at GitHub is now building Zed, which is a new IDE, is going to be there. And I can’t mention all the speakers, but there’s going to be a lot of people that are really looking at how do we drive forward development and development environments. And that experience can get a lot better. So, if you’re interested in that, if you’re going to be in San Francisco on June 1st and 2nd and want to talk to these people, learn from them, and help us drive this vision forward for just a better development experience, come hang out with us.

Corey: I’m a big fan of collaborating with folks and figuring out what tricks and tips they’ve picked up along the way. And this is coming from the perspective of someone who acts as a solo developer in many cases. But it always drove me a little nuts when you see people spending weeks of their lives configuring their text editor—VIM in my case because I’m no better than these people; I am one of them—and getting it all setup and dialed in. It’s, how much productivity you gaining versus how much time are you spending getting there?

And then when all was said and done a few years ago, I found myself switching to VS Code for most of what I do, and—because it’s great—and suddenly the world’s shifting on its axis again. At some point, you want to get away from focusing on productivity on an individualized basis. Now, the rules change when you’re talking about large teams where everyone needs a copy of this running locally or in their dev environment, wherever happens to be, and you’re right, often the first two weeks of a new software engineering job are, you’re now responsible for updating the onboarding docs because it’s been ten minutes since the last time someone went through it. And oh, the versions bumped again of what we would have [unintelligible 00:16:44] brew install on a Mac and suddenly everything’s broken. Yay. I don’t miss those days.

Mike: Yeah, the new, like, ARM-based Macs came out and then you were—now all of a sudden, all your builds are broken. We hear that a lot.

Corey: Oh, what I love now is that, in many cases, I’m still in a process of, okay, I’m developing locally on an ARM-based Mac and I’m deploying it to a Graviton2-based Lambda or instance, but the CI/CD builder is going to run on Intel, so it’s one of those, what is going on here? Like, there’s a toolchain lag of round embracing ARM as an architecture. That’s mostly been taken care of as things have evolved, but it’s gotten pretty amusing at some point, just as quickly that baseline architecture has shifted for some workloads. And for some companies.

Mike: Yeah, and things just seem to be getting more [laugh] and more complicated not less complicated, and so I think the more that we can—

Corey: Oh, you noticed?

Mike: Try to simplify build abstractions [laugh], you know, the better. But I think in those cases where, I think it’s actually good for people to struggle with setting up their environment sometime, with caring about the tools that they use and their experience developing. I think there has to be some ROI with that. If it’s like a chronic thing that you have to continue to try to fix and make better, it’s one thing, but if you spend a whole day improving the tools that you use to make you a better developer later, I think there’s a ton of value in that. I think we should care a lot about the tools we use.

However, that’s not something we want to do every day. I mean, ultimately, I know I don’t build software for the sake of building software. I want to create something. I want to create some value, some change in the world. There’s some product ultimately that I’m trying to build.

And, you know, early on, I’ve done a lot of work in my career on, like, workflow-type builders and visual builders and I had this incorrect assumption somewhere along the way—and this came around, like, sort of the maker movement, when everybody was talking about everybody should learn how to code, and I made this assumption that everybody really wants to create; everybody wants to be a creator, and if given the opportunity, they will. And I think what I finally learned is that, actually most people don’t like to create. A lot of people just want to be served; like, they just want to consume and they don’t want the hassle of it. Some people do, if they have the opportunity and the skillsets, too, but it’s also similar to, like, if I’m a professional developer, I need to get my work done. I’m not measured on how well my local tooling is set up; I’m sort of measured on my output and the impact that I have in the organization.

I tend to think about, like, chefs. If I’m a chef and I work 60 hours in a restaurant, 70 hours in a restaurant, the last thing I want to do is come home and cook myself a meal. And most of the chefs I know actually don’t have really nice kitchens at home. They, like, tend to, they want other people to cook for them. And so, I think, like, there’s a place in professional setting where you just need to get the work done and you don’t want to worry about all the meta things and the time that you could waste on it.

And so, I feel like there’s a happy medium there. I think it’s good for people to care about the tools that they use the environment that they develop in, to really care for that and to curate it and make it better, but there’s got to be some ROI and it’s got to have value to you. You have to enjoy that. Otherwise, you know, what’s the point of it in the first place?

Corey: One thing that I used to think about was that if you’re working in regulated industries, as I tended to a fair bit, there’s something very nice about not having any of the data or IP or anything like that locally. Your laptop effectively just becomes a thin client to something that’s already controlled by the existing security and compliance apparatus. That’s very nice, where suddenly it’s all someone steals my iPad, or I drop it into the bay, it’s locked, it’s encrypted. Cool, I go to the store, get myself a new one, restore a backup from iCloud, and I’m up and running again in a very short period of time as if nothing had ever changed. Whereas when I was doing a lot of local development and had bad hard drive issues in the earlier part of my career, well, there goes that month.

Mike: Yeah, it’s a really good point. I think that we’re all walking around with these laptops with really sensitive IP on it and that those are in bars and restaurants. And maybe your drives are encrypted, but there’s a lot of additional risks, including, you know, everything that is going over the network, whether I’m on a local coffee shop, and you know, the latest vulnerability that, an update I have to do on my Mac if I’m behind. And there’s actually a lot of risk and having all that just sort of thrown to the wind and spread across the world and there’s a lot of value in having that in a very safe place. And what we’ve even found that, at Gitpod now, like, the latest product we’re working on is one that we called Gitpod Dedicated, which gives you the ability to run inside your own cloud perimeter. And we’re doing that on AWS first, and so we can set up and manage an installation of Gitpod inside your own AWS account.

And the reason that became important to us is that a lot of companies, a lot of our customers, treat their source code as their most sensitive intellectual property. And they won’t allow it to leave their perimeter, like, they may run in AWS, but they have this concept of, sort of like, our perimeter and you’re either inside of that and outside of it. And I think this speaks a little bit to a blog post that you wrote a few months ago about the lagging adoption of remote development environments. I think one of those aspects is, sort of, convenience and the user experience, but the other is that you can’t use them very well with your stack and all the tools and resources that you need to use if they’re not running, sort of, close within your perimeter. And so, you know, we’re finding that companies have this need to be able to have greater control, and now with the, sort of, trends around, like, coding assistance and generative AI and it’s even the perfect storm of not only am I like sending my source code from my editor out into some [LM 00:22:36], but I also have the risk of an LM that might be compromised, that’s injecting code and I’m committing on my behalf that may be introducing vulnerabilities. And so, I think, like, getting that off to a secure space that is consistent and sound and can be monitored, to be kept up-to-date, I think it has the ability to, sort of, greatly increase a customer’s security posture.

Corey: While we’re here kicking the beehive, for lack of a better term, your support for multiple editors in Gitpod the product, I assumed that most people would go with VS Code because I tend to see it everywhere, and I couldn’t help but notice that neither VI nor Emacs is one of the options, the last time I checked. What are you seeing as far as popularity contests go? And that might be a dangerous question because I’m not suggesting you alienate many of the other vendors who are available, but in the world I live in, it’s pretty clear where the zeitgeist of my subculture is going.

Mike: Yeah, I mean, VS Code is definitely the most popular IDE. The majority of people that use Gitpod—and especially we have a, like, a pretty heavy free usage tier—uses it in the browser, just for the convenience of having that in the browser and having many environments in the browser. We tend to find more professional developers use VS Code desktop or the JetBrains suite of IDEs.

Corey: Yeah, JetBrains I’m seeing a fair bit of in a bunch of different ways and I think that’s actually most of what your other options are. I feel like people have either gone down the JetBrains path or they haven’t and it seems like it’s very, people who are into it are really into it and people who are not are just, never touch it.

Mike: Yeah, and we want to provide the options for people to use the tools that they want to use and feel comfortable on. And we also want to provide a platform for the next generation of IDEs to be able to build on and support and to be able to support this concept of cloud or remote development more natively. So, like I mentioned, Nathan Sobo at Zed, I met up with him last week—I’m in Denver; he’s in Boulder—and we were talking about this and he’s interested in Zed working in the browser, and he’s talked about this publicly. And for us, it’s really interesting because, like, IDEs working in the browser is, like, a really great convenience. It’s not the perfect way to work, necessarily, in all circumstances.

There’s some challenges with, like, all this tab sprawl and stuff, but it gives us the opportunity, if we can make Zed work really well in for Gitpod—or anybody else building an IDE—for that to work in the browser. Ultimately what we want is that if you want to use a terminal, we want to create a great experience for you for that. And so, we’re working on this ability in Gitpod to be able to effectively, like, bring your own IDE, if you’re building on that, and to be able to offer it and distribute on Gitpod, to be able to create a new developer tool and make it so that anybody in their Gitpod workspace can launch that as part of their workspace, part of their tool. And we want to see developer tools and IDEs flourish on top of this platform that is cloud development because we want to give people choice. Like, at Gitpod, we’re not building our own IDE anymore.

The team started to. They created Theia, which was one of the original cloud, sort of, web-based IDEs that now has been handed over to the Eclipse Foundation. But we moved to VS Code because we found that that’s where the ecosystem were. That’s where our users were, and our customers, and what they wanted to use. But we want to expand beyond that and give people the ability to choose, not only the options that are available today but the options that should be available in the future. And we think that choice is really important.

Corey: When you see people kicking the tires on Gitpod for the first time, where does the bulk of their hesitancy come from? Like, what is it where—people, in my experience, don’t love to embrace change. So, it’s always this thing, “This thing sucks,” is sort of the default response to anything that requires them to change their philosophy on something. So okay, great. That is a thing that happens. We’ll see what people say or do. But are they basing it on anything beyond just familiarity and comfort with the old way of doing things or are there certain areas that you’re finding the new customers are having a hard time wrapping their head around?

Mike: There’s a couple of things. I think one thing is just habit. People have habits and preferences, which are really valuable because it’s the way that they’ve learned to be successful in their careers and the way that they expect things. Sometimes people have these preferences that are fairly well ingrained that maybe are irrational or rational. And so, one thing is just people’s force of habit.

And then getting used to this idea that if it’s not on my laptop, it means—like what you mentioned before, it’s always what-ifs of, like, “What if I’m on a plane?” Or like, “What if I’m at the airport in a hurricane?” “What if I’m on a train with a spotty internet connection?” And so, there’s all these sort of what-if situations. And once people get past that and they start actually using Gitpod and trying to set their projects up, the other limiting factor we have is just connectivity.

And that’s, like, connectivity to the other resources that you use to develop. So, whether that’s, you know, package or module repositories or that some internal services or a database that might be running behind a firewall, it’s like getting connectivity to those things. And that’s where the dedicated deployment model that I talked about, running inside of your perimeter on our network, they have control over, kind of helps, and that’s why we’re trying to overcome that. Or if you’re using our SaaS product, using something like Tailscale or a more modern VPN that way. But those are the two main things.

It’s like familiarity, this comfort for how to work, sort of, in this new world and not having this level of comfort of, like, it’s running on this thing I can hold, as well as connectivity. And then there is some cost associated with people now paying for this infrastructure they didn’t have to pay for before. And I think it’s a, you know, it’s a mistake to say that we’re going to offset the cost of laptops. Like, that shouldn’t be how you justify a cloud development environment. Like—

Corey: Yeah, I feel like people are not requesting under-specced laptops much these days anymore.

Mike: It’s just like, I want to use a good laptop; I want to use a really nice laptop with good hardware and that shouldn’t be the cost. The proposition shouldn’t be, it’s like, “Save a thousand dollars on every developer’s laptop by moving this off to the cloud.” It’s really the time savings. It’s the focus. It’s the, you know, removing all of that drift and creating these consistent environments that are more secure, and effectively, like, automating your development environment that’s the same for everybody.

But that’s the—I think habits are the big thing. And there is, you know, I talked about a little bit that element of, like, we still have this concept of, like, I have this environment and I start it and it’s there, and I pay for it while it’s there and I have to clean it up or I have to make sure it stopped. I think that still exists and it creates a lot of sort of cognitive overhead of things that I have to manage that I didn’t have to manage before. And I think that we have to—Gitpod needs to be better there and so does everybody else in the industry—about removing that completely. Like, there’s one of the things that I really love that I learned from, like, Stewart Butterfield when I was at Slack was, he always brought up this concept called the convenience threshold.

And it was just the idea that when a certain threshold of convenience is met, people’s behavior suddenly changes. And as we thought about products and, like, the availability of features, that it really drove how we thought about even how to think about you know, adoption or, like, what is the threshold, what would it take? And, like, a good example of this is even, like, the way we just use credit cards now or debit cards to pay for things all the time, where we’re used to carry cash. And in the beginning, when it was kind of novel that you could use a credit card to pay for things, like even pay for gas, you always had to have cash because you didn’t know if it’d be accepted. And so, you still had to have cash, you still had to have it on hand, you still had to get it from the ATM, you still have to worry about, like, what if I get there and they don’t accept my cards and how much money is it going to be, so I need to make sure I have enough of it.

But the convenience of having this card where I don’t have to carry cash is I don’t have to worry about that anymore, as long as they have money in my bank account. And it wasn’t until those cards were accepted more broadly that I could actually rely on having that card and not having the cash. It’s similar when it comes to cloud development environments. It needs to be more convenient than my local development environment. It needs to be—it’s kind of like early—I remember when laptops became more common, I was used to developing on a desktop, and people were like, nobody’s ever going to develop on a laptop, it’s not powerful enough, the battery runs out, I have to you know, when I close the lid, when you open the lid, it used to take, like, five minutes before, like, it would resume an unhibernate and stuff, and it was amazing where you could just close it and open it and get back to where you were.

But like, that’s the case where, like, laptops weren’t convenient as desktops were because they were always plugged in, powered on, you can leave them and you can effectively just come back and sit down and pick up where you left off. And so, I think that this is another moment where we need to make these cloud development environments more convenient to be able to use and ultimately better. And part of that convenience is to make it so that you don’t have to think about all these parts of them of whether they’re running, not running, how much they cost, whether you’re going to be there [unintelligible 00:31:35] or lose their data. Like, that should be the value of it that I don’t have to think about any of that stuff.

Corey: So, my last question for you is, when you take a look at people who have migrated to using Gitpod, specifically from the corporate perspective, what are their realizations after the fact—I mean, assuming they still take your phone calls because that’s sort of feedback of a different sort—but what have they realized has worked well? What keeps them happy and coming back and taking your calls?

Mike: Yeah, our customers could focus on their business instead of focusing on all the issues that they have with configuring development environments, everything that could go wrong. And so, a good example of this is a customer they have, Quizlet, Quizlet saw a 45-point increase in developer satisfaction and a 60% reduction in incidents, and the time that it takes to onboard new engineers went down to ten minutes. So, we have some customers that we talk to that come to us and say, “It takes us 20 days to onboard an engineer because of all the access they need and everything you need to set up and credentials and things, and now we could boil that down to a button click.” And that’s the thing that we tend to hear from people is that, like, they just don’t have to worry about this anymore and they tend to be able to focus on their business and what the developers are actually trying to do, which is build their product.

And in Quizlet’s example, it was really cool to see them mention in one of the recent OpenAI announcements around GPT4 and plugins is they were one of the early customers that built GPT4 plugins, or ChatGPT, and they mentioned that they were sharing a lot of Gitpod URLs around when we reached out to congratulate them. And the thing that was great about that, for us is, like, they were talking about their business and what they were developing and how they were being successful. And we’d rather see Gitpod in your development environment just sort of disappear into the background. We’d actually like to not hear from customers because it’s just working so well from them. So, that’s what we found is that customers are just able to get to this point where they could just focus on their business and focus on what they’re trying to develop and focus on making their customers successful and not have to worry about infrastructure for development.

Corey: I think that really says it all. On some level, when you have customers who are happy with what’s happening and how they’re approaching this, that really is the best marketing story I can think of because you can say anything you want about it, but when customers will go out and say, “Yeah, this has made our lives better; please keep doing what you’re doing,” it counts for a lot.

Mike: Yeah, I agree. And that’s what we’re trying to do. You know, we’re not trying to win, sort of, a tab versus spaces debate here around local or cloud or—I actually just want to enable customers to be able to do their work of their business and develop software better. We want to try to provide a method and a platform that’s extensible and customizable and gives them all the power they need to be able to just be ready to code, to get to work as soon as they can.

Corey: I really want to thank you for being so generous with your time. If people want to learn more, where’s the best place for them to find you, other than at your conference in San Francisco in a few weeks?

Mike: [laugh]. Yeah, thank you. I really appreciate the banter back and forth. And I hope to see you there at our conference. You should come. Consider this an invite for June 1st and 2nd in San Francisco at CDE Universe.

Corey: Of course. And we will put links to this in the [show notes 00:34:53]. Thank you so much for being so generous with your time. I appreciate it.

Mike: Thanks, Corey. That was really fun.

Corey: Mike Brevoort, Chief Product Officer at Gitpod. I’m Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment detailing exactly why cloud development is not the future, but then lose your content halfway through because your hard drive crashed.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.