Ep. #115, Reimagining Terminals with Zach Lloyd of Warp

Brian Douglas: Welcome to another installment of Jamstack Radio. On the line we've got Zach Lloyd. Welcome. How are you doing?

Zach Lloyd: I'm doing great. Really excited to be here, Brian. Thank you so much for having me on.

Brian: Perfect. Yeah, so we chatted actually maybe a few weeks ago, maybe a month ago. But we talked about Warp, and I want to get into what Warp is. But first can you intro who Zach is?

Zach: Sure. So yeah, I'm Zach. I guess primarily I would describe myself as a software developer, I've been a developer for the past 20 something years. I'm also at this point a startup founder, I'm an ex-Googler, I used to be the engineering lead on Google Sheets and helped build that product, and then engineering lead on the Google Doc Suite when I was at Google.

So I really like being collaborative productivity software. I am on my second startup now, and I really like-- If I had to sum it up, I like taking things that are crappy software or old school software, non collaborative software and try my best to make them into a more modern, better software experience that's more cloud oriented. That's most of what I've done in my career.

Brian: Yeah, that's awesome. I didn't know about the background in Google Sheets as well. Big fan, I use it all the time.

Zach: Cool. I'm glad you use it. Any bugs? People used to, whenever I say that, they would always be like, "Ah, I really love Google Sheets. But do you know that you can't do X that you can do in Excel?" That's the most common.

Brian: Yeah. Most of my bugs would've come from Excel. I have a finance degree and I spent a lot of time in Excel, learning how to do macros and calculations and stuff like that, so I think probably 10 years ago I might have tried to convert all my stuff from Excel to free Google Sheets and it just wasn't there yet. I haven't attempted that. I don't use Excel the way I used to do it back when I had to do finance, but yeah, have not attempted to do any of that stuff since then.

Zach: It's getting better every time I use it. I haven't worked on it for six or seven years. Every time I use it, it gets better. It's very hard to make it as good as Excel. A big part of that has to do with the fact that it's built in the web platform, which is also its biggest advantage, is that it's built in the web platform and so it's inherently collaborative. You get to it via a link, which is awesome. But to get the performance as good as Excel was always a major, major challenge and very, very hard to accomplish.

Brian: Yeah, yeah. I believe it, that sounds like a hard problem I don't want to work on. But speaking of which, I'll circle back on some other questions about Google Sheets. But some other hard problems is building terminals, want to talk about what is Warp and what's the deal over there?

Zach: Yeah. So Warp is a company that I founded a little over two years ago. The product is a complete reinvention of the terminal. It's built in Rust, so it's a totally native app. The problems that we're trying to fix are basically that terminal is a super widely used tool, it's probably used by every developer every day, whether they want to or not.

All sorts of developer activities flow through it, whether you're using Vim and coding in it, or you're building your code, or you're using CLIs to interact with different cloud services. It's like a Swiss army knife, a ton of different use cases.

My take on the product experience of using the terminal is it's traditionally been a pretty poor piece of software from a usability perspective. It's a thing that's hard to learn, I think it's intimidating to a lot of new developers, it's very easy to make catastrophic mistakes in it and the mouse doesn't work in it.

So the idea behind Warp is to rethink it from first principles, look at what developers do in the terminal and try to build an app that feels modern and makes them much more efficient in it, makes them more productive, makes them less frustrated. It really makes it so that any user can get the most power out of the tool, so that's the big vision.

Brian: Maybe it's similar or it's relevant because we almost had a whole another podcast about Excel, but Excel is one of those tools that you deal with it, it's been around for a bit. Even Google Sheets, spreadsheets in general, we'll zoom out into spreadsheets. It's a software that you just accept its limitations, and the terminal is the same thing. I've been a regular terminal user on the Mac since I started programming on a Mac.

I used to do PC programming, college days. But since Mac, terminal, I don't need iTerm, I don't need all this other stuff. I just used terminal. I know how to get around with just terminal and I accept its limitations. My first experience in Warp, which we can get into more details on why you built Warp and what led you to that decision, but it just makes so much more sense. I question my life decisions for the past five years of not even trying iTerm, to be honest. It's intuitive in the sense that I kind of wish this was fixed and approached earlier.

Zach: Yeah. So first of all, thank you. I'm glad that you had that reaction. The really big differences out of the gate that someone will see is that the two main things that people do in the terminal is they enter commands and they look at the output. We just changed the way those two fundamental UI primitives work. We basically give you structure around the output, which makes a ton of sense.

You enter a command and that command produces output, and it makes sense that you'd want to be able to do things with that output as one unit. Then the input is so frigging weird in a normal terminal. The mouse doesn't work, you can't double click and delete things. You kind of have to unlearn everything that you are used to doing in every other app, whether you're in VSCode or Google Docs or whatever, to use the terminal input.

And so we were just like, "It shouldn't work like that, let's try to build a thing actually in a way that if you were building it from scratch, you would try to make it right." So yeah, that aligns with what you're saying.

Brian: Yeah. It gives a sense of everything I learned about programming I learned on the job through a coworker or a more senior engineer that just knew their way around the terminal better. So it'd be like we're in a pair on a problem, I'll stop them and say, "Hey, what did you do there?" And my example is the control R thing, I didn't know that until like five years into my career.

Zach: That's insane.

Brian: That you can go into history and be like, "Oh, you don't have to just keep hitting up until you get to what you need."

Zach: That's insane. Honestly, I think I learned that the same way. I was at Google and I think it was this guy Josh on my team, who I saw him pulling up old commands and you're like, "Whoa, what?" Because, yeah, the terminal, it's not really interested in helping its users learn how to use it effectively. I think in an extreme case, there's almost like a rite of passage or something where it's like developers, some of them, I would say, like the steepness of the learning curve.

It feels like if you learn the magical incantation to do something, all of a sudden you can do a thing that just seems like crazy you couldn't do that before. I do think on the whole that's probably not how it should work though, and it's not the best thing for the world of software development that the terminal has to be such a weirdly opaque, old school UI.

Brian: Yeah. I think there's sort of a... I don't want to say arms race because I feel like it's a bad analogy. But there's this movement of people now improving situations in developer experiences. I worked at Netlify previously and they deployed apps to the cloud easier. It was all built on Kubernetes, anybody could've built their own Kubernetes cluster to make this work.

But what Netlify said is, "You don't need to learn Kubernetes. You can have these deploys happen automagically." Every other cloud provider today does the same thing, but now we're seeing this now with databases and IDEs and terminals. It's wild that there's not more terminals to choose from.

I mean, there's probably a ton, but the expectation is that it is a rite of passage or there's a crew of folks who choose this terminal and we will learn it together, and there's a community. It's sort of like, not gatekeeping, but essentially gatekeeping of like, "Yeah, we know how to use this thing, we know how to be powerful and wizards in the terminal. We will keep it that way."

Zach: Yeah. Definitely, like you said, there's a trend right now of how do you give developers first class user experiences. Netlify is a great example. Even in developer adjacent tools like Linear, the task tracking tool. I think that they're trying really hard to just make the experience of the tools developers use every day, more consumer grade.

I think companies are realizing that developer time is a very valuable commodity and developer happiness using their tools really matters a lot, and so there's a lot of economic incentive for making these tools more productive and more seamless and less frustrating and less error prone.

So yeah, I guess I don't know why it's taken so long and it's probably different for each of these different parts of the stack. But the developers, just like any other user, I think deserve a really seamless, polished user experience and that's a big part of what we're going for.

Brian: Yeah. I wanted to dig in deeper on the Rust connection and the decision towards building with Rust. So did you have a lot of experience with Rust prior to making that technical decision?

Zach: No, zero. Zero experience of Rust. My history is as a developer in web tech primarily. I've done a lot of development in JavaScript, I've done a lot of development in Java on the server side, I've done native iOS development. Back when I was in school I did C and C++ development. But I'd never done Rust development. We prototyped Rust as an Electron app, and Warp is a desktop app.

I guess one thing to just clarify, terminals kind of still need to be desktop apps just because they access your local file system and I do think there's advantage to a terminal that can work in the browser, but it's not the primary use case. So we did an Electron prototype, it was pretty quick to build but didn't perform very well. Very heavy resource usage and higher operational latency in terms of framerate, lower throughput in terms of rendering a lot of data, if you're catting a log file it goes by very quickly.

We thought from a developer experience standpoint that performance is really, really important. Especially for this tool, a lot of times if you're doing something in the terminal, you're doing it all hands on keyboard, you want speed, you want flexibility, you want efficiency and so we just decided to look at what would be the fastest stack to build this in.

Rust was something that we'd learned about, we had someone join us on the team early who had experience with Rust, who had developed some code in Rust that was actually important for getting us going. Then we all learned it, and it was one of the more important decisions that we made and a decision I'm super happy with, as far as how the app now is. It's not just that the app is in Rust, it's in Rust and we do the full stack of rendering.

Meaning that we have our own UI framework that's written in Rust, we interface with the graphics code directly so on Mac that API is Metal, and so we have our own shader code and there's always a lot of overhead and you give up a bunch of stuff when you say, "Okay, I'm going to build the whole stack." But from a product quality standpoint and from us controlling the way the app works standpoint, it was a really good decision that I'm super happy.

The Rust community is awesome. Rust gets us a lot of marketing value, a lot of developers are just into Rust. Rust is helpful on the recruiting side, a lot of really awesome engineers want to build things in Rust. So yeah, it's been awesome.

Brian: Yeah, yeah. It's valuable, and I know I'm blanking on the VC, but there's a VC that's very, very adamant about investing in Rust forward companies.

Zach: Oh, really? That's funny.

Brian: Yeah. We don't need to call out all the VCs on this podcast, but yeah, I follow him on Twitter and their portfolio is every cutting edge Rust tool, which we can talk about offline.

Zach: That's a hilarious thesis, I guess that makes some sense.

Brian: Yeah. It's a dev tool VC, so it's a smaller, up and coming one. So they're making some bets on the future of Rust, which Rust has been around for quite a bit of time. I spent a lot of time working in Go, I guess around six or seven years ago. At that time I had spent some time learning Rust and it was pre 1.0. It was too early for me to even get into systems programming, because I was mainly a web dev and I was just tinkering. Just didn't have enough infrastructure and documentation for me to keep going on that. But I'm happy to see Rust now it's solidified itself in the industry and figured its way into web programming and other places.

Zach: Yeah. It's evolving very quickly. Our server is not built in Rust, our server is built in Go, and we made that decision at the time based on the maturity of all of the cloud infrastructure around server hosting on Rust. I personally don't know if that was even the right decision, but people on our team are happy with that decision. But yeah, I've been really impressed with Rust as a language, and there's a steep learning curve. The benefit, actually it's not just that your app is fast if you build it right. We just don't have many crashes. You have to work to do null pointer dereferences and memory leaks and that type of stuff in Rust, so it's a rigid language that I think forces you to actually program in a pretty effective way.

Brian: Yeah. So you mentioned a bit of this earlier when you were describing Warp, but I'm curious if you could run down some features that make it different from other terminals?

Zach: Yeah. So there's two classes of features in Warp. One is features around making the individual user experience better, and I talked about some of those. Warp has its own input editor, Warp has this concept of output blocks. The other set of features is not as developed, but basically we're trying to make the terminal into a cloud native collaborative app. A thing you can do in Warp that doesn't exist in any other terminal is any command you run, you can basically get a permalink to its output that you can share with people on your team, is an example of that.

Another really cool feature to leverage is the cloud, as we have an integration with Open AI Codex, and so you can do natural language command search in Warp. So you can be like, "What's the command for tarring up all the files in this directory?" Which is, I don't know, tar X CVN, whatever it is. It just tells you, and it works pretty remarkably well. That's another cloud based feature we have.

Then other interesting things I would call out, other terminals really require quite a bit of configuration in order to get to a point where you're more powerful than them, and Warp just ships with things out of the box that makes life easier. So for instance, we ship with completions for about 500 commands, we ship with this feature called workflows, which is basically templatized snippets for commonly used commands. We ship now, as of last week, with syntax highlighting and auto suggestions. We give you a read dash if your command has an error in it, kind of like auto error correction.

So a lot of things that people would previously search on GitHub to find a project that makes the terminal better, we just have incorporated it and integrated it into the product, and sometimes in collaboration with these other open source tools which exist. But the idea is that you shouldn't have to spend a ton of time configuring your terminal to get a power user experience out of it.

Brian: Yeah. That's what I do appreciate as well, because I don't know all the stuff you need to know to make the terminal as useful as it can be. So tmux is one thing that I've never really dug super deep into, I know how to use it and how to spin up a server to then call somewhere else, but I'm curious of the collaboration features like being able to share environments across machines.

Personally, I use Warp specifically, so I am a Warp user if anyone is listening and wants to know. But I have one machine that I only do side project work on and a bunch of writing, so it's a third tenant MacBook that I keep upstairs, away from the regular office setup, just to be in a different head space.

I made a point to put Warp on there and getting started, getting every environment like my Zsh and all the stuff, it was pretty quick. I was able to be productive very quick, which I can't say when I bought this M1 machine. It took me about a half a day until I think about, "Oh, what do I need to install? How do I set this up?"

Zach: Yeah. So one feature that we haven't built, just to speak to your current use case, that we would like to build is the ability that when you log into Warp, no matter what computer you're on, it could be a brand new computer, that all of your settings are just there. Like the way Chrome Sync works, for instance. Another collaborative feature that we have in the works right now that is not yet publicly launched, but we're doing some testing with design partner teams, is around making it really easy to share a library of terminal commands, and even share documentation around those commands via something that looks a little bit like a notebook that lives in the terminal.

The idea there is that there is a lot of knowledge that is living in single developer's heads when they use the terminal, that would be beneficial to the rest of their team members to have a way of searching through, executing, updating, keeping everyone in sync. That could be like making it really easy to onboard into a particular environment, or it could be you're doing some production DevOps task like you're upgrading a database. What are all the steps that you need to do? That sort of documentation lives outside of the tool right now, in large part, and we're trying to make it easier and more seamless to bring it in.

Brian: Cool. Yeah, I'm looking forward to that shipping as well because I can have that sync on my main machine, and then I'm good to go forever, as long as Warp keeps shipping updates. Cool. Curious of the business model, how are y'all making money? Are you just going for mass user adoption or is there an actual teams plan or something like that?

Zach: So at the moment there is no paid Warp plan, Warp is totally free. We have no plans to charge individual Warp users ever. The idea is at the moment just build something that developers love, that they want to use for work, that they want to use for personal, and that it makes them more productive. And so we're just trying to basically get as many people to try Warp as possible at the moment.

The eventual business model that we're planning on pursuing is around enterprise and team features. So the goal is not to charge individual developers for using Warp, it's to build something that's valuable to a whole team that doesn't even exist right now, build something that makes the whole terminal more valuable to a company, where a company would buy it for its developers and make money that way.

Just some other things to clarify, when you use Warp, none of your terminal data goes to our servers. We don't know what command you're typing, we don't know what the output is. We do, at the moment, collect telemetry, meaning how many new tabs did you make or that type of thing. We're adding a feature to disable that. But the plan is never to make money around peoples' data or anything like that.

We really want to build something that is useful and makes teams more productive, makes their environment more secure, makes their systems more reliable, and charge for that. That's the goal. But we're not in a big rush to try to monetize it, we're in a big rush right now to just try to make the product really good for developers.

Brian: Yeah. That seems like a pretty valuable path as well, because one of the things, I worked at a startup back in 2015, I remember reading a blog post before I worked at GitHub, about how GitHub set up their environments for new engineers at GitHub. It was through a bunch of script commands, and that encouraged us for our team to set up our environments where it's reproducible really quickly.

So spill a beer on your machine, you could be coding by the afternoon on a new machine, pretty quickly. So as far as setting up teams, even at Open Sauce, we don't have a big team but as we look to hire in the future, we want people to be successful pretty quickly, or be able to ship code pretty quickly. We have a lot of nuance and stuff to jump into, or-

Zach: Source of truth?

Brian: Source of truth, yes. We want a single source of truth of like, "Okay, this is how environments get set up at Open Sauce, or XYZ enterprise."

Zach: Yes. I guess out of curiosity, do you use code spaces? Have you tried to do it like that?

Brian: At GitHub they use code spaces for obvious reasons. I'll be honest, inside baseball, not everyone is using code spaces internally so you're not going to rip the terminal out of every engineer's hands. At Open Sauce we don't use code spaces because I know how much it cost, and we're not ready to pay for that.

Zach: Super interesting. I'm very interested in how the transition to remote development environments will go, and I'm also very interested in the question of how do you make it very easy to standardize the development environment. There's a lot of different approaches to this, and whenever I talk to a new startup I always ask, like, "What are you doing for this?"

Brian: Yeah. We can talk more about this offline, but let's just say when Microsoft is providing compute for code spaces, there's a bit of a discount happening there, and every other startup that's in this space has a lot of credits so everyone needs to figure out how they're going to pay for this down the road. So anyone who's doing cloud IDEs, that's basically to summarize it really quickly.

Any cloud IDE, stack puts, code sandbox, you want to come on the podcast and talk about your business, I'm happy to have you. That's an open shout out. Cool. So I just wanted to wind down the conversation, but I just wanted to find out, you had mentioned in passing that cloud sync will be a future feature. What else is coming down the roadmap for Warp?

Zach: Yeah. So the things that users are requesting most are cross platform support, so a Linux build, a Windows build. We would also like to do a web build of Warp, I think there's interesting use cases there around using Warp to connect to a remote machine or using Warp for collaboration. So cross platform is a thing that we will do, it will take us some time. I don't have a time estimate.

We will also eventually build real time collaboration into the terminal, so that's like, "Hey, I'm using Warp and I want to have someone look at what I'm doing because I'm SSH-ing some machine and I'm trying to understand the logs and I want someone else there." So the ability to really seamlessly share terminal sessions is something that is coming down the pipe, but not imminent. Then trying to get these initial cloud team features is important, that's coming.

Then I guess the final thing would be we really want to make Warp into not just a product, but more of a platform where there is extension points that people can build things in. So some examples would be adding completions for your own internal tools, or adding richer renderings within our blocks. There's a lot of ideas we have around how the developers could extend Warp and code, and have their own code make the terminal a more powerful platform.

Brian: Cool. Yeah, looking forward to checking that out. We're actually working on a CLI tool for Open Sauce tool as well, so yeah, would definitely love to be able to hook into other extensions and present data in a way that's useful for our users. So yeah, we'll definitely be paying attention and continue to be a happy Warp user. But with that, I want to actually transition us to picks, these are JAM picks, anything that you're jamming on.

Could be music, food, technology related, nothing is off the table. If you don't mind, I will go first and share my pick, which is Wisecut. Wisecut is actually a platform that I only discovered in the last couple weeks. I create a lot of content. Our marketing strategy, if anyone wants the inside baseball on how we're basically customer acquisition and stuff like that for Open Sauce.

We started a YouTube series called The Secret Sauce, and it's like a podcast with video on YouTube and we just have conversations with folks who potentially would be a customer or potentially would be a user of Open Sauce to hear their story and find out where their wins were. We take those and we've been slicing them into clips for TikTok and Instagram and YouTube Shorts. Wisecut actually has a feature that does it automagically through machine learning, so rather than take the clip and then try to slice it to follow me around if I happen to move too much, it actually knows who's talking and will follow that person around and make a clip.

So if you ever use a tool like Descript where you can see the words, you could also edit based on words so finding clips inside of an hour long podcast has never been easier. It's turned around our workflow where I probably should do more stuff than just TikTok as a founder, so now I can do less editing and more just getting it done and moving on.

Zach: That's super cool. Is it using Open AI or some public API? Do you know how it does the ML?

Brian: That's a good question. I did actually have a conversation with the founder yesterday for the first time. I didn't go into details because their CTO wasn't on the call, and the CTO is their brother and they had built everything, so I don't have that answer. But if you're interested in trying out Wisecut, it's probably in their documentation or something somewhere. But yeah, it's using some sort of video model to find audio. It's tracking audio to know who's speaking, but then it can also see who's mouth is moving. It's pretty clever. It's exactly what I needed at the right time.

Zach: That's very, very cool. So my pick will be Loom, are you familiar with Loom?

Brian: Yeah, yeah. I've used a lot of Loom. I had a paid account at GitHub, and then now I don't have a paid account. I've already hit my 25 Loom videos per month or whatever it is. Well, I don't want to snipe your pick, but yeah, we use it for doing quick design walkthroughs or engineering demos.

Zach: Yeah. So for Loom, in case folks don't know, it let's you do a screen recording and record yourself talking over it, and then gives you a permalink to it. The use case, I guess there's a couple use cases for Loom lately that I've thought have been really cool.

Typically now when an engineer on our team sends a pull request that has a user facing change, they will do a Loom showing off how a feature works. Which, if you're me, I don't review every PR at all, but I'll sometimes go in to see the demos and the progress and what the PRs, so that's an awesome use case.

Then the other really cool use case that we've had lately is, we do recruiting, we're hiring, specifically we're hiring a product designer and I decided to try putting a Loom of me demoing Warp in our outreach email, and actually we've gotten positive feedback from design candidates. They're like, "This is awesome, it's so cool to see the founder of a company explain the product as part of the outreach."So that's my Loom shoutout. Also a close friend of mine runs the engineering team of Loom.

Brian: Nice. Excellent. I don't know how long it's been around, but definitely during the pandemic when everyone was remote, Loom became very useful to be able to do those demos. It's like you don't really need to do another Zoom call when someone could just give a video and then we comment directly inline, inside the URL. I tried pushing for having a Loom integration at GitHub, inside the PR, or some sort of extension. But conversations went stale.

Zach: I think that's a good idea. Literally, we use it for that.

Brian: Oh yeah, very popular. I don't know any engineers that... Well, I have a very small cohort of engineers I talk to, but yeah, it's pretty common to have it. Also at Open Sauce as well, trying to convey your point or a quick demo of the bug you found, Loom has been a really easy lift to do that.

Zach: Like bug reports come in through Loom? That's really interesting.

Brian: Yeah, because trying to reproduce it through just text, sometimes a lot of stuff can get lost in translation, especially if you're working with folks international. If you don't overlap in time zone, yeah, Loom is a quick way to get to the point and then move on.

Zach: Got it. Cool.

Brian: Cool. Well, appreciate the time, Zach, and chatting through Warp, Excel.

Zach: Thank you for having me, Brian. It's been awesome.

Brian: And folks, keep spreading the jam.