The home team talks with Guillermo Rauch, CEO and cofounder of Vercel and cocreator of Next.js, and Sam Lambert, formerly VP of Engineering at Github and now CEO of PlanetScale. They cover how Vercel and PlanetScale are making the web more accessible to developers, the future of web development for professional programmers, and why human laziness is the ultimate security threat.
Vercel is a developer-first, frontend-focused platform. Together with Google and Meta, Vercel built Next.js, an open-source React framework that helps developers build high-performance web experiences with ease.
PlanetScale is a MySQL-compatible serverless database platform that enables infinite SQL horizontal scale.
Tools like Webflow and Squarespace have made web development accessible for casual programmers, but what does this mean for professional developers?
This week’s Lifeboat badge goes to user Michael Thelin for their answer to How can I play a Spotify audio track with Python?.
Find Guillermo on LinkedIn here.
Find Sam on LinkedIn here.
Guillermo Rauch My take is that as the primitives of the cloud have become more solidified, so the way that I think of it is as layer one and layer two cloud, we had this initial wave of, "Let's create the fundamental primitives to run software all over the world." And that's where we saw the creation of EC2, the creation of S3. Like all these primitives that are almost like fundamental building blocks. They're the neutrons and protons of the cloud. And then you get to a point where there's just no more fundamental particles to discover. So where is the value in cloud? Well, it's in bridging the gap of accessibility. So what's happening is that we're building these layer two clouds that are saying, "Hey, the presentation to you is not a proton. It is a molecule. It's a pre-established artifact that you can plug and play and you can build on top of." So that's what we're seeing with the creation of the React component which allows you to assimilate primitives into reusable bits for the front end UI. We're seeing this with functions where instead of dealing with the VM or the computer, we're dealing with a unit that is also highly reusable of computation that it can run all over the world with Serverless Functions or Edge Functions in Vercel. So I think we're abstracting out in really thoughtful ways. We're making things a lot more reusable. And to your point, I think what's going to happen is that we're lowering the barrier to entry without sacrificing that underlying super powerful and super stable infrastructure.
[intro music plays]
Ben Popper Make is a powerful no-code platform that lets you visually design, build, and automate workflows. Speed up your development time, debug in minutes instead of hours, make abstracts the problem so you can focus on the solution, regardless of language. Sign up for free at Make.com.
Matt Kiernander Hello, everyone. Welcome to the Stack Overflow Podcast. We have some very interesting guests today. I'm Matt. I'm one of the Tech Evangelists here at Stack Overflow, and I have my co-host here, Ceora. Ceora, do you want to introduce yourself?
Ceora Ford I'm Ceora Ford. I'm a Developer Advocate at ApolloGraphQL, and I'm also super excited about our guests today. I'll let you both go ahead and introduce yourselves as well.
GR I'm Guillermo Rauch. I'm the CEO and Co-founder of Vercel and Co-creator of Next.js and really happy to be here.
Sam Lambert My name is Sam Lambert. I am the CEO of PlanetScale.
MK Before we started you had some incredible conversation going, and I would love to kind of backtrack and pick up because you were talking about the relationship between PlanetScale and Vercel, how you synergize together, and make the web a little bit more of an accessible, easier place for web developers.
GR Yeah, Vercel started out with a very strong focus on the front end developer experience. So we built out Next.js, a framework that builds atop React, makes it really accessible to build high-performance experiences on the web. But we kind of made not just Next.js, but Vercel, a platform that was pretty much stateless. It focused a lot on delivering your websites and applications with the absolute best performance. And we plugged in and we left it open to the ecosystem to sort of bring in your data, bring in your data from anywhere. You can actually bring in your data from Apollo. You can bring in your data from Shopify to build a storefront. But we're always missing that component for, how do we bring a full stack developer experience that is unmatched and is super seamless like everything that we try to do at Vercel? And that's where PlanetScale came in, and I'm going to let Sam speak more about it.
SL Yeah, so PlanetScale has interesting roots in the sense that our core technology started at YouTube and it was the database backend for all of YouTube, pairing them up to multiple billions of users. But really we present ourselves very, very differently. And we present ourselves in the world that Guillermo is talking about. And actually I remember meeting Guillermo years ago when I was at GitHub and talking to him about what he believes the future of the internet is. And I felt incredibly inspired by this future that gives companies insane leverage above infrastructure and the ability to build highly scalable and performant applications incredibly simply. And I thought this is the world that we as a company at PlanetScale need to represent ourselves in, because it is definitely where the future is. And the front end community, I think, has been spoiled with tools like Vercel in the sense that they get this incredible, like batteries included, right? That you take the framework that is the obvious framework for building web applications, and it fits into its deployment environment and to the platform it's deployed against and builds a seamless experience. And we take inspiration from this world to build PlanetScale, and so our big challenge has always been taking something already massively scalable and bringing it down to the point where individual teams, small teams, can manage and deploy it. And in fact there's a shared customer, there's many shared Vercel and PlanetScale customers, many, actually probably in the thousands now. But there's one that's a top 3000 website and they have a tiny team, like less than 10 people running a top 3000 website across our two platforms. And that to me is massive. That's not even achievable 10 years ago. And I think this future is only going to get more optimistic and brighter as these companies start to scale and grow. And now with this combined stack, you can easily support millions of users without any operational burden inside your company.
GR I remember that customer really well because they had a situation one day where they had a tremendous traffic spike. And one of the key takeaways for them was, "Oh my God, Vercel is so awesome. It allowed me to cache this story at the edge. It took in all our traffic, we didn't have to worry about anything." However, the trend that we've been seeing in the industry, especially in the front end development space, is that folks want to do more and more dynamic stuff. So sometimes you can cache, sometimes you can't. And what they were starting to find more of a bottleneck in was a database. So they kept asking us, "Hey Vercel, can you build a database that gives me all the same properties of infinite scale, great developer experience?" Because we're stuck in this world of like, "Okay, I have Vercel for the front end and I have this big public cloud database provider where DX is sort of an afterthought as a key component of my backend story. And what I was really impressed with is how easily they switched to the serverless data solution that PlanetScale provided. And basically that brought the stability back to the force. Now they have that great DX, and great scale, and great UX, consequently all across the board. So we're very happy to integrate deeply with PlanetScale and platforms that complete the story for enabling teams to be full stack.
SL Yeah, that was a great migration. Actually, I remember we'd already kind of sold them the solution and they were incrementally moving over. I think they were 1% migrated over to us and then Amazon had another outage and they were like, "Screw it. We're just going to move the database completely to PlanetScale.” And they came back up online, and that was while we were in beta as well, which made me quite nervous at the beginning because it's like, the database is in beta. They shifted this really large website over and it came back online and I caught up with the guy over there and the other week I said, "Hey, how's things?" He said, "I just haven't thought about databases as being a problem ever since we moved." The other thing they get is when they do a preview on Vercel, they get their branch of their database as well on PlanetScale. So they get this fully isolated stack as their development environment because the platforms are so in sync. And it's very cool, I just love it. I love to see tools integrating so well that are very good at what they do and can still be strong together. And I think this is actually a major threat to the clouds. The fat companies that can build the absolute best in class service tailored to their audiences, that then can work together is really problematic, because we're breaking out of the walled garden. And these clouds benefited from the leverage they had of someone having an Amazon account, they can use the additional services that Amazon provides. But now the war is kind of getting very desperate for them. They're fighting many battles on many fronts against fantastic product companies that deeply specialize in what they're doing, and us all working together makes a formidable opponent I think for these cloud providers.
CF One thing I've been thinking a lot about as a developer advocate, I do a lot of developer educational content, and my whole philosophy has always been that I want to make whatever I'm teaching or talking about as easy to understand for anybody. And as I build sample apps or whatever for demos, for talks, I'm kind of carrying that philosophy over to the technologies that I'm using and that I'm promoting as well. And the one thing I really love about both PlanetScale and Vercel, and Next.js is that, I feel like this has become my new standard for a good developer product, is something that could be used by beginners, people who are just starting out their first projects, their first solo projects, whatever the case may be, but also can be used by teams who are building projects or products that do complex things. And it seems like that's something that we have here with both PlanetScale and Vercel. So I'm interested in hearing what was the process like for both of you to get to this point where you made the developer experience so smooth that you can have this wide range in customers and customer personas using your product?
GR I can speak to that because you hit a point that is very dear to my heart. When I started this company I was obsessed with the idea of, it has to be really good in the first five seconds that you've tried the technology. But I can't sell you an elution, because that same thing, that great experience that you had in those five seconds, it also has to scale to day 1000, when you've beaten the technology, you've migrated, integrated, incrementally added more, one page to one billion pages, and that took a lot of work behind the scenes that has gone into the platform. Sometimes it comes in the form of introducing subtle constraints or guiding the developer. The thing that has been instrumental for us is that Next.js, which we happen to have a design hand on, helps with that process of guiding toward that scale, while still being super easy to use and super pleasurable within those five minutes, five seconds that you've tried the technology. And I think what Sam was touching on that I've always found fascinating is that it's the same for Vitess, because if you take the underlying engine, MySQL, and you try to do what YouTube did, which is serve billions of people all over the world, you can't just do that. The engine is good, but it's not up to that kind of task. So you have to do that same work that we did for the front end and for the edge network, but you have to do it for the database and you can have the cake and eat it too, it just takes a lot of thinking and a lot of work.
SL I think I completely agree. And I think it's also about really not accepting transferring much pain over to your users. Something that has been a very historic precedent for now with databases, is they're really hard to build well, and conventional wisdom says don't really use brand new shiny databases because they're generally unproven and come with a bunch of problems. And it takes decades to bake a good database, like MySQL's at 25 years now-ish. It takes a long time to mature. And that being said, you want the DX and all the great feature sets of the modern stack and modern databases. And I think most of the robust, scalable, trusted databases kind of have the approach of, "Well, we've solved a hard problem for you so we'll leave the rest of the work to you. You can have some of that pain. You should feel grateful, we've done loads for you. I mean, have fun." We just don't feel that, right? We think of the most unreasonable developer as the core audience. Like, young developers that are coming into this industry and they think to themselves, "Why can't it be this way? Why can't I just have this? Why can't I have that?" Like super unreasonable, not trying to reason with trade-offs. Just like, "Why?" Like my two year old does now, it's just endless why's.
GR Yeah, I have a really great example of that by the way, Sam, with Serverless, which is one of the key components or key principles behind Vercel, is that it just scales. You know, you get more traffic, we run more of your front end rendering logic all over the world. And what we're noticing before PlanetScale broke into the scene was that folks would go to traditional databases as exactly what Sam said. It was like, they're super robust. They are extensively tested, they're durable. They don't have any data loss, they don't have any consistency gaps. But then they would try to scale them in terms of, for example the number of connections. Because now with this technology it's running at the edge, you could be connected to your database from all over the world, for example. And the database would defer that pain to the user. They would be like, "Okay, set up some gateway in front of your database to take in more connections because that's not our problem." And then it would show up with, "Migrations, no the database doesn't solve that. That's also your problem. Write some scripts or figure it out." And then you would see that really what I think the industry has been looking for is not a database, it's more of a data platform. It's a comprehensive solution that takes into consideration the workflow and the actual bits of the infrastructure that is answering a query. And that's exactly what we saw with front end. It's not just the infrastructure, it's as you mentioned Ceora, like the workflow of pushing to get and spinning up a preview such that I can iterate and collaborate with the platform. It's not just about, "Oh, I was able to host an app." And I think what's really awesome and this is the opportunity for companies like ours is, just continue to take on more and more of that pain that traditionally has just been handed off to the developer.
MK So I'm fairly new to the industry. I've only been a software developer in front end specifically for the last three or four years. One of the first things that I noticed when I joined was I was completely overwhelmed by how much tooling and how much stuff you had to know. I feel like there's a weird dichotomy where the web is more accessible for people now who want to get into casual development with things like Webflow and Squarespace and everything else. But for those who are wanting to become professional web developers, there's so much stuff that you need to know. So I'm really curious around your thoughts on the future of web development for professionals. Where do you think that that's going to head? Do you think tooling is going to get more focused on modularity and being able to slice things out and add things as you want? Or do you think there are going to be more established stacks like Vercel and PlanetScale and more integrations that are going to make our lives easier as opposed to more complex?
GR My take is that as the primitives of the cloud have become more solidified, so the way that I think of it is as layer one and layer two cloud. We had this initial wave of, "Let's create the fundamental primitives to run software all over the world." And that's where we saw the creation of EC2, the creation of S3, like all these primitives that are almost like fundamental building blocks. They're the neutrons and protons of the cloud. And then you get to a point where there's just no more fundamental particles to discover. So where is the value in cloud? Well, it's in bridging the gap of accessibility. So what's happening is that we're building these layer two clouds that are saying, "Hey, the presentation to you is not a proton, it is a molecule. It's a pre-established artifact that you can plug and play and you can build on top of." So that's what we're seeing with the creation of the React component which allows you to assimilate primitives into reusable bits for the front end UI. We're seeing this with functions where instead of dealing with the VM or the computer, we're dealing with a unit that is also highly reusable of computation that it can run all over the world with Serverless Functions or Edge Functions in Vercel. So I think we're abstracting out in really thoughtful ways, we're making things a lot more reusable. And to your point, I think what's going to happen is that we're lowering the barrier to entry without sacrificing that underlying super powerful and super stable infrastructure. A customer of mine the other day sent me this message, he was really happy saying they've been around for many, many years. And I remember things like Heroku (7:55), that in his mind offered DX, but not the scale. And then he felt like he had to opt-out and go back to that layer one in order to scale. And he told me with Vercel, I found the DX and I found the scale. And it's not because Vercel has the most brilliant people in the world, or like we talked to God and they gave us a recipe. It was more that we were able to piggyback on this layer one of fundamental particles and fundamental primitives to now build really robust software on top. So I'm really optimistic about this idea of you're just learning front end, but it's getting really, really easy, and it's getting also really scalable at the same time. So, definitely the best time in my opinion to get into programming that there's ever been.
SL And it's an evolution, it's where tech's been going. It's normal now for people to not understand how data centers work and how to rack and stack servers because the cloud has taken that away. They've gone incrementally further. They haven't gone the full way. There's a lot left like Guillermo says in terms of tailoring it, much like building this additional layer on top, and we have to get to that point. And I think it's really a moment in time, we've gotten to the point where you can gain incredible leverage and truthfully, what's infrastructure for if it isn't for leverage? And you can gain outsized leverage by being very selective and choosing tools that give you an opinionated experience. The more open-ended it all is, the more complicated, the more it can go wrong and the more you have to learn and reason about and understand. It's a problem when you see companies, or frameworks, or whatever, trying to do everything rather than take an opinion and guide you to build against that opinion. And when you have people do that, and you have platforms that make that super easy, you do gain a ton of leverage. Being the everything to everybody doesn't do that. It makes things much more complicated and much more difficult. iPhone is a great example, right? Android was very open to begin, very open. Any device, any design for your application, however you want it. And then you look at their ecosystem now and it's immensely fractured. I can't remember the numbers, it's really worth looking up though, the length of time old Android versions have been in the world is ridiculous. So it creates second order problems like security issues and all of these things. But the oldest versions of iOS out there on iPhones is much, much younger than the versions of Android. They keep people up to date. And in the early days of using the iPhone, they heavily influenced how applications should look. And you give someone an iOS app and they can pretty much navigate it. They all kind of feel the same, you expect the same from the applications because Apple wants to deliver a consistent, but more narrowed down kind of experience that gets people doing what they need to do. It gets the job to be done, done for the device and the usage of the device. But it takes having an opinion and you have to be solid and be brave and stick to that opinion and cast away a lot of things, which doesn't mean it's for everybody and there's a whole bunch of people that say, "Oh, you have to understand the abstractions and every layer underneath." And I think they almost smirk and think it's like an inferior type of engineering to stay way up the stack and use these highly tailored, high leverage tools. I think that's a ridiculous view. I think they're wasting their time on most of the things they spend doing. And I think this new generation building against platforms like ours are going to get a lot more done.
CF First, I want to say that the opinionated opinion about building opinionated tools, I think is really valuable. Before I became a developer, I used to do digital marketing and I was a freelance digital marketer. And one of the biggest issues I had was I would come to these people who had small businesses and I would say, "Okay, who's your target audience?" And they would say, "Everybody." And that's like the worst answer you could give because it's so hard to market something to everybody. You've got to choose who your target audience is. So, one question I want to ask which I think kind of ties into that is, both of you are leading startups. And one thing I noticed that can be a struggle for a lot of startups is getting themselves from the point where individual developers love and enjoy the tool, and getting to a point where now enterprise companies are enjoying your tool and using it to build things that generate income, generate lots of money sometimes too. So what was that like for you both? How did you get to that point?
GR For me, it was an interesting journey because the world had been presented to me by many experts as there's a fundamental tradeoff here. Kind of like DX versus UX, a bad false dichotomy. There's a fundamental tradeoff here. If you're going to do great by developers, that's taking away resources that you're not going to do great for enterprises. And then when I actually started talking to enterprise companies, I realized that the underpinnings of what makes a great enterprise offering are things that developers highly appreciate. For example, the ability to scale, have great performance, have isolation, and have security, are the things that developers always consider as a top priority. Especially now as things are becoming more transparent, you hear every day about the NPM security breach of the day and things like this, and this is impacting the way that front end developers think about the cloud, and front end developers think about building scalable software solutions. They don't want to be known for having chosen the solution that was a toy and didn't scale when they took it to work. Or to be in conflict with the software making decisions that are made by CTOs or CIOs or VPs of engineering. So, I think the world is evolving very rapidly. And I think one of the key aspects of this has been, engineers are now equipped to make buying decisions that are high leverage. The output of their code is directly tied into the operational costs because the world is moving towards consumption-based pricing. So engineers are now deciding, "Okay, I take this solution because it's going to cost this much, or I'm going to spend this much time optimizing so that it takes away from this. Or I'm going to take a shortcut here. I'm going to get this product to market faster by taking advantage of this serverless solution over here." So I think the developer as the new CIO that is making a lot of these decisions has been a reality that, to me, I thought it was going to be way further ahead. But it's very, very, very real now. The ability to adopt these technologies in smaller chunks in incremental ways has been a very successful strategy for us. We always tell folks that Next.js allows you to modernize your software one page at a time. I always also talk about the idea of like, you can create an entire new front end experience on top of existing data and existing backends and existing modernization strategies through microservices or GraphQL. So we fit in really nicely in that incremental path, and that's also resonated a lot. But at the end of the day, I think folks tend to still underestimate how much of a great enterprise offering is made up by very strong fundamentals. You want to trust the technology, you want to trust that it scales. You want to trust its security. And that's what we've been spending a lot of time on.
SL Absolutely. I think the convergence of what developers spend their time doing in enterprises and what they do in startups is coming, because startups are now disrupting large enterprises at an ever increasing rate because of the speed they can move, the agility. Some of it's management and culture, which enterprises have got a lot of work to do to get right to still be able to compete there with startups. However, when it comes to the tech tools, if you've got a tiny 10-15 person team running laps around you and you still think using Oracle Server is going to give you any competitive advantage, I have bad news for you. At the 10 year horizon you have some trouble on your hands. And with the rate startups are being created, the things that were traditionally advantages for enterprises, like having big infrastructure teams and the ability to rack our own servers, and custom this and whatever, it's actually not an advantage anymore. Because we've brought that point of view of usability so far forward that companies are realizing it. You know, in the last year, we've done briefings with some of the biggest banks in the world. And their problems sound awfully similar to startups, which is, "We just need to get things delivered quickly, well, best practices, the long-term maintenance of these things, it has to be secure, and like Guillermo said, it has to be trusted." We have those things, those become table stakes. And even doing that is easier thanks to other startups. I couldn't believe how quickly we got SOC 2 compliance by using tools that are just out there now to do this. All of that rate is increasing and it means getting in and selling to enterprises is getting easier and easier. And this hiring market is so competitive. Them hiring operators to manage databases or manage servers out at the edge or build their own PoPs or do this stuff, utter waste of time. Sign the contract, buy a tool, get it over with.
GR You mention the edge, and this is something that I always find myself talking about with larger enterprises. To compete with a modern platform, a modern offering like ours, you have to start thinking around not just maintaining one region. You have to maintain a global footprint because we're in the business of accelerating the end user experience. We're not just making it easy and enjoyable for developers. We care deeply about the end result, the resulting product and experience that is being given to the users of the web. And the best way that we found to do this is to lean heavily on edge computing and putting your application right next to where the prospective customer is, especially for e-commerce. So that means that now we have to worry about, "Okay, to do my own Vercel, I think about 20 plus core regions have to be maintained, failed over, scaled, secured." And then you start realizing, "Well, by offloading this I'm actually becoming more secure and more stable than if I try to do it myself."
CF I like both of your answers a lot, because I think at the core of it, it comes down to the fact that if you get the developer experience down right, everything else will fall in place eventually. Which I think a lot of people forget. I think sometimes as developers, I think you mentioned this earlier, Sam, sometimes we want to do the thing that's the most advanced and takes a lot of thought, is the most complicated. But at the end of the day, it really comes down to, can people use this easily? Can they have a good time using this? Is there going to be any friction? If you answer yes to the friction part, you can bet that you won't get a lot of people who are going to be happy to use your products.
SL A hundred percent. Friction is bad for security. Humans are very lazy. We often do not do the right thing when we're supposed to, in the physical world, in the world of software. If it's any number of additional steps to get something done that makes you more secure or more robust, if it's a pain and you have OKRs or whatever ruling you to get this done, you likely won't do it. Right? I'm sure Guillermo has the same challenge.
GR It reminds me of passwords that are really complicated, and people follow all the 20 restrictions, but then they write it down on a post-it note and put it on their desk. If you add friction, that's a really underestimated point, Sam. Like folks will just find the ways around it and then you're in square one. So I think frictionless, this is a very underrated point, the frictionless solution, the simpler solution, tends to be the more secure solution. And this is what the opportunity for startups is.
SL And giving that to domain experts. We're the experts in databases, Vercel, the experts of building incredible scalable apps at the edge. Let us handle these things. Do you expect your security team to continue to learn everything about the incredibly vast surface area that companies have now? I just don't buy it as being more secure to have all this stuff in house because it just becomes so difficult to manage. I remember this conversation when I was at GitHub, the Git team was in the infrastructure org which I ran. And I remember there was a Git vulnerability that was quite nasty, and vulnerabilities happen in open source, it's completely normal. And we'd just detected it and patched it on GitHub before it'd actually been disclosed to everyone else. I remember talking to a large enterprise, they were like, "Well, we don't feel so safe putting our code on GitHub." And I asked what version of Git they run internally and it was the old vulnerable version. I was like, "Well, with our security team and the Git team on staff here at GitHub, we had that patched before it was ever a problem.” And that won the sale. And I think it's reminding ourselves that, it's a lot to trust, but when you're trusting the experts who have this oversight view of the world, like we find problems with people's databases before they do often, because we're running tens of thousands of them on behalf of customers. And I think that's the big journey and emotional journey that a lot of companies still need to go through to give up that trust and realize that they're not in a better world by doing it all for themselves. They're just hurting themselves in the long run.
CF Oh, yeah, absolutely. It makes me think of how, this is semi-related, but sometimes I know I have the tendency to think, "I can do this myself. I can paint these walls myself." But it's so much better to get someone who does house painting for a living to do it then for me to spend all day.
GR I think we've all been there. It's a great example.
CF Yeah, exactly. So it's the same with software.
SL It's really hard to teach people to value their time, or just the value of additional time. Even if you know the store down the road, or like two miles away, is a little bit cheaper for the item that's right in front of you on the shelf, it will never be cheaper to go travel to that store and actually get that item. The cost of your time and enjoying your weekend is way better. You're not getting time back so let someone paint your house and it's the same with innovation, right? Like people talk about innovation points, there's very few innovation points that you have to spend. And you need to get as many of those innovation points being spent in differentiating things for your product, because your customers don't give a damn what database you're using. They just don't care. So choose the one that takes the least innovation points away from you so that you can do the things your users actually care about. And that's how you can win as a business. And I think tech's evolved. When I was in tech in the early days when I was an engineer, it used to be all about building stuff yourself, what crazy backend stack thing you invented for yourself that you can brag about on Hacker News. It's just not cool to do that anymore. The thing I like now is people on Twitter are sharing growth metrics from their businesses and stuff that really actually matters. It's way cooler now to just get a really good scalable stack, move on, do cool differentiated stuff, rather than just mess around reinventing the wheel.
GR Something that has helped me a lot in my career is that I always try to go and reverse engineer from the product experience. Like, show me a fast website, show me a cool experience, show me a new way of rendering 3D or shopping, and then let's talk about how it's built. And this is why I continue to insist that I think starting with the front end developer is the most strategic place for any company. Because those are the folks that are directly in touch with the customer experience. And as Sam said, no one will know how your database works, what its name is. They'll know whether your site is fast, whether it doesn't break down during Black Friday, or whether it's evolving quickly. Like nowadays I feel like I'm always in a constant, real time, product building conversation with the customer where they tweet or they email, and their expectation is that you're going to get their stuff fixed and addressed pretty much in real time. I think that's ultimately where we're headed. Like, you messaged me, "Hey, I would like this to do this or that, or I don't like this, or this is not good," and I'm basically modifying it as we speak. That's the rate of change that the world is setting itself up for.
MK That's one of the things that I've definitely noticed doing my normal 9-5 job as a software engineer and having to deal with legacy code and bugs and problems. If I have a side project, the last thing I want to do is spend my weekends and evenings debugging some very purpose-built piece of technology that integrates that doesn't make my life easier. When you have to become your own product manager, you just want to pick tools that are going to work, you can rely on, they can get the job done, and you can get as frictionless experience as possible, because your time outside of work is super valuable. I really wish that methodology of thinking was transferred to enterprise as well because at the end of the day we're there to build things to make people happy. We're output driven, as opposed to spending all of our time configuring and doing all sorts of bits and bobs just to try and get the thing working in the first place.
CF Yeah. I think this is an exciting time to be a developer too, because we have a lot of tools that make all of that easier. So I'm excited to see where products like PlanetScale and Vercel take us in the future.
[music plays]
MK And with that, that is a wrap on the Vercel and PlanetScale podcast. Thank you so much for tuning in. The lifeboat that we're going to give away today is, "How can I play a Spotify audio track with Python?" Interesting topic. It was done by Michael Thelin, with 4.5 thousand points on Stack Overflow, so thank you so much for that one. That has been me, Matt Kiernander, the Tech Evangelist here at Stack Overflow. You can find me on Twitter @MattKander. And Ceora, would you like to do yours?
CF Sure, yes. I've been Ceora Ford. Like I mentioned earlier, I'm a Developer Advocate at ApolloGraphQL. You can find me on Twitter, my username there is @Ceeoreo_. Spend a lot of time there so check me out there. And I'll pass it off to you, Sam.
SL Sam Lambert. You can find me on Twitter @ISamLambert, and most importantly PlanetScale.com. Everything you need in a database.
GR I'm Guillermo Rauch, and you can find me on Twitter @RauchG. And feel free to DM me what your favorite part of this podcast was. Thank you.
[outro music plays]