This week with chat with Matt Biilmann, CEO of Netlify, who has been building developer tools, content management systems, and web infrastructure for more than 30 years and is recognized for coining the term “Jamstack.” He opens up about what, in his opinion, makes a great API.
Pattern matching in Python 3 - a nice new feature, a gift to Stack Overflow point seekers, or a big pain in the neck?
Curious about the Jamstack? You can find lots of great information on how it works and who works with it here.
Want to follow Matt? He's on Twitter here.
Our lifeboat badge winner for this episode is Jim Mischel, who explained how to: Find the first character in a string that is a letter.
Matthias Biilmann The more we make these tools, really approachable and delightful for developers, the more delightful experiences those developers will go and build out in the world. Right? And I also really agree there that that's what makes API's great, right? When developers can get creative with them and build really cool stuff.
[INTRO MUSIC]
Ben Popper Are you ready to start writing your tech story? join an Ironhack boot camp and learn the skills you need to pursue a meaningful career in tech. Visit ironhack.com/write-your-story to find out more. Let's write your story.
BP Hello, everyone! Welcome to the Stack Overflow Podcast. Good evening, I should say.
Sara Chipps Good evening!
BP See, Sara, we changed it up.
SC So nice! If it's not evening where you are, you can't listen.
Paul Ford We have never recorded in the evening before, it feels very casual. It's like we're gonna just relax listen to some good conversation.
BP Yeah, I'm having a beverage. Paul has a five o'clock shadow.
PF You, kwe got to bring the energy level up, we can't just we're not here to lounge around and talk about programming. It's always morning.
BP There was some strong energy this morning. The link that hit me when I first signed on 'Stack Overflow users rejoice is pattern ching is added to Python 3.1'.
SC There's a lot jokes to be made here.
BP It's critical. It's critical. You know, I don't I don't like this disparagement of pattern ching, or the Python pet process. I personally really liked it. There's pattern ching in Python 3.1. And I challenge anyone. This is just snippy-ness about a lovely process--they gave us the software said 'Sara, they're like, Hey, you like to destructure tree based data structures, don't you?' And I'm like, 'Yeah, I do.' And Sara, what about you?
SC Yeah, I would say, sure thing? I think? Yes.
PF No, I mean, yeah, look at you know, you got you're gonna walk a tree and deal with all sorts of chaotic data have these people never seen a document in their life like a like a badly structured messy tree. And then you gotta walk that tree and then and then output things they've never done that it's just this is just like some don't say anything bad about Python data is destructuring out there. Just don't do it. Just unless you unless you've ever dealt with like 14 mg's of XML expanded in memory, that you have to walk through and transform into it another tree. Unless you've done that I don't want to hear a damn word.
SC I've definitely done that. But I don't, I haven't done so much Python. So I welcome I welcome the world of Python making it easier.
PF It's a good language.
SC There's a lot of jokes to be made about patter ching existing in this world of software since the beginning.
BP It's a lot of low hanging fruit, go out and get those reputation points on Stack Overflow, unless we mark it as duplicate, in which case, sorry, you're out of luck.
PF It's just a little bit of everything. That's sometimes it's just mostly what you need. It's like I need to do my data science. Oh, good. I need to scrape the web. Hey, I got you. Right. Like it is, I can't run natively inside of web browser will give a time with webassembly. And we'll see what happens. And and it you know, people are all Hell no, they defend JavaScript. And there is no JavaScript anymore. Okay, I want to argue about that, too.
SC Who's, who's attacking JavaScript?!
PF JavaScript attacks itself.
SC Who doesn't do JavaScript?
PF First of all, there is no JavaScript, I would like to throw that out. There's no JavaScript JavaScript is now a virtual machine. If you sit down and say, I'm going to write some naked bear JavaScript, just like live the JavaScript way, we're going to get a book or the rhino on it, and I'm gonna go straight to the syntax. No one knows what that is. You need TypeScript--
SC I do.
PF Oh, really?
SC Yeah. Well, no, I mean, I didn't mean to interrupt you. I'm just again, aging ourselves. But I think this is a great, I think this is a great segue because the last time I did this, I was able to deploy my website WAC retiring. It's my dad's retirement content countdown website probably broken because it's like, he's now well supposedly retired, unfortunately, pandemic, but I was able to deploy it in like 10 seconds with Netlify with my vanilla JavaScript.
PF Wait, wait, who's here? Who's here? [Sara laughs]
BP Hey, we have a guest!
MB Hey everybody, happy to be here.
SC Great to have you!
BP Yes. We have a guest today related to Netlify. , would you like to introduce yourself?
MB I'm Matt Biilmann, I'm the CEO and co-founder of Netlify.
SC So great, well, thank you and thank you for the my father's retirement website, which I'm sure was the use case you were thinking of.
MB I hope he didn't retire because of the website.
PF This is a product that has taken my the agency that I co-founded by storm like I get those emails which are just like you're using more Netlify minutes and hundreds and hundreds of minutes as we--and I mean, Sara, you've used this thing, I've used this thing, this will sound nerdy but it's like it changes the way you think about deploys t, tell someone who is jam stack curious cuz that's still a lot of the world, you know, they've got they can use GitHub, they've built a couple WordPress sites, they, you know, have integrated with a couple API's in their life they know some JavaScript and get them up to speed on Netlify. What does it do?
MB Yeah, I mean, first of all, netlify tries to just reduce all the friction that you get from writing code, to actually getting getting it on a URL when you're a developer. And we could do that by being very open about what kind of JavaScript you use, as you said, like, there's all kinds of ways of writing for the web. Today, there's so many different frameworks and dialect, we typically always have some build tools involved, and so on. Right, so we didn't take an opinion there. But we took a strong opinion around the overall architecture that you should follow, to build for the web, and said, like to build for the modern web and allow us to make your life a lot easier, you should take an approach where you decouple the web presentation layer, from the back end business logic layer, and start treating that back in business logic layer is just a series of API's where some you build yourself, and some other people have built for you like Stripe, or Algolia, Contentful, and so on. And we sort of saw that if people adopt it that way, where you're essentially like building web applications in the same style as mobile applications where the UI is compiled, and then data is pulled in as needed, then we could really build like an end to end lifecycle management platform for that whole web presentation layer that both includes the runtime globally distributed that that that we deployed to and the actual like CI/CD platform that will do the compilation of the UI and gives you nice features, like deploy previews, where every pull request get a URL, and--
PF It's worth emphasizing, we should let me pause you that is magical. If you've never had this experience, you push a branch to GitHub. And then the branch name becomes a preview that only you can see. And it gets compiled. It's all nicely narrated as it happens. And so you're fully done with the staging server at that point, like you're just seeing your thing as it comes to life. And then you do it again and again, just like we all do, until there's a callus builds up when you reload finger. And that I will say is magical. There is just a moment of like, okay, push the code. Oh, I have to deploy it. No, you don't! No, here it is.
SC That's so nice. Yeah, there's no more, no more having to configure your staging environments for 20 people. So that's great.
BP I was gonna say, , did this come out of frustrations that you had working another job or doing web development for this? Like, what was the impetus for the creation of this?
MB Yeah, I mean, it came out of a lot of experience of building for the web and building tools for developers building for the web. So before all of this before even coming to the US, into the bay area, I spent quite a while as CTO for a company in Spain that built websites for small to medium businesses in the European market, and at very large scale. So we would build something like 100 websites a week, it's really about mounting a machine around it, where the the team of like the engineering team and product team and so on that Elliot was building the the different generations of platforms that the designers would use to do the design with, that the clients would use for content management and that power every single website from from brief to production hosting. And then, based on that experience, I started a startup in, in Spain, together with the Spanish founders, where we were sort of saying, okay, we just tried building something like this in house that built cloud hosted multi tenant CMS, where other agencies and other professionals could get some of the same efficiencies when when building for clients. And I came to the Bay Area with it, and I was working with it and, and already had like several iterations of that kind of platform under my belt from Spain. And this product was one of the like, was built as a traditional monolithic web applications, right where, where you really have like, everything is centered around this request response cycle, a request will come in for a URL, and then you will set it to through a load balancer through a set of application servers that talks to a database and fetches data and mixes those templates and builds everything and ships it to the to the end user. Already at the time with web pub, like I was trying to really structurally separate like their templating design programming environment from the content environment and have a pretty clear separation, right? But it was still all one monolithic running system. And I learned about like all the hassles of operating that system. And of developers sort of having to understand the full implications of writing a template that below the hoods triggers a whole bunch of database queries and what that means for performance. And so I learned all about trying to instrument layers and layers of caching, to get performing in trade and striking the balance between either getting shitty performance or getting sort of unexpected cash behaviors where you don't really know why, why a user is seeing something instead of something else. And I also started seeing around that time, sort of three major changes happening in the overall web ecosystem. And the first one was just GitHub emerging, right, where, before GitHub, most front end developers I knew did version control by sending around folders with names like 'Version four, final, final, final, for real this time' [Ben laughs]
SC Yeah!
MB And going back and forth, right. And GitHub was sort of the tipping point that sort of got suddenly front end developers to adopt version control. But not just to keeping track of files also, suddenly, yes, they mean collaborative tooling in the main way of driving workflows. And around the same time as, as GitHub sort of grew up, the browser also started growing up and really started for real going from being more of a document viewer to really becoming more of an operating system talking to all these different API's and services and running JavaScript then today, even WebAssembly, right. And the third thing I saw happening was just in the wake of that, this whole emerging emergence of front end build tools, where on the one hand, you had like the early static site generators, like Jekyll, and so on, but on the other hand, the whole ecosystem around Grunt, and Gulp, and then single page application framework, and transpilers, and compilers, and so on, that suddenly led to like front end developers, potentially working in a very different way, like working in Git, having a build step compiling stuff for this modern browser based operating system. And I started looking sort of at all the projects that that we had built in Spain, from ecommerce sites to like blogs or community sites to all the projects that people were building with my multi tenant cloud hosted CMS against like, ranging from like newspapers, through airports, to ecommerce, and so on. And I could see there wasn't any technical reason that you shouldn't be able to completely dig cobble the web presentation layer of that work in get work with modern front end build tools, deploy that as like a self standing UI, and then talk to different well defined API's for the dynamic pieces. The reason people weren't doing it, though, was that setting up all their sort of workflows and tooling to work and build in that way, just introduced a ton of friction, right? Like now we had to set up a CI/CD platform and a CDN and like an object storage, and you have to figure out how to instrument like atomic deploys, and cache invalidation. And when a data source changed, you had to figure out how to respond to that. And then you had to do the same thing over again, for your staging environment and for your development environment--
PF Help us understand the beginning. So you want to fix this problem, is it you alone in a room with a text editor? Is it a small team? How did you start? How did Netlify get started?
MB So I had WebPub acid acid was called running and had some revenue from WebPub and was and could have grown that business. But that of seeing like this, this monolithic approach is it's just not the future of the web, right? Like, if I build this business, I'm building something that will eventually get outdated. Right. And so it took sort of the decision of saying, like, I have to build something from for, for the architecture I actually believe in. And at that point, yeah, it was just me and a text editor, I sat down, I gave myself first two weeks to sort of come up with like, what's the simplest thing in the direction of this vision that I can build and take to market? So I build a small MVP called BitBalloon where you could simply like that, just aim that like saying, Okay, if it's true that you can like decouple this front end Lee and build it up front, and then put it on a URL? What's the simplest way for people to get it on a URL? And the simplest way I could think of was like, just take your folder with your front end, and then just drag it onto a website. And you're done. Right? Yeah. So Netlify still has that functionality. If you go to netlify.com slash draw, I now get that kind of like, you can just drag a folder right? But that was like the very first MVP I build with BitBalloon of just seeing like, what's the smallest friction to just getting that kind of self standing front end live? So spend a couple of weeks just building that MVP and then a couple of weeks more adding some subscriptions and stuff.
PF And when was this? When was version zero?
MB This was back in 2014.
BP Yeah, folder is good. But what if I just drew the idea on a napkin? [ & Sara laugh]
PF Netlify ml. So folder is version zero. Get us to like, when did you say, alright, this is it. This is what I'm doing for a long time.
MB So it happened pretty fast after that, just from that I started seeing seeing the right kind of energy and the early adopters and then I added like CNI based deploys, and API based deploys and quickly saw that treating it as a programmable layer that you just push that friend into opened up a lot of possibilities, right. And one of them was running a build somewhere in some CI/CD system, and then pushing through the CLR, the API, and instrumenting, in that way, right. And then, at the point where I had that early MVP, we started sort of seeing the right kind of early adopters, getting getting interested and validating the idea and started reaching out and talking to to one of my very best friends back from Denmark, where I'm originally from, Chris, who was my co founder today, and who I've known for more than 25 years, going way back to high school. At the time, he had built his own production company and sold it to a larger full ad service company where he was Chief Digital Officer and and a partner. And was running like more like the digital strategy for the Walmart of Scandinavia and things like that. And I just started talking to him about like, all of the potentials of decoupling this web presentation layer into its own thing, pre compiling it, spreading it on servers all over the world, like the benefits you would get in performance, security, scalability, and conceptual simplicity for the developers working on it in all of that. And then we started just really again, looking at if his agency, for example, if if he wanted to go to his developers and say, 'let's do things this way, let's actually build this way.' What would it take? Right and and at that point, again, it was just a hodgepodge clink level of stitching together CI/CD services--
SC Yeah, I thought it was so much like, for a big company like that, just being able to step in and do some do something like that. That's tough. That's a great place to start. If you want to figure that out.
MB Yeah. And the thing, like if you're an agency, and Paul, you probably know this, if you're an agency, and you just go crazy, and you build something with like seven different cloud platforms and stitch it together and go to a client and say, 'Here you go, good luck maintaining it' right? Like, then you probably get fairly unpopular fairly quickly.
PF Well, they don't love it. They want you to, yes, simpler tools do better. The sad thing is, of course, you could land that and it would be like six months before they figured it out. But in general, you want to you want to give them something simple, which actually goes to a point. And I find this fascinating about these these platforms. When do you think--it's a very loaded question--when will there be a data layer? Like right now, I want to I need to find an API to save data. So cookies, track users do author etc. When is there a roadmap? How do you think about data in relationship to jam stack style?
MB Yeah, yeah. So I would say there's two answers to it. And it depends a bit of the scope of the day, right. Like one thing I generally sort of recommend Siggins is that now we've really gone through this idea of decoupling the web presentation layer, having it it's an in its own pipeline with developers that can work very fast on the actual experience, and then other teams that can build API's. And I think that's actually pretty healthy decoupling, I don't think we should go back and then try to stuff all of the monolithic stuff just into the front end area and end up with like, essentially the same architecture just running inside some blob of React or something. Right. So I think that decoupling is pretty healthy. Then the other part of it is when we start working with architecture, one of the things that's interesting to see is that, like, traditionally, when I was building, web pop, and when I was building websites, before, all of this are web applications, every application, my mental model was that I had like my app server and my database, right, those two components, right? And database was like, singular, right?
SC Yes, yeah, just one.
MB But today, you start having like setups where where your data actually lives in a lot of different places, right? Like, you might, you might say, okay, authentication there. Now, like a lot of different services for handling authentication. There's like AuthZero and Okta, we have an Identity Service at Netlify. There's new options, like the use of basic query coming along, and so on, right? And, and, and it's easy enough to say, Okay, I pick, like, work always. And I set up Single Sign On, and now I have authentication figured out, right? But now we actually added a data store for users, right? That's a special purpose data store it does, you no longer have to think about the schema or anything like that. But nevertheless, you're now storing all your all your users in one database. And then maybe you go in and say my users need to subscribe to stuff and have plans and so on. Well, the logical places probably to to go to Stripe, they have agreed like billing engine with plans and everything. Before stripe, right? Again, you had to architect the right data schema for for billing in your database. And some of us to spend a lot of time like writing down like table diagrams for that kind of thing. Now you just pick Stripe and you say that. I don't have to think about the schema. I also don't have to think about backups, replication, anything like that.
PF No, it's true, I never want to implement commerce ever or come close to it. If I can possibly, it's horrible. Yeah, it's just, you're just you're guaranteed failure anyway. Okay, so yes.
MB But anyway, right now you have an app where you have your users in one API, and you have your, your, all your subscription and plans and so on in another API. And that's totally your data, right? Like, you're just, you just haven't even thought about like a custom database yet, right. And as this whole world of API's evolves, and you get more and more of those services, I think we will start seeing data fragment in that way, right like that a single application will no longer be like your app in your database, it will be your app, and then these different API's that that holds data. And I think we will still, of course, for applications, for most applications, either we'll need to build like a real API with our core business logic, and so on. And there, you will probably still use a traditional database. And we're seeing a whole, like, architectural evolution in how you deploy and maintain those kind of services, right. But there's also a set of apps where you mainly have these ready made API's. And you maybe just need like the glue layer to tie it together. And there I think, we'll start seeing like API, like databases emerge that are simpler than like a full on relational database, maybe, but that are very easy to provision and, and work with directly for the web.
SC Do you mean like a, like a stering, like a hodgepodge of different API's that work together?
MB So I think we'll see a combination of like, things like Superbase and so on, we can just spin up like a database and start talking to it real time from the web with simple authentication. But I think we'll also start seeing things that helps us as developers, glue together these different data sources that we have, like historic cloud that started out by just sitting in front of a Postgres database, and now they're starting to add more connectors, so you can query across from them, I think we'll see more and more of those kind of blue lists to to help. And I think what you'll want as a developer is for, for tools like us to really help you with the orchestration of all of that right, to not have to worry about like, how do I spin up all the rest, right API's instances, get all the right tokens and keys in place? How do we spin up like the deed API's? And how do I query them?
PF I want to derail for a second because I just Googled, actually I didn't Google--I duckduckgo'd, Superbase, and it is the most--
SC It's a Nicki Minaj song.
PF It's not just that, it is the most overloaded term I've ever seen. It was a database on the Almiga. It was it is a it is a database, that sort of Lino and like a new modern database product. It's a compound that has a high affinity for protons. It's a Nicki Minaj song. And it's a one, it's a one part water based acrylic coating. Yeah. So I mean, actually, when you're when you're humming Superbase by Nicki Minaj, as I do almost every morning. I also think about acrylic coatings. And now I'm thinking about dynamic databases. Actually, you know, one thing I really want to ask is your experience, you have quite a bit of API experience as the as the CEO of Netlify, what makes a good API?
SC What a good question.
MB Yeah, that's a really good question. Right, like, now, I think the first thing is the flexibility to build different kinds of experiences on top of it, right? Like, I think that that's one of the things that's really become the power of this API driven landscape, right that when the API get composed at the right level, they can give you sort of ready to take business logic that you can build new experiences on top off right, where where the granularity in the API calls that allow you to, to build the user experience you want to build. And then of course, as a developer, it's important that a good API is easily discoverable, right? Like you have to be able to, to fake out there has to be some principle of how it works. That makes it easy to guess if it's a REST API, it should follow. Like there's so many different conventions for REST API, but it's you follow one of them right, like internally and give you clarity, it should be easy to understand the API just by looking at something like a Web Inspector, right? Like a good API, you can you can look at the calls in the browser, and you can understand what's going on. And you can play around with it with as little tooling as possible. I think, right? Like if you can see your URL and an API and and understand how it works. That feels like then it's easily consumable and easily understandable and doesn't put up a ton of hurdles. Right. Those would be some of my--
PF No and you know, it's fascinating. Listening to you, because I'm in violent agreement with all of them.
SC Violent agreement? I've never heard Paul be in violent agreement with anymore.
BP Paul went on mute, he was shaking the monitor.
PF We're talking about API's, come on, of course. No, you know what's interesting is that I think a lot of times when people talk about API's, like the answer is that you will expect from big orgs are like very scalable, extremely low latency. And the things you just described, which I think are also the most important are good user experience and the ability to compose--
SC For engineers. Yeah, yeah. Yeah. People rarely think about that engineering experience. You know, I mean, like people do, but it's like, bottom of the list.
PF API as a product I feel is like the undiscovered country, in our industry, right? Because it's just people, people feel that they've slapped REST or graph qL, on top of everything, and actually, graph qL is easy to slap on top of things like it's really good at being slapped. [Sara laughs] So maybe that's just the future, but--
SC This is possibly the most violent episode of this podcast there ever has been.
PF Are there any--like I always think of Stripe as being a very large surface well documented that actually has very good semantics, any others that you think of is really good?
MB I think Twilio has a has a strong culture for building good API's. Stripe, for sure is the one we are we're all looking towards. I was a fan back in the day of a Flickr's API for those that remembers it.
PF Ah, it was a classic!
MB I think that was really a classic that started defining like the whole idea of like, hey, an API can be this friendly to developers in this discoverable in this fun to play with. Right. And again, I think, to me, that's also the key, right? Like, the more we make these tools, really approachable and delightful for developers, the more delightful experiences those developers will go and build out in the world, right? And I also really agree there that that's what makes API's great, right? When when developers can get creative with them and build really cool stuff.
BP Right. Did that DNA from Flickr carry over to Slack? I feel like that was one of the things that really put them over the top was that you could integrate all the services. We had been using, roll your own chat that we built at Fox, and then we used Yammer and oh, man, Slack was just such a breath of fresh air.
PF It was but you know what the I mean, yes, they did good. It's just they get really excited about IRC compatibility early days, and then that just slowly got taken away. That's always, it's always sad when they're like, not aware of the internet, you want to use IRC with this, or you want to use Slack, whatever. And then it's just like, it's not really gonna work anymore.
BP Pour one out, pour one out. I didn't actually make the connection there, which is that Stewart Butterfield was that Flickr before?
MB Yeah. And I think they, what they really had was that what I talked about before, right, the simplicity, where you can set up a webhook. And then from C URL, you can start sending messages into Slack. And you're like, I really understand this. That kind of simplicity in the model, like when the mental model is simple enough that you can take it down to that step and understand that I always get excited about that.
PF You know what it is to me? It's when they get away from URLs, when people are like, ah, REST gets argued about endlessly as to what is good and proper REST. But to me, it's just like, the thing everybody latches on to is I can think about a service as a set of URLs with some verbs attached. And the same is true with the webhooks in Slack. It's like, you can address the entire interface inside of the application and that there were so many years and there have been so many efforts to be like, 'you don't need any of that, you can do this instead!' or 'it'll auto discover' that's always the one where they're going to this service will find the other services. No, a human will look at a webpage--[Sara laughs]
SC I've met computer before. [Sara laughs]
PF That is always the dream is always to get the person out of the loop and to autoe it. And it's just like, why would you want to do that? just hire a developer for God's sake.
MB Yeah, I think that's always been the key behind the the tools I've been trying to build right is like to to actually build for developers and think that developers are a good thing, right? Like having humans be able to build stuff with technology. That's, that's great. Let's give them great tools to reduce the friction of all the things that just distracts them. And then have been yes, but let's give them they're the best tools to really focus on on the part that is development, right? Like this building experiences, there is creating value, right? And I think, thinking of API's of services, anything with with that kind of actual human being in mind, that's going to sit and build stuff. That's very important to me.
PF Let me throw you a curveball, right? Because you've got a certain a certain kind of developer, I think, sees Netlify and goes, Oh my God, this integrates with GitHub, I got the website up. It's the interface to the 12 API's. I feel good about myself. I saw my branches. I'm going home, good for me. The rest of the world has different opinions, right, not about Netlify, but like go into planet Salesforce. All these different API's are going to be glued together around Salesforce using MuleSoft integrations you're gonna fill out forms--
SC MuleSoft?!
PF MuleSoft! Let's get somebody from MuleSoft on the, on the show and we'll just yell at them. [ & Sara laugh] That world over there, right, which is, it's gonna be way more plug and play, it's gonna be like Windows USB, you're just gonna and it's gonna make a noise and you're gonna be happy. And then on the other side, I think you've got like, kind of low code on the rise and a sense of like, you don't need all these all these developers. Do you factor that in? When you're building products? Or have you said to yourself, 'I'm going to build for this developer and to hell with it, do what you may'?
MB No, I would say both, both of those have been part of the story, right? Like, the first thing is that whether it's Salesforce or any large enterprise, right, they will have a big hodgepodge of services and internal stuff. And so and it's never going to go away, right, like so think, anything you build, if you wanted to be usable in those contexts, you have to say, like, we have to coexist with all of that, right? But that's, that's where we've seen that it's been powerful, this concept of decoupling the presentation layer, right? Because suddenly, you can sort of carve out that whole, like web experience, put it on its own plane, and then focus on, okay, so what's the bridge? Like? How do I talk from the web to all of those existing services, or to my endpoints in Salesforce or whatever, right? It's where we've seen things like serverless functions become really powerful, right? Like, you can write a little bit of logic there that glues together the presentation layer and the back end layer, or in the build step, you can suck in data from these legacy services, and then pre build the front end, and so on. Right? So coexisting with that, I think it's always been important. And then the local thing, I don't know, like, as long as I've been in this business, I've been told that that web developers would go out of business, right? Like, it used to be like when the first came out, and Wix, and Weebly, and so on, everybody were like, 'all developers are gonna be obsolete!'
PF It's always something, right? It's AIML, that or outsourcing, or it's like, there's always a lot of reasons why you shouldn't go to work in the morning, and then you go to work, and there's a lot to do. [ laughs]
SC Strangely!
MB And that's only more to do, right, like, because at the same time, like, I think what's happening and what happened even more in 2020, right, was that, as the main present most businesses becomes their online business, if you as a business, just rely on on local tools, or whatever that sort of gives you like an out of the box, this is what you can build experience. How are you going to differentiate your business from anyone else's business for real, right, like, and I think low-code is great, because it democratizes a lot of just getting stuff out there for for individuals, for small businesses for all kinds of that. But I think as soon as you're building, like real innovation on online or in the world today, right? Like, you need to build your online presence. And you can't just rely on some something out of the box to get there if you want to actually differentiate. So I think it always just allows those areas to focus more on building, like more advanced things. And then as we go along, it becomes easier. Like I mean, there was a time where it's really hard to, for anyone to get something up in a domain. And now it's really easy for anybody. That's great, right? Like, I think more of that, the more the merrier. But I just never think that it will mean that suddenly, the art of building like complex user experiences or floats will be delegated to to some random tool.
BP Well, if the podcast economy tells us anything, it's that everybody needs to build their own website. I can't listen to a podcast without hearing about Wix or Squarespace and how I can fulfill my dreams. The website of my dreams will make my dreams come true.
PF You need a new tress and a new website.
SC And your tress needs a website. Yeah.
BP Exactly.
[MUSIC]
BP It's that time of the episode, I'm going to shout out a lifeboater, that's somebody who took a question with a score of negative three or more, gave an answer and got it up to a score of 20 or more. This question is quite old, but it's just surfacing today. It says the lifeboat was accepted two days ago, so shout out to Jim Mischel. 'Find the first character in a string that is a letter.' That's a six year old question, but it's got a brand new answer that is bumping up to the top.
SC I feel like that would be a great Sesame Street Song.
PF Yeah, really is. [Sara laughs]
PF There's a son and it has a raise. [Sara laughs] Son has a raise.
SC And strangely, George Clooney.
BP I see a conga line.
PF TCHAR, TCHAR, TCHAR!
BP Can we pitch a development deal when we're done with this podcast?
PF Yeah, no, because of all the money and children's television about programming. [Ben laughs] Alright, good. Well, we did it!
BP We did it.
PF We did it. I'm gonna go deploy a branch.
BP Alright. My name is Ben Popper. I'm the Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper. And you can always email us podcast@stackoverflow.com. Matt, why don't you tell people who you are and if you want to be found on the web where they can find you?
MB I'm Matt Biilmann, I'm CEO and co-counder of Netlify and you can find me on Twitter under @Biilmann.
SC I'm Sara Chipps, Director of Community here at Stack Overflow. And you can find me at @SaraJo on GitHub.
PF I am Paul Ford, friend of Stack Overflow, check out my company Postlight and apply to work there. We are hiring and we are growing rapidly. I need designers, engineers, product managers, the best of the best!
[OUTRO MUSIC]