Learn more about how the no-code movement benefits everybody!
Vlad Magdalin is the founder of Webflow, a powerful visual development tool that enables people to create professional websites without writing code. Webflow is on a much lower level of abstraction than something like Squarespace, and users still need to understand the core fundamentals of web development.
You might think that tools like these are going to take jobs away from developers, but it actually does the opposite! When innovative technologies allow more people to do work that was once restricted to experts, it benefits everybody. That's what the no-code movement is about. Removing barriers, and giving development power to non-experts.
As developers, we'll be able to collaborate better with designers and other team members. And with the increased output of surface-level webpages, there will be more demand for developers with a deeper skillset.
Teach a non-coder one coding related topic without using code
Kent C. Dodds (00:00):
Hello friends. This is your friend Kent C. Dodds, and I'm joined by my friend Vlad Magdalin. Say hi, Vlad.
Vlad Magdalin (00:06):
Hey everyone. Hey Kent. Great to be here.
Kent C. Dodds (00:08):
It's good to have you. I did ask you to say hi Vlad, but that's okay. Hi everyone works too.
Vlad Magdalin (00:16):
Kent C. Dodds (00:16):
Vlad, I'm so excited to have you here. For those who don't know you, you founded a company called Webflow. I'd love for you to tell us a little bit more about that, but I met you, I think you had already founded Webflow.
Vlad Magdalin (00:28):
Kent C. Dodds (00:30):
And I think we met at React Rally. Is that right?
Vlad Magdalin (00:33):
Yep. I don't remember exactly which one, but it was definitely at React Rally.
Kent C. Dodds (00:38):
Yeah. I think you may have taken a bunch of us out to dinner or something, or lunch or-
Vlad Magdalin (00:41):
Yeah, something like that. Yep. That's right. I remember the place too. It was a sushi place and it was amazing.
Kent C. Dodds (00:46):
Oh yeah, yeah. I remember that too. It was delicious. Fun times. I love React Rally. I can't wait until we can meet in person. Maybe this year might workout.
Vlad Magdalin (00:55):
Hopefully. Cross our fingers.
Kent C. Dodds (00:59):
But it's just been a pleasure to know and follow you. A bunch of my friends have gone to work for you, and they all love it, at least that's what they tell me.
Vlad Magdalin (01:11):
I'd like to think working with me. I don't like the working for me phrase, it's a little bit old school.
Kent C. Dodds (01:14):
Yeah. Actually, I think I've tweeted this before, but I have a short list of companies that I would like to work for, and Webflow is toward the top or maybe the top of that list. Just the interesting problems that you're tackling and the amazing people that work with you. Merrick Christensen is one that comes to mind. I just love Merrick, and I was actually writing one wheel with him a few weeks ago and he was telling me about the stuff that he's doing.
He's like making a programming language or something, like what? So, pretty interesting, fascinating stuff, but I need to stop talking. I want you to introduce yourself to our friends here, Vlad. Can you tell us about yourself? You can be as professional or personal as you want and take as much time as you'd like.
Vlad Magdalin (02:04):
Sure. Well, again, I'm so glad to be here. It's an honor to spend more time together. Like Kent said, my name is Vlad Magdalin. I grew up in Russia, actually. I came here as a refugee when I was nine and started Webflow four different times, starting in 2005. There were three failures up until the time that hopefully ends up not failing. So far it's working out. So started this iteration with my brother and another close friend from Intuit in 2012.
And we're going deeper and deeper down the stack to where we now have a CMS, which is an abstraction of a database and we're also exploring logic and business logic, things like that. Webflow is used by millions of people at this point, but we're still a really, really small fry compared to WordPress. WordPress is something like 50% of the internet. We're more like 0.05% of all websites, but definitely having a lot of fun doing it. I don't know what I'm in charge of. I'm technically the CEO, but that job changes every three months or so. The company is about 250 people now, which is rapidly scaling. Job feels different every day, but it's an honor to lead great people and work on this really important mission that we're on.
Kent C. Dodds (03:56):
Wow. That's awesome. I am just amazed. Just the tenacity to start the same kind of concept four times, and now it seems to be working. What do you think is different about this time?
Vlad Magdalin (04:09):
You call it tenacity, my wife's calls it stubbornness or bull headedness. So many different factors made it work this time. A, co-founders. My brother being an amazing designer, we built the product for him. He created essentially the entire user interface and the abstraction visually. I think that's the hard part. And then my co-founder, Bryant, who was way better than me at backend stuff, I was more of a front end engineer.
But the most important thing I think is the timing of web technology. The first three times when I tried to start Webflow with different co-founders or by myself, Chrome didn't exist, Firefox didn't exist. There wasn't the set of APIs like the DOM API or CSSOM that really allowed you to build an app in the browser. And to build something like Webflow, for it to be truly WYSIWYG, you have to either write your own browser, which very few people can do, or you have to be able to emulate in real time what a certain code change would have on the browser.
With Chrome 1.0, which happened around 2010/2011, was when something like what Webflow actually ended up being technologically was even possible. Companies or other founders might've had the exact same idea, call it Wix or Squarespace, they might've had the exact same idea, but just that technology wasn't available at the time.
I think it really is a big combination of right people, lucky timing. Actually, a little bit of lucky timing in the sense that when we started Webflow, everyone else was focused on mobile. There was almost no competition because every investor, every other company were like, "Oh, the web is dying. You have to focus on mobile apps, et cetera." There wasn't much in terms of investment or encouragement, and people were like, "This idea failed before with Dreamweaver and Adobe tried a bunch of times." It was a really great combination of lots of factors that gave us the time and the runway to really figure out to build the technology.
Kent C. Dodds (06:17):
Yeah. Well, I'm glad that you're fighting for the web. I love the web. It is not dying.
Vlad Magdalin (06:22):
It's not at all. It is thriving.
Kent C. Dodds (06:26):
That's great. I'm glad that you have the stubbornness or tenacity to keep going on this project. I think it's really cool. I bet most people who are listening in have heard of Wix or Squarespace, and probably you're trying to frame Webflow into their mental model there. Can you differentiate what is Webflow relative to those things? Are they direct competitors? [crosstalk 00:06:52]
Vlad Magdalin (06:51):
Not at all. If you think of Wix and Squarespace, one of the best analogies I've been able to think of is like iMovie and After Effects or Final Cut Pro. IMovie, anybody can use to cut together a pretty quick movie, and same thing with Wix and Squarespace. You pick a template and then change some content, but you're really within the constraints of that template. Whereas After Effects, you're essentially creating production grade visual effects, and you really have to understand the core constraints of the medium to use that tool properly. Same thing with 3D animation software. To use that effectively, you have to understand modeling, animation, rigging, et cetera, down to the core primitives.
Webflow is the same. Webflow is almost like DevTools or Web Inspector plus some visual tools. So underneath it all, we truly abstract HTML elements and CSS declaration blocks. And within those, we just have visual abstractions over each CSS property.
It's essentially a one-to-one type of relationship where when you're using Webflow, you're essentially implementing the same way that you would write, maybe not CSS and JS, but the traditional way of writing style sheets. You're doing that in Webflow. In fact, we have this code preview mode. As you're making changes, like dragging the margin or changing the border, you can see the exact CSS property that's changing. Or as you're dragging in a new element, like a div, and then you choose whether it's a section or it's an aside or something like that, it's the same mental model of how you're thinking about hierarchy inside of an HTML template or something that's an abstraction of HTML.
Webflow is very much way lower level in terms of asking our users and these professional designers to really understand core fundamentals of web development. They have to understand the box model. They have to understand how Flexbox primitives work. They have to understand that you don't just click on something and move it to the right, or just drag it to the right. You have to know to go to its parent or its container and set its properties to, let's say, align along a certain axis or whatever.
It's very much like, sometimes we call it visual development. You're literally thinking the same way that a developer would, not at the syntax level, but at the primitive level. So same way when you start to work in Webflow with our content management system or CMS, it's essentially creating tables and columns in a Postgres definition or an act of record declaration if you were using Rails where you have to think about which objects do I have? What is the relationship between them? You really have to think around, is this a one to many relationship? Is this a many to many relationship? And the constraints that that entails, because a lot of times, just because you have a link from one object to another doesn't mean you have a link back from another object back. You have to think of it as a developer would as a data model exercise.
Webflow is that way more professional tool set that's all about building really professional websites and applications. Our entire mission is to, how do we take most of the power of code and surface it in a way where you don't need to know most of the complexity or the accidental complexity behind having to write that code. That comes with some drawbacks because it is a harder learning curve than what's in Squarespace by sometimes an order of magnitude.
But, once you learn those things, you essentially have the superpowers of a coder to a certain degree. We have people who a single designer who is running an entire production marketing site that is hundreds of pages or maybe even thousands of dynamic data objects, where before it was a team of four engineers. Those four engineers can now go work on something a lot more interesting than updating marketing sites. And you're essentially getting all the benefits of running the stuff in production without a lot of the complexity behind, "Okay. How do we now QA this? How do we deploy it? How do we get this into production, et cetera, et cetera?"
A lot of times when I talk to developers, I really lean on the Web Inspector analogy because the Web Inspector in Chrome, for example, is getting closer and closer to what Webflow is, because a lot of times it's a lot easier to use a color picker than remember hex code.
Kent C. Dodds (06:51):
Vlad Magdalin (11:25):
It's a lot easier to define a gradient than remember the syntax for a radial gradient, right? And that's what Webflow is. It's just taking those visual abstractions and taking them to the next level, but not getting too far away from the core foundations and the core principles of the web primitives that we're working on top of.
Kent C. Dodds (11:44):
Oh, wow. Yeah. That makes a lot of sense. It sounds like, I mean, the ultimate would be, "Computer, build me this website that does this thing," and the computer just does it all right.
Vlad Magdalin (11:55):
I don't believe that's possible, actually.
Kent C. Dodds (11:57):
You don't think it's possible. I'd love to hear you talk about it because it sounds like you're making some trade-offs on what we think would be perfect. It would be so nice if we could just make it do this, but because it's not, we need to make trade-offs and move a little bit further down the abstraction layers, and you feel like you've hit the spot with where Webflow is at. Why do you feel that is the right layer of abstraction for people?
Vlad Magdalin (12:25):
A, because I believe that human creativity and expectations are always rising. Think of it like the 3D animation or, let's say 3D movie production equivalent. There we've created really, really impressive, super sophisticated tools that hide a lot of complexity. Before you needed developers to figure out, each company was building their own version of a render like an animation system, or you really had to be kind of a developer that understood WebGL or other 3D rendering principles in order to tell a story and work a Pixar.
Now we have really sophisticated software, like modeling, rigging, animation, particle effects, really, really sophisticated things. However, the hard part of what story do you tell, how do you make the characters, how do you make them unique, how do you make them like tell a really lively story? All that stuff is still coming from human ingenuity. And you're never going to get to a place where you say, "Hey, some Pixar brain create an engaging human story that's going to sell well." Right?
I think that's always going to need that humanity in the context of the creatives to figure out what problem are we solving or what story are we telling? And then use the tools to augment that creative endeavor. Right?
And I think when you're building for the web, it's always going to be that way. Whether it's websites or as we go deeper into applications, the hard part is always discovering a problem in the world. Like, "Hey, this is inefficient." Let's say booking a ticket for a concert is super tedious, and I don't like using Ticketmaster. I have an idea for how this can be much better. Right? And I want to use software to solve that.
The hard part is understanding users. What is their problem? What is the flow of things? And constantly iterating and tweaking that and learning. I don't know if you go into a full AI world or there's general AI maybe. Then we have much bigger problems than who's building software. Pretty sure it we'll be worried much more about our survival than should I design code or not.
So I do think that that Webflow and other tools are going to rise to that level of abstraction where the tools try to hide as much of the complexity as is reasonable that you don't want to repeat over and over. Right? That not everybody should be rebuilding their authentication system or their own deployment system or for the same way that not everybody, not all developers today are rolling their own hardware. They're just getting computing power from a cloud provider. Right?
Kent C. Dodds (14:58):
Yeah. It's getting commoditized. More-
Vlad Magdalin (15:01):
Kent C. Dodds (15:02):
... higher up the stack, we just keep on getting more [crosstalk 00:15:04] commoditized.
Vlad Magdalin (15:04):
So I think the problems at the very top of the stack of what is the product, what is the user experience? Those are always going to be really hard and are going to require teams of people to keep iterating and understanding their customer base and trying to find product market fit, et cetera, because they're so imperfect. But the lower down the stack you go, the more we're going to find abstractions.
We already have all these abstractions through APIs, right? You and I as developers probably 15 years ago, had to roll our own, Authorize.Net thing. Now we just use Stripe. Somebody five years ago would have had to use Stripe directly. Now they can just use Stripe Elements where that's even further abstracted. Two years ago, you could just use Webflow, which uses Stripe Elements, and you're just dragging and dropping things. Underneath the hood, you're essentially like replacing the same or using the same exact code that you would use as a developer. But we're hiding more and more of that complexity to really make sure that people are focusing on the things that truly matter, the things that are truly unique, right? The things that you don't know how they should work.
So I think that's always going to be the case where we want to make sure the tools mature to the point where a lot of the same problems that software engineers are solving all over the world, we try to find ways that only a few software engineers need to solve them. And then people can, like an order of magnitude more people, if not two, can use those primitives to build higher order things.
So one example is, let's say the Stripe example. You could either teach every single person, "Hey, now there's the Stripe Elements thing. Here's how you pull in some API code to pull it into your HTML or React template or whatever." Or you could say now this primitive of taking a payment is this no code thing, this visual thing that you just drag out and say, "I'm going to have a payment flow here." And then you specify some of its parameters. The same thing that you would pass in, like the API call you would send to Stripe. And now what you've done is you've essentially removed the requirement that people have to know, understand the context of, "Okay, here's an example of a code snippet. Where do I even put that in?"
Most developers will know, but most people won't know. And most people in the world, they're not developers by a long shot, right? 99.5% of the world is not, doesn't know anything about code let alone as a software engineering professional. So it's really the entire no-code movement is about removing barriers and giving more and more people access to that power.
The exact same thing happened with things like spreadsheets 40 years ago, right? There was a moment where the industry, the software development industry, they were writing like Fortran and COBOL and Pascal and almost everything was being done through these terminal based software applications. Really basic things like making sure the books are closed and making sure that our financial models are accurate. And then when spreadsheets came around first, they were kind of like toys, right?
And eventually they got more and more serious where people could solve real financial modeling use cases with it. And the assumption was that, "Oh, shoot, this is going to steal jobs from software developers because this is what we're doing now."
The reality was that you now have enabled a thousand times as many people to solve problems with computing, which means that a thousand times as many shots on goal to validate a business idea now happen. Maybe 10% of them worked out and now 10% of those need more developers to go work on the more complex stuff.
And we've had an entire software development industry blossom out of that. So the same thing is happening now with no-code right where you have a hundred times as many people trying to build stuff with software. Eventually they will need more custom things. And when they need more custom things, they build a company around it. Then they have to hire software engineers and et cetera. It only creates more demand.
And now we're seeing actually even more demand for software engineers than we did five years ago. Like non-linearly so because more people are starting to solve problems with software, and eventually it gets to these like, "Hey, we need more firepower here. We need more people to go in and solve problems that these visual tools don't solve yet."
But now because a hundred times as many people are doing these things, there's just fundamentally more demand. So it's almost like one of those rising tide lifts all boats types of things. And there is something where for every no code designer creating something like a software engineers is somehow like losing a job, which is wonderful because it makes you feel really good about the mission. When we first started, it was a lot of that worry around, "Hey, are we going to be taking jobs away from people, et cetera?" And I'm glad that's not the case.
Kent C. Dodds (19:47):
Yeah. Yeah. It makes total sense to me what you've described. So you've decided to operate at an abstraction level currently where people have to understand the box model or at least from an abstract standpoint, not necessarily the syntax around CSS and layout necessarily.
Do you foresee Webflow ever being able to move outside of those foundational understandings for people? If Webflow could have an abstraction on top of that, so people don't have to worry about that at some point?
Vlad Magdalin (20:24):
But then once they build the actual application, and they hand it off to somebody that's managing content or somebody that's adding pages, somebody that's just using existing components that somebody put into a style guide or whatever, then the level of abstraction is much higher. Right? They now think on an even higher order plane of, "Okay, now it's a lot more like Squarespace where I have these prebuilt components that this designer created."
But the very important thing is if you only do that, then it's hard to, in order to go to that more complex power piece, you have to break out into code. So that's why it was important for us to build this first and then start to make that power available to more people.
And now what we're seeing is that it's not just a designer that's enabling a less technical person to operate in this editor, like more simplified editor abstraction. But what you're seeing is designers who go really deep on the software in Webflow really understand it. They're creating components that they're putting out into the ecosystem. They're creating these galleries of components that they spend a week on building and then somebody else without knowing all of the complexity of how those things are built, they'll just copy paste into their project, and it's essentially done.
So they're gaining, the same way that we would pull from npm, and we get the benefit of other developers working on something. It's kind of the same principle where now designers who are less technical are using the work of designers who are much more technical, and they're reusing that work without really having to understand exactly how it was implemented from the ground up.
Kent C. Dodds (22:42):
Wow, that's very cool. I like that. And the way that you describe it makes it sound like the lower level editor is where you build your own Squarespace or you build your own Wix, and then you take that and on top of that, you can use you-
Vlad Magdalin (22:59):
It's a little bit like, so it's not like building your own Squarespace or Wix. It's like building your own Squarespace or Wix templates. So what happens in Squarespace and Wix, it's their team, their software engineers that are building each template. Right?
So what we're saying is now Webflow users, these professional designers can build the templates.
Kent C. Dodds (23:14):
Vlad Magdalin (23:15):
And what we're only building is the template builder. So we're basically moving the level editor and then people can build their own games or their own levels, et cetera. And then they can share those levels with other people and have other people playing in those kinds of environments.
And the cool thing is once you've done it, you can actually make it available to the world. So now we have like this huge template marketplace where other Webflow users are making a living just selling their templates to people who don't-
Kent C. Dodds (23:15):
Vlad Magdalin (23:43):
... want to go deeper on building those things from scratch, but they can benefit a ton from again, like standing on the shoulders of giants.
Kent C. Dodds (23:50):
I love that. That's very cool.
Vlad Magdalin (23:51):
So you get the benefit of both worlds.
Kent C. Dodds (23:54):
Yeah, very cool. And so it's really interesting the approach that you're taking. And I think that what I really like about this is what you said about how this isn't a zero sum game. This is actually like a rising tide lifting all boats where you're kind of democratizing creation or content creation on the web.
And what's really cool about that is we don't know how many people have died in a third world country who could have been the next Mozart or whatever just because they didn't have the opportunity. And so what you're offering to people is the opportunity to create on the web that they wouldn't have the opportunity to do otherwise. I just think that's awesome.
Vlad Magdalin (24:40):
Absolutely. The best equivalent I've seen is the movie industry and how we've democratized creation around video through so many different platforms, right? There's now people making a living on YouTube and Twitch and all these other platforms. That doesn't steal from the fact that there's blockbuster movies being built by Hollywood. Right? And that actually didn't steal a ton of demand from people going to see traditional movies. And it lifted the entire industry because now more people need video equipment. More people need more professional or prosumer video equipment. More people are seeking training around video editing. More people as they elevate from, "Hey, now I'm just a hobbyist trying to figure out how to do YouTube. Okay, now I have a following. Now I need a more professional setup, et cetera." It lifted the entire industry.
It didn't have to steal from somewhere else in order to enable many more people to benefit from being able to share their voice or their ideas or tell these stories or these sketch comedy shows or whatever.
There's so much. Who would have ever imagined if you had the movie industry in charge of all video production, that there would be millionaire children on unboxing videos and that there would be demand for that, or ASMR or whatever. You just go down the list. By making access to that medium a lot more accessible, you're just opening up the world to be able to express a lot more ideas.
And with software it's even more powerful because you're not just creating an entertainment experience or a just in time type of like, "Hey, you've watched this video and this is the experience." You can actually have multiplicative effects because you can create a product or a service that solves the same problem. That's the power of software. You solve it once. And as long as people find out about it, you now have this flywheel where more people can just use that software to solve that same problem for themselves. And the creator can make a living, form a company around it, do a lot of great things in the world because now they've made somebody's life easier, and we're able to sustain and finance a team, et cetera, et cetera.
And that is just a really, really powerful concept. It's the same way. It just feels wrong to a degree to have that level of power locked up in just the hands of 0.25% of the world. And when the reality is that the demand for this kind of work is so grand once people figure out that they can solve so many problems with software.
So, especially in an environment where it's not zero-sum. Every person learning how to use no-code tools doesn't actually take anything away from a developer. Unless honestly, you're a really terrible developer, right? If you were a developer 10 years ago, and your only job was taking Photoshop templates and turning them into HTML, and that's the only skill you had, which does not describe very many developers, then sure, maybe that was a threatening thing where a lot of these services that came around that just automated that or made it much cheaper to commoditize it. Then yes, if you don't upscale or learn React or something like that, then yeah, you might be in trouble. But for the vast majority of developers who are going much deeper on the software stack, it's not a problem at all. It only creates a lot more demand for the skill that they learned.
Kent C. Dodds (28:00):
Yeah, and even if that is you, and that's fine if it is, but you might want to see the writing on the wall. And if you don't want to upscale, that's fine, you just go build a bunch of templates on Webflow and it's sounds like-
Vlad Magdalin (28:15):
Exactly. Actually we have a ton of developers using WebFOCUS, it's just straight up faster, right? For the same reason that you would use DevTools A lot of times where you just don't want to remember the syntax. So it's the right tool for the job sometimes. Sometimes it's not right. Sometimes code is absolutely the right tool for the job.
Kent C. Dodds (28:33):
Yeah, I'm actually curious about that intersection. So let's say I work at a company and I feel like Webflow's going to be good for the company, but I realized, wait, that's what my job is. So what is my job now as a developer at this company where we're starting to adopt Webflow? How do I integrate with that? I've got services that we're using. How do I integrate those? I know we have a minute left, but we can go over a little bit.
Vlad Magdalin (28:58):
Yeah. I mean there's a bunch of flexibility like Webflow is no code, but there's a lot of ways to extend it with code. So developers typically can add code to integrate it to other services, et cetera. Most of the things that workflow is used in today, like marketing sites, developers, that's their second choice to work on if not third or fourth or fifth. They want a product. They want to move to algorithms, et cetera.
So in most cases, the developers are the ones that are selling it internally. They're like, "Hey, if I can teach the marketing team and the design team to go do this stuff without having to wait on me to go do that translation of a Figma file to some HTML template, all the power to the design team. Right? And it makes the developer's life life easier.
But there's so many different ways. Webflow is not an isolated thing, it's just like when you follow the right abstractions, whatever Webflow doesn't do, you can quickly augment with code. So that's why I mentioned there's always demand for more developers because you inevitably run into cases that are not abstracted yet, or won't be for a long time so.
Kent C. Dodds (29:59):
So as a company that's using Webflow, I could build little components in Webflow that integrate with our country selector that has some weird filters on it or whatever, and hit my APIs for different things.
Vlad Magdalin (30:16):
You can. Usually people use it in a lot more of a, like for example, the entire marketing site is built on Webflow. Right? And then you might have content and Webflow that you pull into other places, but only if the main source of truth for your content is in Webflow.
Not a lot of people use it in very partial ways. I'll have some components in Webflow, then I have another code base and you try to pull things across. That's still a little too manual. So more of what we see is one department will start to use Webflow where it's really appropriate. So marketing sites or internal sites or larger content sites or dynamic ones. But then build their main application in a more traditional code based way.
You usually don't get too much of a mix, but where we're headed in the future is that more and more, this area where designers live and the source of truth for what they own, is going to start to expand. Right?
Over time, designers are going to be hopefully in control of the design system. Right? Where developers can pull that in as almost like an npm import. All the different responsive variants and breakpoints are defined by a designer. And then when they change the design system, it just changes everywhere.
Hopefully we'll head in that direction, but it's going to be gradual. It's not going to be an all or nothing thing. So you're going to see more and more use cases being in designer land without this big intermediate hand-off piece where this is what I meant, I can't implement this, or this is going to take two weeks, or this is not how we do things here or whatever. Hopefully it moves more and more towards what we see with SVGs. Right?
You have the designer in control of those assets and then they hand over the final asset to a developer. You don't typically have a developer rewriting an SVG.
Kent C. Dodds (31:59):
Vlad Magdalin (31:59):
So something like that is going to start happening more with design systems, simple design systems. They're more complex ones as these tools develop, et cetera.
Kent C. Dodds (32:07):
Yeah, okay. Very cool. I feel like there are a hundred more questions that I'd love to ask you about Webflow, but-
Vlad Magdalin (32:13):
We'll do a round two later.
Kent C. Dodds (32:14):
Yeah, yeah. We're out of time for this show. Was there anything else that you wanted to make sure we talked about before we wrap up?
Vlad Magdalin (32:25):
I think we covered everything. I feel like if I mention something else we can go on another 20 minutes.
Kent C. Dodds (32:31):
Maybe we should do another episode. Yeah, well, I do want to close the loop on the idea that Webflow and technologies and the no code movement in general is broadening the number of people who are able to create on the web. And this is a very good thing. And so our homework lines up with that, and the homework is for you listener. I'm talking to you. Teach a non-coder, one coding related topic without using syntax, without using code, and anything to add to that, Vlad?
Vlad Magdalin (33:08):
Yeah, the way I think about that homework problem is almost everything in Webflow, for example, is a pure abstraction over something that you would write syntax around. So the box model, right? You can explain it by writing HTML, but you can also explain it by going to DevTools and clicking on boxes and changing some settings on the side and helping a non-technical person see sort of how those things connect.
And same thing with data modeling or trying to explain object oriented programming. And I think the critical piece with that homework is that once you get a person to see that they have this hammer, that they can now start to potentially solve their own problems with, and they don't think of software development is this, "Oh, I have a cousin who builds apps." And it's this magical abstraction that somehow requires a four year degree.
Once they start to see software development the way they see spreadsheets, right? They think of a problem like, "Oh, I can track this list of attendees for a party using spreadsheets or Airtable or whatever." Once we explain more of these high level principles behind software engineering, it demystifies the practice, and people feel more and more confident to start to explore software creation as a skill that they can practice themselves, which I've always seen as once people have that aha moment, it's like discovering reading in a sense because you're like, "Okay, now not only do I have access to understand what this word is, but I have access to so much more knowledge." And hopefully more and more developers can have these kinds of conversations with folks and help them understand the power of software.
Kent C. Dodds (34:43):
Yeah. Great. I'm looking forward to showing my wife the box model. That'll be great.
Vlad Magdalin (34:46):
Awesome. And if it doesn't work, we have a whole video on Webflow University.
Kent C. Dodds (34:51):
Oh, yeah. Perfect.
Vlad Magdalin (34:53):
That can help you with that issue.
Kent C. Dodds (34:54):
Yeah, great. So one other thing on that, I had another episode. I don't know whether it's going to be scheduled before or after this one, but if you haven't already listened to it yet, go listen to that one. It's with Maggie Appleton, and she talks a lot about metaphors.
She's the one who does all of the egghead, beautiful design illustration stuff. She's the one behind that. And so she comes up with these metaphors to explain software concepts. It's a really great episode. So listen to that one, do that homework, and then maybe do this one.
Vlad Magdalin (35:26):
Kent C. Dodds (35:26):
Okay, thanks everybody for listening in. Vlad, last thing. What's the best way for people to keep up with what you're doing?
Vlad Magdalin (35:34):
I'm on and off Twitter. Sometimes I'm active. Sometimes it's not very active. I'm just @callmevlad there. That's probably the best way, and yeah, hope to see many of you online.
Kent C. Dodds (35:46):
Awesome. Thanks so much. We'll see you all later. Bye.