Everybody knows the statistic, right? The one where WordPress powers the third of the web, which is so whack-a-doodle statistic. That's like, what? That's why there's so many people here, because that's so amazing and cool.  I like to start this talk with a personal feeling that maybe it's because a third of the developers in the world cut their teeth on WordPress. I've talked to, throughout my career, I'm a front-end developer. And I go to conferences. And I have shows. I've just made my life, being and thinking about being a front-end developer. And so many of them have WordPress experience. It's almost weird to meet a developer that doesn't have any of these days, like industry-wide. And I think that's significant, too.  I just think that's cool. And I just count myself among that group. When I got started building websites, it was totally through the WordPress path. And I'm so glad that it was, because that has helped my career tremendously. Let's spend a while thinking about how to be a front-end developer. That's the talk title, for sure. Like I said, I've kind of made my life out of that co-founder of CodePen, which is like a social playground for playing around with the web. And I have a podcast. We'll get into that. And I've been writing about it for almost 11 years on CSS Tricks. It's really my whole thing. So I've been wanting to do this talk forever. What is a front-end developer? How do we think about it? Let's take one little pit stop before we get started. Is that a correct sentence? I work as a front-end developer. Yes, it is, because front-end is a compound adjective. And it should have a dash in it. Is that a correct sentence? I work as a front-end developer. No, because it doesn't have a dash, even though it's a compound adjective. There's a right and wrong answer to this. I don't feel it's necessary to correct people, because it's kind of like, you can let people be wrong. That's fine. Like, just let it go. But it's like, well, we're going to say the word like a thousand times in this talk. We might as well be right about it. What about that one? I work on the front-end. Yes, yes, it's a noun, not a compound adjective. So it's cool. Is that right? No, because that's not a thing. It's not being used as an adjective there. What if you saw a blog post said that? You could say, that's not a word. Is it a word? Are we like, well, we can appropriate it. That's cool. But if we're going to fight that fight, we've got to decide to do that collectively. And it's a whole process. OK, so what is a front-end developer? Well, I run a job board, a code pen job board. And it's kind of focused on that. So people hire for being a front-end developer all the time. There's the smashing mag one, the Stack Overflow job board. There's a million front-end jobs posted all the time. Huge industry. It's super definitely a job. And super definitely a job title that people have. I'm sure there's a lot of people here that self-identify that way, have front-end developer in their job title in some way. So there's no doubt about that. I have a million thoughts about how to think like one and all this, but I wanted to not just have this me being like, this is what a front-end developer is, and have it be representative of a lot of different voices and what they think being a front-end developer. So on my podcast, Shop Talk Show, I've been doing the series about this one, asking kind of a series of pointed questions, the same questions to different developers to get different perspective on those same questions. So that's me and my friend Dave who run Shop Talk Show. And so far, we've talked to these developers, Monica, Eric, Sam, Brad, Trent, Mina, Ben, and Peggy. And we'll hear from more of them throughout this whole thing. But I wanted to learn, has it always been a word, like in the early days of CSS? Do people refer to themselves as front-end developers or not? So I kind of asked Eric this question who probably has the longest career of the people that we talked to, and we're gonna talk a little bit about the Zengarde, and that was a key moment in the history of front-end development where there was like this one unchanging HTML file and different web, you know, front-end developer designers would apply different style sheets to it and do drastically different things to that document. And it was like open people's eyes to what the power of front-end development and specifically CSS could do to a document. While Eric talks here, it's gonna show a movie of like the new rebooted. So let's say during the Zengarde days, did you say, you know what my job is in the world? I'm a front-end developer. Was that like, was that a term then? Or is that newer than that? I feel like it's a little newer than that, at least as a term of widespread currency. It's become more widespread than that since those days. Like at the time, we didn't just talk about, ooh, front-end versus back-end, right? The Zengarde days where we were still coming out of the era of everyone's a webmaster which meant you had to be what we would now call a full-stack developer. Of course, back then that meant that you understood that there was a CGI bin directory and maybe you could write some Perl. You know, we didn't have the vast, what would you even have known what it meant with somebody like, or is it?  So it was, kind of. And even in the earliest days, front-end developers have been a thing. We've had time to let this thing shake out. You know, like it's a term that was meaningful then, at least to some degree, and is definitely meaningful now. So it's a thing. They were, we're gonna call it a developer. I don't know if you knew that, but it just didn't catch on. It was weird. So I think of all the people I've talked to, Mina put it the best. Like, what's a front-end developer? It deals with things that you can see, things that are actually inferred beyond the screen in a web client, in a client. And in my mind, anyone who works on a user-facing interface or application website or whatever, in my mind, that's a front-end developer. Yeah, what you can see, right? What people use in the browser. Like, if you deal with the client, then that's what makes you a front-end developer. It's not specific languages or whatever. It's like you're dealing with people and they use the browser. So Trent here struggled a little bit with what to call himself, but really underscores the browser. You know, I think on my, I looked at my website, my blog, and I was like, what did I, I forgot, what did I call myself? And I think I say something like, web designer and a web builder. Because I don't want people to think that I'm just this like, full stack, the buck stops at my desk and any front-end question that you have, I will be the person at Paravell to go to for that. But like, yeah, like I live the majority of my time in whether it's design or building or optimization or whatever it is, it's spent in the browser. And that's all I think about, that's where I live. So I love that, of course it is. It's the browser. That's what really makes us front-end developers is just living our lives in that, in that browser context. This, this is really where it is. And it's not like the back-end developers don't have a browser open all day also, but we care about it at like a weirdly deeper level, like across all kinds of different browsers and all that stuff. And like we care about everything, every little scroll and click and DOM event and nugget of anything in the browser where we're kind of deeply into. So this is us, you know, there's a heck of a lot of them, isn't there? I should have probably removed the edge ones though, huh? Sick burn. Yeah, but of course it's not, it's not just that, you know, we care about the users, but doesn't everybody, like if you work at a company, aren't you like, should you probably like, should care about the, well, I think that's true to some degree, but Monica puts a kind of a good point on it. I struggle to phrase it in a way that's like doesn't sound like a back-end person doesn't care about the user or doesn't care about websites because they kind of do too, right? But they're totally allowed not to, right? Like if you're the person who's writing the SQL code for the database, I think you're totally allowed not to care about the user. This is your personal choice because at that point you're like delegating your responsibility. So what I'm trying to say is that I think it's totally fine to not want to call yourself a front-end developer too. As much as we do as front-end developers, there is other roles still, you know, of course there is, there's back-end developers and she's kind of saying that that's a difference. You could be a great front-end developer who's really focused on what they're doing and kind of like on purpose delegating the responsibility of deep caring about UX to another role. And it's not just browsers and it's not just the people that use those browsers but of course it's this craziness too that we've been talking about forever, this rainbow of devices that represents front-end design. So it's super definitely a job with a job title. It deals with the browser and the devices that those browsers run on and the people that use those things. That's what a front-end developer is. What do you need to know though? We haven't talked about skill sets a little bit. We can get into that. There's definitely like this whole set of foundational skills that's fascinating. Like you need to be like super computer proficient to even start thinking about being a front-end developer which I think is a whole fascinating thing to think about and talk about. Like you have to be good at this whole slew of software and you have to be like a good typist or have some way of entering proficiently characters into a computer. There's all the stuff you need to know to even get started at all. And then there's this whole slew of soft skills which is also a wildly fascinating thing. Like you need to write a damn fine email. You need to have good Slack etiquette. Slack etiquette.   Actually we're on our way to, I was thinking about all these job skills that you need to know and I was thinking about we're going to Nashville, like the mecca of acoustic guitars and stuff and I was like, oh, this reminded me of this great Doc Watson song. The guy gets the job, you know. He rolls in and he's like, the boss is like, what can you do? He's like, I can lay a railroad track. You're hired, you know. It's amazing. I wish you could go into a job in a few now and be like, what can you do? And be like, I can align squiggly braces. You're hired. That'd be great. It's not as easy anymore.  Read, write, maintain them and then a bunch of bonus skills too which is what makes this interesting which is probably gonna be mostly what we talk about here. Let's talk about these core skills for a minute. This will surprise nobody. They are HTML and CSS I would think. Yeah, you know, like the reason that that's not controversial is because every single website in the whole world is built from them. There's all kinds of other stuff that happens but in the end, it's HTML and CSS. 100% of websites have HTML of some kind. That's definitely gonna, there's some things coming down from the wire that gets turned into the DOM that makes that website. Probably 99.9-ish percent of websites have CSS in some way. I'm sure there's a couple outliers still using font tags or whatever. Those are fundamental skills that will serve you well. It's not like, oh, yeah, they're there but we only write in abstract languages. No, like that still, there's plenty of the work that we do as front-end developers too. Like the six-year-old tweet from Dan Cederholm saying that it's really through his 15 years which would now be 21 years, I guess, is that HTML is still a good bet, you know? And I'd say that's true and even for CSS too, there's really nothing that's like angling to unseat those things. There's always ways that we're compiling it differently and thinking about it differently but as a fundamental technology, it's as important now as it really ever has been which is cool. And then there's a third language, though, isn't there? I'm pretty sure there's a third language. Let's see what Eric has to say about that. You know, and it might be somebody who knows a ton of JavaScript and can hand write it all or it might be somebody who only uses libraries like jQuery or it might be somebody who never writes JavaScript at all. And... Yeah, it doesn't make you not a front-end developer. Right, I mean, I think you need to at least understand JavaScript in its role but that doesn't necessarily mean you have to be able to write everything from scratch. So yes, it's definitely the third language. It's, you know, what your skill level at it is can be widely different but you definitely need to understand its role kind of thing, definitely the third language of the well for sure. And then there's all these... Oh, and notice I put accessibility next to all three of these languages. It definitely touches on all three of these languages. Here's Peggy about that. Great, I do think though, like as a front-end developer, like you should have basic fluency and accessibility regardless. Like if you're building UI, you should know some basic principles of accessibility and not just leave that to a specialist. I'll let that stand for itself, I think. And then there's these plus skills or bonus skills, whatever, I found this fascinating. I got this from my wife, Miranda, who worked on like digital teams at media companies for a super long time and in fact was part of the lead-up, the team at the Boston Globe when they made that first responsive design years ago that kind of proved that it works at a large scale for the industry. And when she was hiring, there'd be people that would come in and they kind of like just knew HTML and CSS. And even back then it was kind of like almost not enough. And I hate to say that because that's not exactly what I mean, but she would always look for people that were like, sure, that's like the get-in-the-door core skills, but it was, they tended to hire people that were HTML and CSS plus. That they were like, if JavaScript is your plus, that's great, that's a full-rounded thing. But it could be plus, you're a great designer too or you're a great copywriter or you're an illustrator or you dig into accessibility or you have some other skillset that augments those kind of core skills. And I found that kind of fascinating. And it leads to this like life as a front-end developer really any career, but that's what we're talking about here is a little bit like a choose your own adventure book.  What do you do? Stab it in the keyboard with a fork? Turn to page 94, you know?  Turn to page 12, you know? And everybody's life is this different fork and path and everybody ends somewhere differently, but we're all reading the same story. Metaphorically, our jobs is like this in a way and that there's this fundamental tree of what we all know, but we all end up with wildly different skillsets. I don't know if it's the perfect metaphor, but that's the one we're gonna use. And it's leading to this point like is front-end development going through somewhat of an identity crisis? This is the kind of fascinating premise that we're gonna be working with here. We can pinpoint a moment, I think, when that started to happen. This thing happened for sure. Number one language on Stack Overflow. It's the most code on GitHub. It's this massive chart of package managers that took off NPM being that red line there that has really blown all the rest of them out of the water. There's a moment right there, right? Really NPM is really taking off at the end of the 2015, which is this kind of seminal moment which many of you will recognize. I'm gonna give you one homework assignment in closing, which I've never done in a state of word before, and you might be able to predict it. And it's a learned JavaScript, deeply. It's very all familiar with that. It turns out that red line happened. He's kind of right about that. And then of course, it's huge in the client, but it's really, you can be a developer these days and know no other language. That's possible. Cool, so this has been happening. I've been reading blog posts and comments on blog posts and finding the sentiment of this is absolutely all over the place. Here's Stephen Davis saying just like, let's just not use the word anymore. Let's split. Let's be UX engineers and JavaScript engineers. They're different mindsets. People tend to not be good at both. It's just where this world is heading a little bit. And Stephen being like, I'm happy to just not be on the JavaScript side of that. I'm good at the HTML and CSS kind of thing, and I'm sick of being forced to do more than that in a way. That's just one sentiment, but there's a lot of that happening. So maybe if our metaphor is this, which is already a wide array of skill sets that have led us there, it's starting to feel a little bit more like this. We're all front-end developers, but there's this path that you can take right at the beginning that leads you down this deep JavaScript land and this other path that kind of doesn't, and you still end up all over the place, but there seems to be a split kind of in the middle. Maybe that's not fair, but still we're gonna roll with it for a minute. Vernon Joyce has the first article I read that called it an identity crisis. Who blames the frameworks? Saying that these frameworks are huge already, not only in what they do from us, but how many websites they're already powering. It's just this massive like, everybody's doing this kind of thing, Angular React, Vue, I remember all of them. And that the people that go down that road, the right media articles about MVC and functional programming and the context API and React suspense and all these like very fancy things that some of us are front-end developers for a long time reading and you're just like, what's that about? Yeah, I mean like this got weird real quick. It feels like a alternate universe sometimes where you're standing there right next to another front-end developer and you share no skill set at all together. But we're both, are we both? We're both the thing? That's weird. Brad stumbled upon a way to describe this in one of our shows. I don't wanna sort of configure webpack or like gulp like workflows and stuff like that. And so I found that I'm sort of on the more design, you know, the front of the front-end and then sort of having somebody else that's more on like the back of the front-end as a nice sort of complimentary role. But he called it a complimentary role, which is kind of cool. Like what if there's these two people that went down these different paths? Together they could be great. Yeah, absolutely. People after hearing that wrote comments in like, I've been feeling that divide for years now. And somebody said just yesterday I was looking at a code base and thinking, this was clearly written by a JavaScript developer which is a poke for sure. You know, there's not a poking across the divide. Plenty of that kind of thing happening. But there's more than poking happening too. There's lots of like extreme frustration that's happening too. And there's nothing more personal and frustrating than trying to get a job and not getting one because of this divide hurting you in some way. Here's Michael from Just Markup saying that I'm seeing this industry wide. I'm seeing companies hire JavaScript developers replacing back-end developers. And sometimes when that happens, if you go down that deep JavaScript route you don't, that maybe your skill level at just the HTML CSS thing is kind of bad. You don't write it very often, you don't care about it that much in the same kind of way that I as a long time front-end developer am very helpless at a lot of back-end tasks. I can't do much with a database. I can't configure servers particularly well. I'm hopeless at that. Thankfully nobody asks me to do that that often but all of a sudden we're asking JavaScript developers to be great at some front-end tasks too. It's a weird crossover.  The job posting met some 80% of what she thought she could do for that company, went in, the interview was mostly great but then asked her some like JavaScript algorithm style questions that didn't go particularly well and didn't get the job and was kind of like WTF, you know, like, why did you ask me in here? Like I have this deep skill set. Laura's a great developer who has a wide skill set of front-end JavaScript stuff but also WordPress development and all this and then didn't get it from some dumb little thing. It's just kind of like that can be extremely frustrating. It can be like hiring-wise. We've got to be more clear about that. So here's the situation. Now hiring a front-end developer is a job post. Hey, I'm a front-end developer. Here's Sue. Sue is looking for a job but our last job was a React developer and worked on server-side rendering because they used Next.js a whole bunch and the data layer was Apollo GraphQL which is awesome and worked on this big app and it made sense to use a CSS and JavaScript-style architecture to get that because it worked on our team really well and just lived in that React and Babel and Webpack and Friends universe and it would be like, what are you good at? She'd be like, I am good at JavaScript architecture and I really care about performance. She's a front-end developer. She's a great front-end developer and she would fit on lots of great teams. Should she apply for that job? Hell, she actually could but here's Joe. Joe's also like, he worked at an agency for the last couple of years, built lots of sites, lots of WordPress themes, would sprinkle on jQuery stuff when they needed to because that's kind of all they needed. He was kind of like the CSS architecture guy, did a lot of SaaS stuff. He loves working with SVG and interaction design. If you say, Joe, what are you into? I'm like, I care about the users. I care about accessibility. I love building websites. Joe's a fantastic developer too. Is he a front-end developer? Yes, should he apply for that job? Sure but wow are those two people different. It's not like there's no crossover. It's not like those people can't learn those other skills. Certainly they can but sometimes when you're hiring a job it's about what you know right now and those are very different skill sets that are, you're gonna, one of these two people are probably gonna be wasting somebody's time which sucks, you know? It feels like that. Anyway, here's Peggy about that divide. I think like front-end developer is such a broad term. It's hard to really define like what exactly a front-end developer is because there's so many different specialties, right? Like you can be a specialist in SVG animations and be a front-end developer and not write any JavaScript at all. Or you could be more working on the data layer like I am and not writing any CSS for example and still be considered a front-end developer. So I think it's kind of, you know, as long as you're touching UI or touching something like a data layer that's tangentially related to UI I think you can identify as a front-end developer. Yeah, it's a wide place to be. I even think about in WordPress context like all of a sudden we have Gutenberg. Now great, how do you build a Gutenberg block? It's weird. It's like React and Webpack and Babylon friends. You gotta have that skill set and you gotta like no WordPress APIs and probably some PHP and stuff so there's some of that stuff going on and then it outputs like a thing that goes in your theme so you need some like HTML and CSS knowledge. Who is that? That's like a new person or a combination of roles is probably gonna be more done by teams and companies and stuff than it is by an individual. Like I'm sure there's lots of great super intelligent people here that can absolutely build a block but I'm kind of like not one of them, you know. I wanna do it, I'm interested but I'm gonna be collaborating with people and have a lot to learn because the skill set for that is weird. It's weird to me. Mel Choice has a wonderful blog article about how she put together a block for this conference for the speaker block thing and like look at how it is. You know, you gotta pick a block, it's got a special icon, it's got, I don't know, you have to know about what classes and stuff to use in there. I guess some of that is boiler-plated out but then it outputs something that's definitely gonna go on the front end so there's CSS class names involved but they're controlled by controls on the right so you need to know how to build that too. There's probably some APIs and stuff for that. You gotta learn and it's like, this is a pretty wide skill set here. Pretty, it's kind of fascinating and then there's like how do you build that dropdown? Well, I don't know, this is a React component so you're gonna have to NPM install some kind of NPM-y React-y dropdown-y Mc thing, you know. And then where does it get that data from that? I don't know, I guess the REST API, querying a custom post type thing, who's super proficient in that? The same exact person that knows all that React stuff or is that a different developer? I don't know, it's just complicated. And what about all these people that are like, I like WordPress fine but I like building, I wanna build my site in Gatsby or I wanna like build a, I don't wanna be told how to build my front end. There's a lot of this happening in front end development. I wanna build the front end, how I wanna build my front end, it's not that I don't like WordPress, I'm just gonna consume it with APIs and the REST API now exists and you can absolutely do that and GraphQL is getting bigger and there's a way to do that too.  That's a new kind of developer that lives in a kind of different world that I love that. I think that's cool, that's possible. I don't know if this is exactly a problem, there is a divide, a schism happening here. So, but like let's just acknowledge it and think about it and talk about it. That's kind of important. Hiring people, use your words for sure. Don't just say, we're hiring a front end developer and just let whoever apply to that, you should probably talk about it. This is, use the first few paragraphs of your job posting to be like, this is what we need right now. This is what you should know. This is, that way it's just, there's not a guess. If you're not that person, maybe you can look for another possible role or say that I wanna learn those things or whatever. There's a recent article from Hayden Pickering saying that there's a lot of places that have these like full stack gatekeepers that are like, I'm this amazing programmer and JavaScript can do everything now so it does do everything now. And they're in control of the HTML and CSS too because it's like the easy part or whatever. But it's not their competency. And that's causing some anger and problems that way too. Leads to like the greatest tweet ever. We only have full stack developers here. That's all we hire. Brad saying like, and it tends to be that one way around. It's not like the, a lot of full stack people are mostly proficient in great HTML and CSS and then also proficient in JavaScript. It always tends to be the other way around that the HTML and CSS stuff gets handled poorly. But it's not always that way. I don't mean to poke too far that direction but the point is here is like, it doesn't matter.   That's what teams are for. Businesses are cool like that. You hire the things, especially these things. Just because you have one skill set doesn't give you permission to do poorly at any of those particular things. So that's kinda cool. And maybe it does need a rethinking. Maybe we should stop saying front end developer so much and start saying other things. That's never gonna hold. The reason I don't advocate for particular job titles is because that war has been waged forever and it just doesn't work. You just, job title needs to be a paragraph I think these days, pretty much. Anyway, so let's end this with some front end developer candy, I think. If you're into thinking about websites and how other people think about websites, let's just do that rather than talking about the divide so much. Maybe there's a divide because people think so differently at websites. I had all these developers look at the same designs and then tell me what goes through their mind when they think of that design. Here's a design. How would a front end developer approach that? This is like the definition of sort of like component driven UI. I feel like this is like, I would have a blast with this just sort of going through and chopping this whole thing up. Brad thinks about components, atomic design. The first thing I see is lots of media objects. And of course, media objects for those who may not know, it's just, it's an image or a piece of media with some content right to the side of it. And I feel like most of this design can be accomplished with by creating a media object. And the only thing that kind of changes is how big that piece of media or content is. Just thinking about CSS patterns that can be used heavily throughout this thing to be efficient with the CSS. Instead of seeing the green characters in the matrix, I see HTML structures. That's literally where I start. So you immediately start outlining like H1, H2, H3? Probably if the stage is more heading, heading, heading, that's a list, that's an ordered list because of the nature of it. Over there is maybe an unordered list. And especially for the design, this particular design is a lot of lists. List, Eric sees lists all over this thing. He's probably right about that, taking near the whole thing. I see a lot of typography and I'm already thinking about the type system. Sam went on to say that that's like a, at the moment, kind of a weak point for her. And so she wants to start with the type system on purpose because he wants to get that set, and then move on to her things that she's better at. To me, I think this is kind of fun. Especially if you have to consider a variety of screen sizes, like the menu on the left, there's the Windows deal where I've seen where the menu kind of half collapses and maybe it goes to just icons, which may or may not be helpful in this context, but how can we sort of have, almost like what's the tablet width gonna do? Yeah, Trent was always talking about that. Like responsive design is fine. It's easy to think about the extremes of what designs are gonna do, but he was very into the really subtle in-betweens of what responsive design. Nobody said the same things, and that's just a tiny portion of what they said. So if you're into this kind of thing, our series on Chop-Doc Show is all about this type of thing. There's a bunch of them here. How's this weird design, you know? Like a really bold vector-based kind of design. I would love to tackle how to create these different animations. Yeah, everybody looked at those animations being like, ooh, how are we gonna do that? That looks fun. There's a lot of noise, like kind of like a speckled textures all over the site. There's like an illustration up top with like some cookware and some food and some coffee. You know, you wonder if you could maybe, instead of exporting this, there's like a gigantic diagonal beige texture or maybe it's like a table or something. Can you take that texture and repeat it elsewhere and maybe color it so you're not having to export gigantic image files? He was immediately starting to be clever and be like, how can we texturize everything with a lightweight file? Might not surprise you that I sort of tend to think of components and stuff. So immediately sort of the things that sort of stick out in my mind is, you know, what are these sort of repeatable elements even in this sort of seemingly very bespoke layout? He's like, there's no website too small for thinking in that way, in a way, which is fascinating. Asking for a lot of SVG resources. Of course, vector all day. And but Eric was saying like, this is a team already. I can't do this myself because I need people to be carving up these assets. I can't enjoy a website without thinking of it skeleton. Well, I heard a lot of that. Like that's all I see is this behind the matrix stuff. I think this one is interesting because it's a website that I might argue WordPress isn't particularly well suited to do or is it now all of a sudden? Like there's all these interesting weird blocks in the middle of it that are like, how would you do that with just one content area? Maybe that's starting to make more sense to chop up into kind of custom Gutenberg blocks. That there's that three column thing, not particularly well suited with just one text area kind of thing. You're adding markup or short codes or that kind of thing. All these things are probably gonna be served a bit better in Gutenberg land. I hope maybe we'll see how that pens out. It's been a day, so let's see. This is weird. Like this is more like a print poster. Like that G? Oh my gosh. Like I can stare at that G for hours. She was like admiring other people's typography to staring at a G for hours. Can you imagine? The first thing I'm thinking of is oh cool writing modes. I can use the writing mode to turn because there's a couple of headlines that are written vertically. So the first thing I'm seeing there is opportunity to use that. Just again thinking about interesting CSS approaches to handle this thing. Like how do you get that vertical text? What can I do now? This seems to be like it would re-stack or re-flow or reshape itself but keep the aesthetic intact at all views. It seems like it could be really fun. Trent again thinking about how weird you can get with the responsive design of it. That's fine for landscape but what about portrait or huge sizes? It's got writing mode, it's got grid, it's got fonts, right? It's got custom fonts. Eric was really excited about this one. He's like I'm gonna reach out to this guy. I'm gonna see if I can put this out like a Zen garden thing. Like how would different developers approach it? And he's like I wonder if he did that but it's kind of a, there's a lot going on here that's fun. People saw the dots and had different approaches to it. So he said I would approach those dots with an unordered list with just empty LIs in it. Just floated next to each other. I'm like oh my God, please don't do that. Oh my God.  This looks like everybody's website. That's the first thing you see is there. Yeah, it's got thin text at the top and then a round button and design at the bottom. She's like oh. But you know whatever, it's a landing page, right? Perhaps speak to them and you know if this is something that's gonna be used in poorer parts of the world, like whether they want backups for when SVG isn't available so whether you just have a standard background in JPEG or PNG, something like that. And how they see the interactions working where if I could get started is it a separate page or is that thing Ajax then already and the page is kind of transitioned across. So I'd be sort of asking questions about how should this thing feel? Yeah, right, Ben was always thinking about how does it fall back and what does it happen across browser and with low data and then like what's deeper than this?  And I was thinking this one too is one of those type of pages that's like I think we're gonna start thinking that way if we're all deep in WordPress line you're gonna be like block, block, block, block, block, block, block, this is a weird interactive one if you like roll over this, it launches some crazy stuff and animations. I always want to see a lot of big high resolution images that this is gonna crawl on anything less than a really, really good connection. Yeah, just thinking about like is that, like who's that gonna work really well for it? Who's it not? Yeah, it stresses me out that when I click on a link I don't expect that to happen, I think that's my... Yeah, you have some like UX concerns like there's a bit much. Yeah, a bit much, but I like when they come back together in Sightlands, so maybe you can focus on that. I didn't mean to have people like not, mostly people are like, this is amazing but you know, other people have concerns too. I'm seeing kind of like data that looks pretty static so maybe I would use something like Gatsby in order to build out this site. Yeah, Peggy talked a lot about things like that, a lot of GraphQL stuff but also like the tooling around it and using tools like Gatsby apparently has some cool image manipulation stuff that can help with the performance of these images. There's a weird dashboard kind of thing we'll look at. Whether things like there's little dots sort of marker points on that graph and I wanna know is there a touch target on there and if so, what's the minimum size for that? Yeah, thinking about the accessibility of touch, you know, this looks kind of like a tablet design are you gonna, is that something you can screw up? It also looks like there's some sort of like real time component to this as well because it's kind of like Uber where you like see the preview of the car driving to the destination. Yeah, real time, maybe what kind of APIs are involved? How do you build that map? I'll probably have to learn SVGs. I've been learning SVGs. Hanging out with Sarah Dresner is a problem in your life you learn about SVGs. Yeah, you know, I don't really know how to do the map part. Everything else sounds fine. That's funny because that looks like a Google map. Monica's at Google. There's a Trello-ish looking weird board here. And then I'd be asking questions about, I suppose, what's the support matrix for this? Who are you looking in terms of browser support? So could we be looking at something to be built with CSS Grid? Does it need to be something a bit older? Yeah, support. Like we all know about the new fancy things. What about the old things? Well, you're gonna have to drag and drop and that is the biggest nightmare in the universe. So good luck, have fun. It goes far very positive about... No, that's hilarious. Anyway, we can wrap up with the idea that I think and talk about this stuff a lot. I'm fascinated by what is a front-end developer and how is it changing and what is this whole world like on CS Strix. I write articles like, what makes a good one and how to be a senior one and the all-powerful front-end developer. That one's particularly relevant because it talks about how front-end design, it's not only just changing a little bit but widening a whole ton. We talked about how front-end developers are in some cases replacing some back-end developers and we're so powerful these days. There's a lot of things that front-end developers can build a site A to Z a lot of times even with fancy data stuff. It's a big conversation. This divide is kind of happening and I encourage people to just talk about it. I think it's worth talking about, especially when it causes frustration at companies because there's problems here with pay gaps and there's problems here with finding the right people and stuff and it's just worth having as a conversation, I think. Thanks so much, everybody, for listening to my talk. I think we just about get it. I said I maybe wasn't gonna do questions. We do have like five, 10 minutes so if the people have some good questions, I'd be happy to take one. I think a microphone is required, though, for the stream. Yes. Can you hear me? I can. Okay, my name's Amber. I follow you on Twitter, big fan. So I've been a freelance developer for like, I don't know, forever. And my biggest problem is that people think I only do WordPress. They don't realize I also do craft and I do static websites. I can do a little bit of PHP and some JavaScript and stuff, even though everywhere on my website it says I'm a front-end developer. So my biggest problem with changing to a UX engineer, because I don't do React or View or anything like that, is that will clients know what that means? My clients are like agencies, like design agencies. So how do people find you? Like, can you just tell them what you do, you know?  These are the CMSs I support, you know? Like, that might be a bit much, you know? Well, I mean, like on my homepage I have a list of, I do accessibility, semantics, you know, things like that. But it's not working? I don't know. I mean, right now, everywhere says front-end developer because that's what everyone understands. So like, if I switch to UX engineer, are they gonna think that I do design work? Because I don't do any design work. Oh, funny. It might be a use-your-word situation, although you already are, so I don't have to tell you. Like, if there's, it sounds like you're a rock in a hard place kind of thing, you're getting the wrong client. These can be solved with conversations, right? Once you're on the phone, hopefully you can really clarify yourself. It sounds like the problem is in the first contact, they're not understanding what you do exactly, but hopefully like a five-minute call can clear those things up. Maybe, hopefully, so good luck with that. But that means I have to get on the phone. Oh, rough.  Maybe one more. Hi, Chris. Thank you for all you do with CSS tricks. I use Flexbox on CSS tricks all the time. So my question is, like, with all the different paths you can go down, how do you pick? Like, what's the best way for someone to pick? Oh, I need to learn more about SVG. I need to learn more about React. How would you suggest going about that? I mean, we've always had, like, the on-chop talk show, even our intro theme song ends with this, like, we're at a conference. We have this slogan, where we ask people to go, and it's a three-word slogan, just build websites, so it's almost worth doing here. But we have the whole crowd go, just build websites, and it's awesome. It's part of the theme song now. But that's really kind of the advice, and I know that it's kind of a cop-up, but the idea is, well, how do I pick what to learn next? Have the project find you, or whatever it is you're working on, have that guide what you need to learn, Lex. I find it's very rare for me to just be like, I think I'm gonna dabble with Angular this weekend. I don't do that ever. That's never gonna happen. I might do that if I had a client who needed it, even though I don't do client work, or my team decided that we're gonna use that technology for that kind of thing, or I saw some demo of an SVG thing that I think I could put into our product somewhere that'd be cool, so I'm going to learn it because I have an end goal in mind. I think that's the way to do it. It is tricky, though, but if you really are just twiddling your thumbs, like, what technology should I learn? Let's say React. Thank you. This isn't a question, it's a comment, actually. Great. So I got into development through linguistics. I was working on a PhD in linguistics a while back when life sort of led me down a different path, but the point that I would say is like, when you say compound down, love it, right? That's great. However, it sounds like a grammar-nazi thing. Yeah, right. Where, you know, is it hyphenated, not hyphenated? When you work on Native American languages, like when you're putting lots of meanings into one thing and you want to say, well, this means that, this means that, it's really not the case. It's how you use it. So really, the question or the answer or the first person is like, how are you going to use it? And each time we use it, it's going to take on a little shade of its own meaning. Language evolves, kind of thing. And I say, unhyphenated, all around. Definitely. Forget hyphen. I'm pro hyphen because of CSS dash strict stuff.


Juliano Testa. Juliano is the surgical director of living donor liver transplant at Baylor University Medical Center. He was here for a number of years. I had the great opportunity to work with him as a colleague and great to welcome you back Juliano. Well first of all, Mark, thank you so much for the invitation. It's one of the highlights of my otherwise insignificant career to be part of the McLean family and to have trained with you. So this is really, really deeply appreciated. I feel better because usually in the past I've been the one who presented a little bit of a controversial issues. So thank you guys for starting with this. That makes everything else very, very easy. We are now thinking about transplanting anything that you may have related in your mind, especially the male mind to cosmetic surgery. So that's not the issue of this what we're discussing today. What the premise for whoever doesn't know where my ethical training has brought me is trying to understand from the guy on the field because I'm a transplant surgeon and I will always be a transplant surgeon. What are the issues that have to do with my profession and also try sometimes to counteract other great ethicists that speak about transplant but don't leave the profession like I do. So there is a little bit of bias in anything that I say and I do about my profession. And one of the things that you may not be aware of or you heard a lot is that the premise to everything that we speak about ethics in transplant is a simple demand and offer. There is a huge gap there and we can feel it. And no matter how much I study about that and no matter how I read about that, the gap is there and there is no solution to that. We've all the beautiful articles have been written and how we should do this and that. If you look at the curve of the donors in the United States coming from a disease source, that curve, that number has been steady and unchanged for the past probably 10 to 12 years. And so if you think about okay well let's do something what out there that can be replaced, there is nothing that will replace. At least now we are talking, when I was a fellow we were talking about doing a senior transplantation using animals organs for humans. Well I was told at that time that was around the corner and that was 20 years ago. So it's not materialized at all and I strongly believe that it will not really be materialized in the next 10 years. So the next one is going to be scaffolding which is using stem cells and growing organs and then putting them in an already pre-framed collagen, let's say, structure that will allow them the cells to grow and perform the action and function of the organs we are trying to replace. And that is also around the corner. Only that the corner is probably 5 or 10 years away. So for the next 10 years we are stuck with this issue and everything I think about when I think about ethics in transplantation is how we can do it in a way that it's good for everybody. And the reality is that the only source that we have that we can use is living donors. You can go around this as much as you want is living donors. The alternative would be to say that we stop placing patients on the list. And that would cause a little bit of ethical dilemma too because once you open the door to the 70 year old to get the kidney transplant or liver transplant or a heart transplant, I think Dick Cheney was close to his 70 when he got his heart transplant, it's hard to start saying, okay, let's put barriers. Let's say that certain people get the transplant, certain people get not the transplant, so the supply and demand will equal. You can do that. And even if you start to do that, then you have a problem of how ethically justifies something like that. So the bottom line, all this introduction is based on the fact that living donors seems to be the only options we have. And then for my point of view, how can we somewhat make sure that we understand that given the premise, how can we can work with the living donors and make them the source that they could be. And in my opinion, this has been an evolution in my thinking is that in the beginning I thought that living donors should be a second choice to disease donors. And the more I work in this field and the more I understand in reality should be the opposite. That the living donors should be the first choice. And disease donors should be the second choice. And although this seems very radical, the bottom line is we are the only profession in medicine that routinely offer a lesser quality treatment when another one is available. Because there is no disease organ that can be comparable in function and duration to a living organ donor. So this is a very intriguing point if you think a little bit about that. And then we are also the only profession, the only section of medicine that tells a patient that you have a problem, this is the treatment, get in line. It's very strange for a society that is used to have everything right away, well done in a perfect fashion and possibly at the top of the line. So this is the conundrum, this is the problem we live on. So having said that, this is what we have. I thought how can we make a living donor more, let me use this better and palatable to the professionals and the people who think that living donor is now a good choice, it shouldn't be the first choice. And it takes a lot of work around that. But I thought why, for example, there are other things we do in medicine that are fairly accepted by everybody. And nobody has really any problem with it. And then when we start touching upon living donors, any sort of medical concern comes about. And that is always a very interesting question for me. So I thought about cosmetic surgery because cosmetic surgery is performed everywhere. When I trained in the University of Chicago, we didn't do cosmetic surgery. Now cosmetic surgery is part of the activity, regular activity, daily activity of the department of university hospital like University of Chicago. It's not only the small plastic surgeon out there that does cosmetic surgery. So it's accepted by everybody. And yet this is an example, in my opinion, and it could be also the one of the sort of matter where somebody doesn't need the treatment but gets the treatment. Unless we believe that by becoming a cosmetic surgery patient, you live longer or something happens to you. Anyway, the difference that I saw is that while in cosmetic surgery is absolute autonomy, and I think very few could probably argue with this point, we are extremely paternalistic, me included, in approaching the living donation process and the living donors. So what is the problem with it? The problem is exactly going back to what I tried to say before. The problem is that by approaching the living donation with this premise, in a certain way, we use it in terms as a deterrent and we decrease the potential number of patients, the donors, not patients, the human beings that would like to step forward and become living donors. So the problem may be, while are you sure that we are being paternalistic when we approach the living donation? Well, I live with this every day and I think we are. I don't think there is probably any article on living donation, I saw probably a couple of them, one of them we were reading remark, that doesn't think that the donor is a vulnerable person. It's just in the mind of everybody. It's a diffuse feeling that we have to think about as a vulnerable person, to the point that the donor has to have an advocate. There is no other specialty medicine where you go to the doctor with an advocate, but we do that for living donation. And then we know that the donor must be protected from coercion and coercion is always the big word. As soon as you talk about living donation, the first reaction is coercion. And I can tell you that in the Western world, there are different connotation of coercion, but it's not as present, as daily seen, as you may think. And then there is also this approach that we have to protect the donor from his own desires and from his own action. And it's our job as physicians to do that, which is probably the epitome of paternalism. And then we scrutinize them. We scrutinize them in a way that's extremely personal. We go into their financial planning, the very heavy insurance plan, and their behaviors. And then we get in trouble of ourselves because we have to disclose eventually that the donor, for example, has practices that may harm the recipient. So this is another ethical problem that we get ourselves into. So how are they similar? Cosmetic surgery and living donation. Neither patient really needs the surgery. There is no curative intent, as far as we know, at least for the person involved himself in the surgery. But both of them may have a great deal of fulfillment. I think that whoever has worked with living donation knows that the donor usually is an incredible fulfillment by being a donor. Both of these surgeries have potential dangerous consequences, even lifelong or the life itself. And there may be an inner pressure in both for different reasons, of course. The living donor because of family issues, maybe, or the cosmetic surgery patient because she feels that she has to do something in order to be better accepted by society. How are they different then? If that's the premise, they have all these similarities. How are these two procedures different? The attitude is completely different. The attitude is that the living donor consider a vulnerable and the cosmetic surgery patient is not. Because otherwise, we would have another circus of physicians and donor advocate also, or cosmetic surgery advocates also for this part of the of the patient population. The premium nonocular concept is always evoked when we think about living donation. There are plenty of articles out there where in the introduction, premium nursery comes up as like we're doing something which we should be ashamed. And then the donor is, as I said, assign donor advocate, which serves to protect eventually the donor. There is a very, very lengthy social screening and behavioral screening. And I never understood where this is done to protect the donor or at the end of the day to protect the recipient because the two things sometimes kind of mingle. And then the motivation. This is something that I feel strongly about. We always question the motivation of the living donor always. And if by any chance the motivation of the living donor is not what we either by society or by because we are physician accept, then very often this donor is, this guy doesn't have it. This guy is going to get in trouble. This guy has some secondary intent. And then we of course, deny donation because that happens. Those are very good reason for denying donation. And then we offer them a cool enough period, which is like to say, are you really sure you want to do that? But I don't think we offer any cool enough period to anybody who wants to have cosmetic surgery, for example. In conclusion, I think we should have a little bit thought about this, that it should be a greater respect for the donor. I would advocate for a more balanced approach between the risks and the benefit, not denying the risk, but also not putting them in front and telling what the benefit of being a donor here. I would like to create a cultural donation, like we in a certain way we create a cultural beauty with cosmetic surgery. So instead of now ever have you ever heard about a national campaign, advocating living donation, never happened? Why not? When this should be really a good option for many, many patients. At the end, I believe everybody will benefit. Thank you for your attention.


Can you learn Python before learning HTML, C++, and Java? Yes. What's up, team? It is your biggest fan, the real Casadero, and I am here recording this video because Jamar from the YouTube channel, I hope I'm saying that right, X'd and the definitive of the answer is yes, you can. This is why I believe that yes, you can learn Python before learning HTML, C++, and Java is because those are all completely, totally different things. They are related only in the sense that they are all programming languages. Now, some people will say, HTML is not a programming language.  According to the laws of computer science, if there ever were such a thing, HTML falls within the definition of programming language. Some may not agree, but that's the way it is. Some people don't agree that a tomato should be a fruit, but by all the specifications that make a fruit a fruit, a tomato is a fruit because one of the specifications of being a fruit, like there is nothing that says a fruit has to be sweet. It just has to be whatever it is all the tomato has. When it comes to programming languages, different programming languages are used for different things, but only because of the way they evolve. In order to make this super simple, we're gonna go all the way back to the beginning. Now, I'm maybe not the best person to lay this out because it is difficult to explain these things without a white board or like diagrams and all this other stuff, but I'm gonna give it my best shot. But if at the end of this video, which will be in another... You are still confused. There's two places you can go on YouTube. One place is you can go over to Crash Course Computer Science. Computers really have allowed us to do some pretty amazing things. Don't call computers magical. They are not. I repeat, are not magical. Fantastic. It is probably the best, the best computer course I have ever taken. And it was all YouTube videos. Very well produced, very entertaining. There's some dope animations in there. I will watch it. The next place I will go is over to Socratica and look at their tutorial on Python and SQL. And I think maybe they have some stuff on PHP too. But the speaker, I don't know her name. She is very robotic and very entertaining. And if you've never used Python before or you're interested in Python or you're thinking about Python, she is gonna make you wanna learn Python because Python is dope. I can talk to machines. I code. But at the same time, every other computer language is dope. They allow us to make computers do stuff. This is all magic. These are just different spells we can use to do the same thing. This X-Man might use laser vision and this X-Man shoots the same lasers out of his. Same stuff, two different places. Computers, same stuff, computer languages. That's what they do. They just different ways to do sometimes the same stuff. With that being said, let's talk about the differences here. C plus plus was born from C. C was born from some other programming language, which was born from some programming language. And all of this stuff came from ones and zeros, which were possibly a representation of the base elements of the universe, right? But we don't need to go like all super deep and get crazy here. In the very beginning, we would have to write programs in ones and zeros. Like we would have punch cards, these little tapes, little holes in them and that's how we would make our programs. They had nothing to do with ones and zeros. I apologize. I'm just, I'm taking you guys all off the path. One, every, everything that happens on a computer boils down to essentially a yes and a no, right? And the ones and zeros make that easy because when you turn the power on, either the power's on or the power is off, right? So one is on, zero is off. This business is binary. Alive or dead. You're one or a zero. Alive or dead. Alive or dead. So to make it easier to tell computers to do stuff, we had to come over something else because writing a word using just ones and zeros would take forever. And if you wrote the word wrong, you would have to go back and figure out where you went wrong. So somebody came up with a way to make this easier, right? So there's a different language for that. You write something in this language. Some other program reads it and turns it into ones and zeros. The computer does this thing. And then somebody said, dude, that language is hard too. We'll make another language that's even easier to understand. And so now we have this other language, this language. Maybe it processes it to this other language. And that language processes it for the computer or maybe it just skips that stuff all together and bam, the computer does what it needs to do. This is where C came from in other programming languages.  For most people, I think this explanation will be good enough. If you wanna go build rockets and be a rocket scientist, you're looking at the wrong video. If you wanna build web applications, maybe you're in the right place. I'm not gonna write any code in this video. I'll write some code at some point. Or you can check out the code 365 startup lab, which has plenty of code there for you to learn, especially, well, maybe it's pretty much, if you're beginning, you know absolutely nothing. Check out the code 365 startup lab dot com. So every language was made to make building applications to make telling a computer to make giving a computer instructions easier. Where C shined is somebody wrote a book and it was a very well-written manual and it made it easy for people, regular people to come and learn this program. And it came along at the time that you could go out and buy a computer and sit it on your desk and it had a screen, you can install the software, you could read the book and you could build your own program, make your own game, make your own applications, do whatever it is you wanted to do. C++ came along to make that process even easier. And then there was some stuff that traditional programming languages did, things like allow you to put stuff in memory and take stuff out of memory. You had to manage all that stuff. C++ made it easier. So you got better syntax and you got an easier way to read programming. I mean, an easier way to type, to create the programs. After that, we get into interpreted languages. Now what these are, because let's step back, C is C++ applications, typically they will be run through a compiler. And what the compiler would do is compile that code down to ones and zeros to be ran on whatever processor the computer was on or to be run by whatever operating system that program was compiled on. So in order to run a program on a Mac, you have to write it on the Mac and compile it on the Mac. Well, you could write it on a Windows machine and then put it on the Mac, but you'd have to compile it. This would make it hard for regular people because every time you wanted to use a program, you would have to compile it. Not many people know how to do that. You gotta go get a compiler, you gotta do all this stuff. So somebody said, hey, what if you made something that ran everywhere? And that's where JavaScript came from. So now you got what's called the Java virtual machine, which is written to work on any operating system. And all it does is it takes in Java code and it spits out code for that particular operating system. So now I could write a program on Windows and it can run on Mac or Linux or wherever. The problem with that is, is that not all Java virtual machines were created equal and something may run fast on this computer and it wouldn't run fast on that computer. It doesn't even matter. Then someone decided that, hey, that stuff is too hard to understand and that's where Python came from. Python is a very easy to read language. Now, the reason why Python has become so popular, number one is very easy to read. Number two, it has fantastic documentation. Number three is self-documenting. So as you write the code, you have to do things in the code if you're writing Python the right way that makes it easier for other people to come and read. Really well-written programs in Python, they become their own book on how to use the program. So you're reading the code in the program and it's telling you how it does stuff. That's why Python is so popular. And because it's easy to read, you get scientists and you get doctors and engineers and all these people who do these things on a regular basis and as they learn Python, they're like, yo, I can make this thing that I can use over and over again. And so they make it and then they share it and it becomes a library. Then somebody takes a bunch of libraries together and they turn them into a framework and now you can use Python to do things like build websites and make games and make desktop applications. Now we get to HTML. HTML stands for hypertext markup language and all it means is that you write something in regular text and another program, typically a web browser, comes and reads that text and makes it display on the screen. Now, HTML in today's terms encompasses JavaScript and CSS so we can think of them all as one thing, HTML, CSS and JavaScript. Now PHP could have took this title. I don't know what happened, something went wrong, but hey, it is what it is. JavaScript makes it easy for you to write things for the browser, you can run things on the browser. Now we have node, you can run things on the server and basically you can do front, front end and back end with one programming language. And it is probably the highest level programming language you can get to. Well, not even the highest because we have other languages like Mocha which make JavaScript syntax super easy. There's probably some language out there that makes Python syntax easy. Like I hear go is like very easy to understand and write and read, but these are high level programming languages. You just write them, something else interprets them, they're very performant and so in that sense they operate just the same as Java. The difference is that the syntax is easier to write, it's easier to understand, it's easier to do stuff. Now again, some people are gonna argue and say, hey, Cas, this dude, he's messing this all up. All right, those people, leave a comment, tell me where your videos are. I wanna go and learn. The people who are watching me talk about this stuff, they wanna go and learn this stuff too. He just asked the question, can I learn Python first? Yes, you can. And maybe you should depending on what you wanna do. If you want to do math and you may wanna build web applications that utilize that math and you wanna build charts and graphs, you wanna crunch numbers, you wanna analyze data, Python's the way to go because data scientists, engineers, doctors, lawyers, all these really smart people have written libraries and frameworks that we can use to do just about anything we can imagine in Python. If you wanna build web applications, if you wanna build web games, if you wanna build stuff like that, then HTML, CSS, and JavaScript and even PHP. PHP is dope, it's super dope. But anyway, team, we're not here to talk about my love of PHP or my hatred. I don't have a hatred for anything, computers. I love computers to death, they're my best friend. But anyway, team, share, subscribe, like if you like this video, hit the thumbs up so YouTube knows that you guys still showing me some love. And the algorithm, the algorithm goes and shows other people these videos so they can learn too. But team, right, if you don't know computer science, never seen any of this stuff before, Crash Course Computer Science will bring you up to speed. Check out Socratica, look at the Python, SQL tutorials, their computer programming tutorials on Socratica on YouTube, Socratica, you'll find it. Or you can check out the code 365 startup lab and I've got like six or seven free courses there on code editors, HTML, CSS, very basic, simple introductory stuff, more courses coming. I just launched the Code 365 startup lab course course. And the very first part of the course is all about how to find clients and get paying clients and make some money so you can use that money to pay for the rest of your learning experience. But anyway, team, that is it. Thanks for hanging out with me here. I hope you got something out of this. I hope you learned something. I'm your biggest fan, the real Casadero.  Just gotta let it out team, just gotta let it out. Before you start doing these stuff, figure out what you wanna do. Figure out what you wanna build that will dictate the rest. If you wanna ask about what you should use, hey, leave a comment, hey, Cas, right? What language should I use to build this thing? I'll give you my input, I may be wrong. Maybe somebody on the channel will correct me. I'm babbling now, team. I'll see you guys next time, the real Casadero, your biggest fan.