Hi everyone, my name is Patrick Akil and for today's episode I had Kyle Cook on from WebDev Simplified. We go over his journey on how he started more on the backend side and moved his way to the frontend side and now teaching full-time through YouTube. We go over how to start when you want to start in programming as well as react and the future of the ecosystem there. I'll put all his socials in the description below. Check him out and with that being said, enjoy the episode.
Beyond coding 100% I mean like you said it's like anything like when I was learning how to program is like the exact same thing It was just like I would just always be building projects and eventually I just kind of learned how to program Did you because man I always had trouble figuring out which projects to build but you had no problem figuring out like little smaller Projects to work on I I don't want to say I had no problem I actually had the problem I had was the opposite of most people where I had like a thousand ideas of projects I wanted to build and I was like, okay. I want to build this. I want to build this. I want to build this And I realized I was like, okay, this is too advanced. This is too advanced.
This is too advanced. And usually what I would end up doing is building something I thought I could do, realize it was too advanced. And I was just like, screw it.
I'm just going to do it anyway. And I would usually get it like 80% of the way done and then start something else. Like I never finished anything. I got almost everything, you know, 80, 90% of the way there.
And then I would just jump to something else because it seemed more interesting at the time. Yeah. Yeah. And was it, I mean, I I'm assuming it was because you enjoyed it right now because you wanted to get like a portfolio and because of work.
I didn't even have an idea of a portfolio. Like I was in school. I was just like, I want to do this.
This is cool. This is cool. I like this.
I'm like, oh, I'm interested in this topic. I'm going to build a project based on that topic. And then when it came time to like make my portfolio, I was like, I have a lot of projects that are 80% complete. I got this very good on portfolios.
I was like, oh, I have like a back end built for this cool project, but that's not going to do anything on portfolio. Yeah, that's that's really admirable because I always was like, damn, I need I need a portfolio. I don't know what projects to build on. And when I'm like, OK, a cool project, let me write that down. I never actually got to it.
Yeah, I mean, I have a massive list of projects I never got to. Even now, like I'm, you know, doing YouTube stuff and I'm like, oh, you know, this would be a really cool project to like build out. But I'm like, when am I going to have time to do like all these cool project ideas on top of YouTube videos and all the other stuff? It's like I just don't have time for most of them. Yeah, I get that.
Because I was wondering, you actually started out with like a computer science background. Did I get that correct? Yeah, so I went to school. So originally I applied to school as a mechanical engineer because I was into engineering, math, science, that kind of stuff.
And then. my senior year of high school i took an underwater robotics class which is like the weirdest thing ever i moved to delaware my senior year from like the midwest so i moved to the coast and had this underwater robotics class i was like that sounds awesome i'm taking that and it was mostly mechanical engineering you know we're like building this robot but there was a one week section of the class where we did programming and we programmed on this like microchip kind of thing the programming language was literally called basic i think but it was like it wasn't like visual basic it was a different thing it was like basic but it was like a chip set language and it was very basic i mean it was super simple but i was super enthralled i was like wow this is the coolest thing ever i wrote like four lines of code and this robot moved like that's the coolest thing in the entire world yeah so as soon as that happened i switched my major before i even went to school i was like i'm doing computer engineering instead of mechanical engineering just still in that engineering mindset i would have done computer science if i knew but i went computer engineering because i was like this is so cool and yeah that's pretty much what started me on the programming path and then when i was in school you know i learned computer engineering which is a lot of hardware and not as much software as i would have liked you know i don't care at all about the hardware side of things but i spent a ton of time learning about it yeah but yeah web development was the thing that really sparked my interest in school so i just taught myself on the side i watched tons of youtube videos from like you know brad traversing people like that and just learned how to become a web developer mostly from school because or from online because there was only one class in my entire school that was web development based yeah and i couldn't take it until i think my senior year of college and at that point i'd already learned all the stuff the class taught me so it was like a complete waste of time because i was like oh this is this i've been doing this for years now yeah That's really cool. I've never, so most of the people I talk to don't have a traditional like software engineering background and even computer engineering is more adjacent to, I would say, a software engineering background.
It's more closer to that because you mentioned having web development in kind of a third year. But if you think about your educational journey, like there's a lot of it come to practice in what you do now, or is it just, it was just education and from then you moved on? Yeah, I would say that what I learned in school, like the first Year of my college degree was really useful cuz I learned like the fundamentals of programming like we learned to see in Java and like My first semester yeah And that was really useful and like teaching me just basic programming language concepts like for loops Conditional statements like all the things that every programming language has like that was really useful and kind of learning some of the back-end stuff of Like how memory works and stuff like that I mean, I don't really use much of that because I write mostly in JavaScript and you don't have to worry about that kind of Thing yeah, but just knowing about it was helpful But I would say every class after like the first year, if not even just the first semester, I felt was pretty much, I wouldn't want to say useless, but it wasn't that useful because a lot of it is like hardware based or it's going to be, you know, like things that I don't actually use in a day to day as like a web developer, because I feel like hardcore computer science, they focus a lot on like theory and they focus a lot on like algorithms and those kinds of things just don't come into play nearly as much when you're doing web development, especially front end web development.
So most of what I learned was from just using YouTube and blog articles and the actual school degree really only helped me with that like initial jumpstart I feel like but the rest of it especially with what I do on YouTube like I don't use any of it anymore exactly I mean I love that you taught yourself through YouTube and through all the like various free means that are out there right blog posts YouTube videos what else do we have I mean podcasts are there as well nowadays a lot more yeah podcasts are a big thing now like I didn't even know about podcasting back when I was learning it was mostly just like YouTube and lots and lots of blog articles that's pretty much how i learned mostly exactly it's like there's something distinct with this community that we just take everything we know and just put it out there for free for others to share and to build upon right and through that you kind of hone your skills as well and get better at your craft which is really cool yeah yeah go ahead oh no no no i was just gonna say like a lot of people don't realize how much you can learn for free i get asked all the time like oh what is the best course for x topic or is this course good is this course good and i always say like i don't know like when i learned I didn't buy a single course. I just did it all for free online. Like sure, I paid for school, which helped with some of it. But like I just learned it all online for free.
It's like you can learn all that you need to online as long as you have the time. That's like the biggest thing is you just need a lot of time to sift through everything. Yeah.
Yeah. I learned with that. Like there's a lot, especially nowadays, content is like there's a lot of quantity. You just have to find the quality in there.
Yeah, definitely. Coming out of university then or college, I don't know which one or even the distinction in the US. But getting into your first job, was it in web dev as well?
Or how did that go? Yeah, so the thing that actually got me into web development was, it kind of had to jump back to when I was in school. My sophomore year, I went to the career fair and I was looking for an internship. And I found an internship at a company and it was partially web development, partially like database related.
But we were doing like, I think we were coding in Visual Basic actually is what we were working in. So like not a super common language, but it was working on web development concepts. So like there's HTML, CSS, JavaScript.
and then Visual Basic for like the backend stuff. Yeah. And I really enjoyed that. And that's kind of what kickstarted me on the like front-end development, web development space.
And like, I learned a lot about CSS back then. Like I was super into CSS and that kind of stuff. Not as much the other stuff, but yeah, I was really into it.
So then when I was looking for jobs, I was really looking for jobs in that web development space. So I applied to like four or five jobs at the career fair when I went and I was like, okay, here's some local web development companies that I'd want to work at. And the job I ended up getting was actually working at Ruby on Rails.
So. They were in the web development space, but it was a little more back-end focused than front-end focused. And it was like an agency-style company.
And I ended up getting that job there, and I really enjoyed it. So straight out of college, I had a job in that back-end-ish. We did some front-end too, but it was a pretty back-end-heavy agency-style job. Yeah, very nice. I like, I mean, the company I joined through, I wouldn't call it an agency.
It was more of a consultancy. It's the company I'm in now, Xebia. But we had kind of an agency model in customers would come to us with kind of an idea.
or even a concept that they would like a product of or a proof of concept of. And we would help them through the ideation and the actual implementation in which I got to do a lot of kind of smaller projects, even longer term, but in a very short time period where I got to touch on a lot of different technologies and a lot of different languages and through that grow kind of exponentially, which is really cool. Yeah, that's something I really liked about like the agency experience. Like it's definitely not for everyone because it's kind of... a different experience but it's nice because you get to touch on a lot of different projects like i mostly worked on longer term projects like i would say when i was there i probably did like four different projects in the time i was there so like almost one project a year essentially yeah but it was just nice being able to jump between different things because it wasn't always like okay i was on one project for a year then another for a year like i would sometimes have two different projects going or so i could kind of swap between them where i'd have like one going for a while and then it would take a break because it was a seasonal based product and i would do something else and then come back to that seasonal project so it's kind of just nice to have variety even though it was in the same language like we always did ruby on rails it was just nice because even the same language you get a lot of differences between different projects and different you know products that you're building yeah it's interesting that you mentioned ruby on rails and kind of the role was more oriented towards back end even though there were like front end components in there as well because i sifted through your youtube and what you're doing now is mainly i mean more so uh front end focus right how was that transition So, so actually the main reason why I do mostly front end and JavaScript related content on my YouTube channel is because of when I was working in this company, I was doing, you know, mostly backend stuff, but we had front end stuff.
Like I would work in react a little bit. I would work in JavaScript and CSS. And those are the things that I enjoyed most when I was learning web development.
So I was like, you know what, when I'm going to make this programming, you know, YouTube channel, I could make a YouTube channel and cover Ruby on rails, which I'm pretty good at. Or I could, you know, dive into JavaScript and react and CSS, which I'm like not bad at, but I'm not amazing at those things. And I wanted to do those because those are the things that interested me the most.
And it was like, well, if I'm working on Ruby on Rails eight hours a day at my job, I don't really want to spend four hours when I get home making YouTube videos on it. I want to make YouTube videos on something else that's interesting to me. So I was like, OK, I'm going to do a lot of front end stuff. And people would even ask me to make Ruby on Rails content.
I'm like, I don't want to do that. I do that all day at work. I don't want to do it anymore. It's fun, but I can only do so much in one day.
So that's essentially why I do front end development on my channel and just kind of just grew from there. That's really cool. I love that you said no, no, no.
But that's. That's some work stuff right there. Here we're doing what I love.
But isn't it kind of scary? Because I mean, through that process, you were allowing yourself to grow and learn and kind of evaluate technologies in there as well. But you immediately put it out on YouTube, right?
For others to consume and to learn from as well. But if you're not like as confident, I was assuming that you were more confident in maybe the Ruby on Rails stuff versus the more front-end related stuff. You didn't have a problem like putting out any of the front-end stuff initially?
Yeah, so my front-end knowledge, like when I worked at my previous company as an intern, we did jQuery exclusively. I'm slightly embarrassed to admit I didn't even know there was a difference between jQuery and JavaScript because I was thrown in straight to jQuery. Like that was the first thing I learned before I learned any JavaScript. So I thought they were just kind of the same thing.
I thought like one was built on top of the other, like they were the same thing. I didn't realize until years later that there were different things. So it was a little bit intimidating for me to jump into, you know, building these JavaScript videos because I had a jQuery foundation, but I didn't have a solid JavaScript foundation. So I kind of had to learn a lot of those JavaScript skills, even though there's a lot of relation between jQuery and JavaScript, just building things out using pure JavaScript was kind of a challenge for me at first. And it was nice being able to do these videos, though, because I would kind of have to learn these topics, I would figure them all out, and then I could make a video on it.
And if you can make a video where you teach someone something, even if you just like write a blog article, anytime you teach someone something, you have to understand it really well. Because as you're teaching it to someone, they're going to have questions, or if you're like making a pre recorded video or blog article. you're going to think like, okay, they're probably going to ask why this thing happens or why this works this way.
And you need to know why that works that way in order to explain it. So you really need to learn something at like a fundamental level. Cause I could do super basic JavaScript stuff before, but I couldn't tell you why everything worked the way it did until I started making videos on it.
And I had to ask myself, okay, why does this work this way? People are going to ask that. I need to know why this works that way.
Yeah. I mean, that makes a lot of sense, right? You feel responsible in, in teaching in that way as well.
So when questions come. You don't just want to be like, well, I don't know. And then that's the end of it. You still want to be able to help them with the questions that they have then.
But just, and I think, sorry, go ahead. Oh, no, I was just gonna say, I think one of the most important concepts with teaching is not necessarily waiting for people to ask you questions, but thinking of the questions they're going to ask ahead of time. Because if you want to be an effective teacher, you need to know the like five most common questions someone's going to ask you. So when you're writing your content and making your content, you can already answer those questions before they even have a chance to answer or ask them to you. And that really, I think helps elevate.
whatever you're teaching and it helps elevate you because you have to learn those things yourself yeah that's a that's a great point actually i mean it doesn't matter in what you're teaching or even what you're presenting if you can figure out what the audience is going to ask anticipate and already answer that throughout your explanation and you're you're giving a great explanation then yeah that's why i think that people that are new to something not like completely fresh but people that are newer to something are better at explaining it than experts because An expert doesn't remember what the questions they asked when they were learning were. So they explain it in a way that they're like, oh, well, of course you already know what that means. I've known that for 20 years, you know, but most people don't know what that means right away.
So if you just learned something a week ago, you're probably better at explaining it to someone that's known it for months. Yeah, exactly right. If it's been something you've been doing year in, year out, I mean, it's kind of fitting in your routine, right? Things that might be obvious to you might not be obvious to someone that's new or fresh or just a starter in that way.
So you kind of obfuscate that in the way you communicate or the way you explain things. And then things don't make quite as much sense for you as it does to someone else. Yeah. One thing when I was learning, I found a lot of like, you know, YouTube channels and blog articles, they would use a lot of really big words.
And like, I could understand some of these big words because I had that computer engineering background. So they pounded big, complicated words into my mind for four years. But like a lot of people that are learning this on their own, they don't have a dictionary definition for all the crazy complex, you know, like.
you know words like memoization like what that just sounds like memorization spelled wrong you know like people don't know what that means so you have to be able to explain things in ways that are easy to understand for everyone not just people that have you know that strong background of jargon yeah yeah you're completely aligned with that I want to touch on what you said earlier in jQuery, JavaScript, and even Java. When I started out, I mean, I had some programming courses in university, but the one course that I had was web development, and it was teach yourself how to make this website you can pick from these designs and that sort of stuff. So I looked online, and everything kind of looks the same. And I was like, well, is this different? Is Java different from JavaScript than even jQuery?
What is that? Like teaching yourself how to do those things is really just... diving down the rabbit hole, trying out things and figuring out yourself what the differences are and when you use what and what was actually the distinction there.
I'd love to know if you were to go back or even if you were to start now with regards to teaching yourself, I mean, front end or back end, you can pick a language, but how would you start teaching yourself how to code if you were to start right now? I mean, obviously, I would just buy all of my own courses and watch all of my videos. Look at that, a small plug. No, seriously, what I would do is I would try to experiment with lots of different sectors because first I would do my research to figure out what are the fields in whatever case you care about.
Like, let's say you're interested in learning how to program, but you don't know what you want to do. Like, maybe you want to do web development, game development, desktop development. You don't really know.
So I would research what the different fields out there are. Try to figure out them. Just like watch some explainer videos.
There's a lot of them out there. And then think, okay, what are the things that most interest me? Like, oh, this one kind of sounds interesting or this one sounds interesting. Then I would dive a little deeper. Okay, figure out what that topic's all about.
Like, okay, I'm interested in web development or game development. Learn a little bit more about what those entail. Like, okay, web development, you're going to be using JavaScript at some point in your web development journey or CSS.
And game development, maybe Unity, like, is the most popular game engine. So you kind of get these ideas of what these tools are. And then just go ahead and start. learning the very basics of them and try to just build something see if you enjoy it like don't go super deep into it just like super basic game development project build like pong for example or build you know like a to-do list application something really basic and see is this something i even enjoy because you may get a year into learning web development only to realize you know what game development sounded more interesting to me i should i wish i knew that a year ago so if you just kind of experiment spend you know a month two months experimenting with like three or four different topics that really interest you figure out what you know you actually like doing and maybe you realize okay i like web development now you have to figure out do you want front end or back end and again do that experimentation phase and it may take you longer to get to the point of being proficient as a developer yeah but you're gonna know that you're in a field that you really enjoy because you may spend a year learning web development only to realize you really don't like it that much and that's a really like terrible feeling to think you wasted a year of your life on something you really don't even enjoy yeah i get that i like that you started with the domains right whether it's game development or web development or like even embedded stuff, stuff like that, IoT things.
It starts with that, right? Because you can jump into a technology and then figure out what you can do with that. But then you're very much technology focused and then the switch to a different technology is going to seem very daunting, right? Because you finally mastered or learned this technology, you became apt at it.
So starting with the domain and figuring out from there, okay, what do I then need to learn from a technical level to be proficient within this domain, right? To get this stuff done. But...
If I'm looking at myself and even my journey, it can be quite daunting, right? Let's say I want to start in the game industry or even web development. If I'm starting with a web page and I have to build in like a login form or even a to-do app, it can seem like quite a lot when you're starting out.
This kind of big thing and everything is kind of interrelated and everything is kind of has to make sense together. How do you make things small enough for you to actually be able to start and make progress in there as well? Yeah, so this is a great question.
Probably one of the biggest problems I find that people run into. You know, I teach a lot of people and a lot of them come to me. They're like, I don't know how to get started. Like I can follow along with every tutorial out there. But as soon as I build a project my own, it's just a blank text editor.
I just stare at it and I have no idea where to get started. Yeah. So I think the biggest thing is once you learn like the super basics programming, like, you know, variables, conditionals, like loops, like the basic building blocks of programming, you are comfortable. You can start building projects, but you don't know where to get started.
I recommend always starting with a really small project. If you think it's doable. make it 50% smaller because then it's actually probably going to be within your skill set. You always overestimate what you can do. But then on top of that, take this project, like let's say it is a to-do list application and break it down into every single component.
So like think if you're a user of this web application, what are the things that you can do? So on a to-do list application, you can add a to-do, you can check mark a to-do to say it's complete. You can delete a to-do, you can edit a to-do. So you have like these different ways that a user can interact with your web page and then think, okay.
I want to build out all these different interactions. What do I need? So for someone to enter to do I'm going to need to have an input box on my page. So already you have an input element you can add to your HTML page, you probably need a button so that they could submit that and create it.
And you're going to need some way to listen to when they create that. So you're going to need some type of form event listener to listen for when they create that to do item. So you kind of have like a checklist of different things you need to do in your mind.
And instead of immediately jumping in and starting to write code, I recommend writing out in like English pseudocode even what you think you need to do. So write out all these steps in English. And then from there, it's really easy to plug in the actual different code elements because you have in your mind, you're like, okay, I know what ifs are, I know what event listeners are, I know these different things. So you can just read your English and you can say, okay, I need a way to enter data. Boom, input element.
I need a way to listen for when they submit that data. Okay, I have an event listener for that. So you have all these different things that you can kind of connect to those English words, which are much easier than saying, okay, I want to create a to-do list application. Like that's super overwhelming, but I need to add an input element to my page.
Anyone can do that. Yeah, I really like that because... I mean, I think back to my own journey and when I started out, I would jump right in, right? Just write code, see what works, what doesn't work, trying to figure out how to make this thing happen on the fly.
And I mean, I started, especially my job here, actually, looking at my colleagues and how they approach things. Because they would have kind of a feature that I would be like, how the hell do you do this? Or I have no clue, like even starting out.
And they would write things on paper or they would kind of high over explain to me, okay, these things need to happen. And it wasn't even code. And I was like, okay, that does make sense, right?
Because if all of those things come together, then we do have this kind of added feature in that way. But that had nothing to do with coding in and of its own, right? That's just kind of structuring your thoughts in a way that makes sense chronologically and even being able to explain that to someone else for them to understand and then also to think it makes sense or even to kind of go back on things and discuss things. And then we implement because then the implementation is way more smooth. We have kind of a checklist of things we want to go through.
We do all of that and then it comes together. You have it. And that's, man, that was a shift in thinking, at least for me. Yeah.
Yeah, I 100% agree. Like, I think that learning to program is like two parts. There's the actual code, like learning, you know, ifs and for loops and those kinds of things. And then there's actually learning how to think like a developer, how to break down a big problem into a much smaller problem. That I think is.
The skill that a lot of people skip over, they're like, okay, I want to learn how to code. I'm going to learn the coding part, but they skip over all of the actual thinking part. And that's the part where they get stuck. They're like, okay, how do I build this project now? Because you never actually learned how to think like a developer and how to break these big problems down.
And if you can break them down, like you mentioned, it makes the implementation an absolute breeze because all you're doing is just taking all this knowledge in your brain and just barfing it out onto a page, following essentially a list of instructions. Yeah. I like, I like that you distinguish in, in thinking like a developer. But for me, what was really hard is when it actually clicked, when I saw the differences in thinking steps was always when I collaborated with someone else, right? Someone that was a bit more senior than me and was educating me and guiding me through that journey in there as well.
I think when you're starting out on your own, you very much focus on how do I get this done before you try and figure out your own thoughts. Or even most often, you don't even get feedback on your approach and how you did things rather than what you actually did. Mm hmm. Yeah, no, if you can find someone that is Even just a week ahead of you in like learning to program, I think that's a really important skill. I know it's not always possible to find someone, but if you can find someone that really helps with accelerating your learning process, because you can kind of, you know, jump ideas off them, be like, hey, does this make sense?
Does this make sense? But even if you can't find that, the idea of rubber ducking, which is essentially where you just talk to a rubber duck or to like a stuffed teddy bear or to the wall or to yourself, and just explain the problem you're having. A lot of times just the idea of verbally explaining what you're trying to do.
you can already see what the issue is that you're running into. Like if you don't know how to implement something, explain what the different steps of the problem are. And a lot of times that'll enlighten you on what the actual problem you're running into is.
So I recommend doing that a lot for people that are stuck on something, just write it down or speak to it with someone or just nothing, speak to yourself. And a lot of times that'll actually fix the problem for you. Yeah, it's an interesting thing in a lot of things are in your head, right? And they can be very unstructured. So for you to be able to communicate that to either someone else or...
in your case, a rubber duck or yourself, it doesn't even matter. The act of structuring your inner thoughts and being able to externalize them, right, writing them down or communicating them verbally, it helps with your thinking process. And all of a sudden it will click and you will figure out kind of what the next step or the missing piece is there.
Yeah, when I when I worked at my last company, it was a small company. So like it was just me and my boss are the only two that worked in the office where I worked. And there'd be many times where he'd be like, hey, Kyle, can you come over here for a second? So I'd walk over. And he'd be like, I got a question on, you know, X, Y, and Z technology.
I'm like, I've never used this before. I don't know anything about this. He's like, I don't care.
You're just a rubber duck right now. I just need to like talk to someone and have like just some feedback. I just need to talk this out.
And like, it's easier when there's someone there. I was like, okay, that's cool. I can do that. I can listen and not know anything. And half the time he'd be talking to me and all of a sudden, like mid sentence, he'd be like, okay, I got it.
And that would be it, you know? So it was just kind of funny to think that, you know, you can talk to someone that literally knows nothing about what you're trying to do. And that may solve the problem for you. Yeah. Yeah.
There's a funny word in Dutch, which. I haven't really found the right translation. It's called Sparta, and it's similar to sparring in kind of a boxing ring.
But you do that when you just need to kind of mirror information to someone, either rubber ducking or for them to actually also give you feedback in that way, for you to structure your thoughts, right? And it doesn't have to be related to programming. It can be something that happened in real life that you just want to spar about. I still don't know the right translation, but we use that very often.
Nice. Yeah, for sure. I lost my train of thought, actually, because... We started out kind of Ruby on Rails and you went to YouTube when you wanted to teach yourself or even educate others with regards to front-end technologies, but when did you actually decide to do YouTube full-time?
Like, did it just take off and you were like, oh yeah, this is my thing. We're going to do this full-time. When did that happen?
That's a good question. So it's kind of two parts. It almost happened at the very start and at the very end, it kind of took off. So when I started the YouTube channel, I in a hundred percent intentionally was like, okay, I want to make this a business that eventually I can do as a full-time job.
So in order to come up with my channel name, actually, this is kind of a funny story. I was like, I want to have a.com domain name associated with my channel name. So instead of just creating a YouTube channel name and having it, whatever it was, I went to like, you know, some domain website. I was just typing in different things that sounded interesting.
I was like, web dev, web dev, easy, web dev, this web dev, whatever. you know, development, whatever it was, because I knew I wanted it to be web development based. And finally I landed on web dev simplified.
I was like, okay, that domain is not taken. It doesn't cost me a million dollars. Like every other domain, every other one. Yeah. So I was like, okay, that's what I'm going to do.
So that's the entire reason my channel is called web dev simplified because I was like, it makes sense because my goal is to kind of like make things simple and easy to understand. So like I was already kind of on that like terminology, but as soon as I found that domain name wasn't taken and it only costs like $10, I was like, okay, bye. That's exactly what I want.
Named my channel literally same day after I bought it. And just the act of. buying the domain name i mean it was literally like ten dollars but the act of putting down money it made me more serious about the project because i probably would have at some point quit but having that ten dollars i put down i was like okay i'm actually dedicated to doing this yeah and that really helped push me through like the beginning stages because the beginning is so hard because you don't know anything it takes forever to build a video you release a video and one person watches it and they downvote it and tell you you suck it's like it's super demoralized so hard beginning yeah so that putting that ten dollars down really helped because i was like okay i've put some skin in the game even though it's only ten dollars like my blizzard brain was like i've put something into this i need to contribute to it yeah and then from there it started to slowly grow you know and after about a year i think i was at about 10 000 subscribers so it was pretty good growth for a year and uh i had a little bit of you know spikes around that time and then the big thing was when covet hit a lot of people you know they were at home they had more time at home they had either lost their job or they were worried about losing their job So a lot of people came to YouTube for entertainment, but also a lot of people came to YouTube to learn a new skill, a skill that could be used for a remote job.
And probably the easiest and best skill to learn for that is, you know, web development of some form. So I saw a huge growth in my channel around that time, you know, that April, March time period. I think it was around 2020 when all that started and it started to continue to grow.
And I was already at a point where I was thinking about quitting my job because I was like, OK, I can kind of see this starting to. It doesn't overtake my income, but I can see eventually maybe a year or two from now, this would overtake my full-time income at my job. So I was like already on the fence of thinking about quitting.
And then COVID came and my YouTube channel started skyrocketing even more than before. So I told my boss, I was like, Hey, how would you feel about me going part-time? I was like, I want to go part-time for a few months, see if this continues to go. And then maybe I'll quit.
He's like, yeah, that's fine. We'll support you. Like they were very supportive. So like, yeah, that's a hundred percent cool.
So I went part-time. And I was able to even keep like my health benefits and stuff. It was super useful, but I was only working like 20 hours a week. So I could dedicate a lot of time on YouTube. And within just one month of being part-time, I realized I was like, okay, this is way better.
I need to do this full-time. So I told my boss, I was like, Hey, I know I told you I'd be here for a few months part-time, but like, I think I need to be done at the end of this month. Like I don't want to miss this opportunity.
So I was like, I'm quitting. And I think it was July, 2020 when I quit. So it was, yeah, the very end of June.
So it started July. So almost exactly two years after I started my channel, I quit, went full-time and yeah. I wasn't making my full-time income.
Like I wasn't making the same amount I was at my full-time job, but I saw the potential. Like I was like, okay, I think this can, you know, even overtake my full-time job. So I need to jump on this now before, you know, the opportunity passes me. That's awesome, man. That's really cool.
I love the little start, the little investment that was also a huge investment in your mind. You were like, I already invested. Like we have to make this through or we have to actually start, right? Because I think starting in most cases is the biggest obstacle you have.
Once you get the ball rolling, once you kind of... found your routine, found your rhythm, that is good, right? Then you're like, okay, we have these kinds of things, X amount of things.
I already have thoughts aligned. I know how to make the video. I know how to structure it, edit it. I actually have consistency in the days that I upload. So then you have a rhythm, but the hardest thing I think still starting and actually doing things.
Yeah. Yeah. I think another thing that really helps, this is for any skill, you know, starting a YouTube channel, starting anything, even just learning to code. is have some people that depend on you one thing that really helped me was i was part of a discord channel for game development actually at the time but there's a few people on there that were interested in learning web development they'd ask me questions because they knew i was you know skilled in that department so i started making videos and i was like hey why don't you guys check out these videos there's like five people or whatever so i'd be able to get like five views on these videos and you know these people were like oh you know that's you know it's really helped i really like that i'm looking forward to the next one and just having that commitment where these people were like actually looking forward even though it was only a couple people looking forward to a new video It really helped motivate me because I was like, oh man, it's been like two weeks since my last video. These people are really hoping for a new video.
Like I really need to get in there and just grind through. Like I remember one of the first videos I did, it was maybe like, I don't know. And within the first 10 videos I did, it was the first video I ever did that did well.
I was just, it was a get tutorial and I was just grinding through this video. I think it was like one or two in the morning when I finished the video because the editing process took so long. And I just posted that video.
I went to bed. The nice thing was that my job had a flexible hour. So I was like, I am sleeping in tomorrow.
I don't normally stay up that late. And I went to bed and the next morning I woke up and I looked at my phone to see how the video did. It had 9,000 views.
And I was like, my previous best video was like eight views. So I was like, what the heck? This is insane. So that really helped motivate me too.
Like I got a decent number of subscribers, like maybe a hundred subscribers off of it, but they never came back and watched another video essentially. But like just that little bit of motivation, like the fact that I was motivated to help these individual people, let me to grind, you know, into 2am to make this video. And then that video ended up doing really well, which helped motivate me further.
So just, it's kind of like a snowball effect at that point. Yeah. Yeah, I mean, I've heard this as well.
Ken G said it. He came on my podcast and he says... like motivation is pretty fickle and it depends on the person but once you feel responsible also for others and others expect something of you that can be one of the biggest motivators you can find right because you feel accountable you feel responsible not just for yourself because i mean letting yourself down is way easier than letting others down so eventually you'll deliver and you find your way into that and that yeah i think that always stuck with me yeah but really cool man i i wonder if you've seen this as well because When I started out in web development, I mean, that was when, like, at a university and we did a lot of PHP, not so much even JavaScript, but HTML and CSS as well. Then I did mostly backend stuff, actually almost exclusively, a little bit of Vue because that was the framework we used.
But then I came into a role and it was almost completely React. And I didn't actually start off understanding JavaScript until after I did most of the React components and React functionality and stuff like that. Because React was just a bit easier to understand and I didn't really have to figure out what happens under the hood. And I did enjoy it because it was component structure. A lot of things made sense kind of conceptually in my head.
I can understand how things fit together and you have some functionality here and there. So I never actually bothered with vanilla JavaScript until just recently where I have a project which is a lot of static HTML templates go as a backend and go HTML and then just vanilla JavaScript over there when we need it. But I think a lot of people start out with a framework, whether it's Vue, whether it's even Angular or mostly React is what I've seen.
I think they start out with that because I think, I don't know, it might be easier. What's your take on that? Yeah, I think a lot of people start with something like React because they see that jobs out there are all looking for React. They're like, OK, if I want a job, I need to learn React. And then they also see that like all these YouTube videos coming out are on React.
Everybody's talking about React. Everybody's doing React projects. Like it just seems like React is the way to go.
And I think even some people don't even realize like how much it's built on JavaScript. So they just kind of jump into React or maybe they'll learn a little bit of JavaScript. They're like, OK, I learned the basics. Now I'm jumping into React because I want to be able to do cool real world things. You know, playing JavaScript is just the thing of the past.
You know, it's like kind of like the jQuery of today. It's like, oh, jQuery is a thing of the past. People think JavaScript's a thing of the past because React is replacing it. But I think it's really important that you understand the core of JavaScript. Like I tell everyone that's trying to learn React or take my React course.
I was like, I have a list of JavaScript concepts. I was like, you need to learn. all of these concepts before you even bother with react because it's going to make your life so much easier it's not a hard list i mean it'll probably take you a month two months to learn through all these different concepts but then when you go to learn react react is going to be a breeze because a lot of people that get tripped up and react get tripped up on javascript concepts not react concepts they're like oh what is this import export stuff or why is it when you pass you know arrow function to a component you like on click event like they kind of aren't really sure how passing functions work so they get confused by that kind of thing like passing by reference versus value versus calling the function versus just passing the name of the function those kinds of things trip up a lot of people that don't learn the fundamentals of JavaScript first so I'm just like learn these fundamentals it's gonna take you a month or two it's probably not gonna be the most fun thing in the world because fundamentals always suck yeah when you go to learn react instead of taking four months to learn react it'll take you one month to learn react because you're gonna know all the JavaScript stuff All you need to learn is the React stuff. And React is pretty small, you know, comparatively to JavaScript.
Yeah, exactly. I also had to backtrack because I was like, this doesn't make sense. And then when I actually figured out how to do it, I was like, none of this stuff is React-based.
Like, these are more fundamental things that I just didn't know. And I learned on the fly, you can do that as well. But when you start out with a foundational base, it makes adding on top of that, I think, a lot easier. Just haven't really, that wasn't my journey.
Yeah, no, I've always found that learning something on the fly, it's fun because you get to start building stuff immediately. Yeah. But I find, and it may seem really fast at first because you're like, oh man, I got this to-do list already. Like, this is crazy. If I spent two months learning JavaScript, I would not have this by now.
Yeah. But then as you go, as the time compounds that you still keep skipping these fundamentals, you start to realize that, okay, things are starting to take me longer than everyone around me. Like, why is that? I feel like I have a good understanding of this, but you're lacking those fundamentals. It's kind of the same thing about learning an instrument that we talked about earlier.
It's like... If you're trying to learn an instrument to be able to play, you know, music, you can skip the fundamentals and go straight into playing songs. And you're going to start to learn songs quicker than if you started with the fundamentals.
You're going to struggle with certain things because you don't have those fundamental skills in place. So if you learn those fundamentals first and then start going to learning songs, you'll be able to learn those songs faster. I think it's the exact same thing with, you know, learning concepts versus learning how to build projects.
Yeah. Yeah, that's a great example. It's very similar to that.
And even that. was kind of relatable to my own experience where i was like okay i get a lot of things done right and that is so satisfying getting the thing done that you need done except when you're a bit slower than other people and other people are like why why is this guy taking so slow or what's wrong here or even internally i'm like okay this should be simple yet i can't figure out this small thing and sure i can google it here and there but at some point i'm like i've googled this so many times that i should actually like figure out how this works before continuing because this is something foundational this is something recurring and this is something that's lacking in my current skill set so then you figure it out i think and you uh i think the oh sorry continue no no go ahead i was gonna say i think the thing that a lot of people run into is like it's fine to do this kind of stuff where you learn on the fly and you're just like experimenting with things but after you're done with the experimenting go back and think what did i struggle with what did i not really understand like you maybe looked at the code you copied it from stack overflow and it worked but why did it work try to ask yourself why and if you can't answer Go back and try to learn that thing. And it may take a little longer at first, but by doing that, it'll make your future projects better. So you can kind of get the best of both worlds where you can start with building something complex.
And when you run into an issue where you don't understand why something works, just look it up after the fact or look it up later. And that's going to really help build your concept-based skills as well as you'll be able to build projects. Yeah, I love that.
I'd love to touch on stuff that's a bit more, I don't know, like more advanced, maybe in React specifically. Because when you got the basics down, what do people struggle with next? Is it more like, getting your components to render as efficiently as possible or state management or even kind of lazy loading your stuff what what do you think are more advanced topics that people kind of struggle with yeah i think some of the more advanced concepts people struggle with is just the conceptual model of react so react is very declarative while you know learning normal javascript is not at all declarative so kind of switching your mindset from this imperative mindset to a declarative mindset where you realize like okay when i change state it's going to re-render my component And I don't have access to that new state until after my component rerenders and like how the use effect hook is going to work within all of these different state updates and like how the component lifecycle works. These things I think are confusing for a lot of people because when you learn normal JavaScript, those are not concepts you learn.
You don't care about declarative stuff. Everything's imperative. Like you have an event listener. When you click on it, it fires this function and then you change the variables and then you have to manually update everything.
While with React, you change your state and then everything reruns again all the way from the top, which is 100% different than how normal JavaScript works. So I think rewiring your brain in that way is what a lot of people struggle with. Because I find when I get asked questions a lot, it's like, hey, I updated the state variable and I tried to use it after that and it didn't update.
And it's like, well, you had to wait for your component to re-render. Or they look at their use effect and they're like, why is my use effect not working? Oh, you forgot this dependency because, you know, when this thing changed, you need to make sure you account for that. So I think these are not quite like super advanced concepts. It's more like that intermediate level.
Like you understand React, but you don't understand why everything's working. I think those are the biggest problems people run into. Yeah, I get that.
I get that as well. I've seen a lot of stuff. I mean, a lot of stuff is evolving very fast, especially in the JavaScript ecosystem, but also in the React ecosystem. I've played around with Gatsby and I've even done some Next.js stuff as well. What's your take on the frameworks that are popping up and that are kind of using elements of React to kind of enhance their own structure in there as well?
I think they're great, honestly. Like my blog article, I used to have it written. Using Gatsby.
I ended up switching over to Astro eventually because I had some problems with Gatsby that just wasn't working Right. I don't know if it was a me problem or a Gatsby problem. I just was like I'm switching to Astro I don't really care if you're this out.
I spent too long trying to figure it out But like things like next.js and there's even frameworks like Redwood and blitz I think those are react based as well or maybe their own amogu Applation of things but like I really like this because it takes away some of the hard stuff of react like Server-side rendering and page routing those kind of things just aren't fun to do and they're very difficult to do sometimes So having these frameworks like Next.js that just take care of all that for you, I think is really useful. And they're not so prescriptive like a Ruby on Rails where it's like you must do it this way. They're very open-ended like React is.
But they just give you a few extra guide rails that make those decisions and those boilerplate code things a little bit easier to work with. Yeah, I agree. I really enjoyed Gatsby when it worked.
And then I think, I mean, we used images that were a bit too big. And then we had a plugin that kind of reformatted all the images. And then all of a sudden our build took way too long. and our Netlify build didn't take it anymore and yet then it wasn't fun anymore but when it works it's great and I mean I love using it additionally with either Verso or Netlify so even deploying your thing and giving it to users in the end makes it so much easier and I love that we're getting more and more tools that make things simpler. I just wonder where it goes is it eventually going to be one framework or are we always going to have choices and kind of opinionated frameworks and you get to pick and choose from there?
And is it going to be, I mean, we have React, we have Vue, Angular, and even, I don't know, Svelte is also there kind of popping up here and there. There's one every day, I'm sure, at least. So I just don't know where it's going.
I'd love to have your take on that as well. I personally feel like it'll kind of end up like the Vue React front-end framework space where there's going to be maybe one that's probably more popular than the rest. Like right now, I would say Next.js is kind of that one where it's like, it kind of does.
everything well enough and it's it's probably the most popular one out there yeah and then i think there's going to be other options that are a little bit more specialized like astro or gatsby they're more specialized in what they do like they're more focused on building out like statically rendered pages like they can do other things but i'd say that's where they're specialized in yeah And then on top of that, there's going to be even further things. So like Next.js is kind of like built on top of React. And then there's going to be things like Blitz and Redwood that are going to be built on Next.js or like the next version of Next.js. The things that really take it to the next step where it's like, OK, we've thought of all the things for you.
We're going to give you an opinionated way to do things. I think that's actually the way that JavaScript is going to go, because a lot of people are fed up with having to make all the decisions themselves. They're like, why does React not have routing built in? Why does it not have this built in?
Like, why do I need to include all these libraries? I think people are getting to the point where they're like, OK. I just want to use Next.js or I just want to use Blitz and it's going to just do all of this for me and I can just write my code and not worry about thinking about which one of the 74 different libraries am I going to use. Yeah, I like that.
I mean, it's part of why I'm a fan of Go because it's a language and all of the things are in that language that I usually would use. I really have to think of when I introduce a dependency because a lot of things are already implemented through that. I can make APIs, I can make my services, I can hook my front end to it. I can even do a lot of static HTML templating.
I now have a stack where it's exactly like that. A lot of backend static HTML templates, a little bit of vanilla JavaScript in there, and Buma as a CSS framework. And it runs like a train.
Like it does exactly what it needs to, and it's super performant. And everything kind of comes out of the box. But JavaScript in and of itself wasn't quite like that. React took it one step further, and still on top of that we're building.
And now we have Next.js, and still on top of that we're building. So I like the thought of, Just getting the technology that is a tool and having enough tools in that toolbox or the technology that is a toolbox and having enough tools in that toolbox to do whatever you need to with regards to web development or pick a toolbox that is kind of apt for whatever you need to do, whether it's building an e-commerce or even building some other thing. I like having a toolbox that's kind of various enough and I don't have to keep trying to figure out which tool.
fits in here and which one is maintained still and which one can i use and which one is not gonna like break my shins on the long run yeah no i i honestly think that the future is going to be like a ruby on rails style javascript framework i think something like that is going to happen like we're already starting to see that with like blitz and redwood they're kind of like pushing themselves towards that territory and i think if something like that becomes good enough that it's usable by people, like, you know, becomes 1.0 and it's got a lot of features. I think that could be the next big thing that really like takes over next. It doesn't maybe take it over, but it's like, you know, another option besides next where it's like, Hey, do you have, you know, just a basic CRUD application?
Like everybody else's building use this framework because it's going to make it so easy. That was my favorite thing about Ruby on rails. It's like, if you're building just a basic CRUD application, which is 90% of applications, like it's so easy and so quick.
And I think if we get something like that for the front end as well with JavaScript and react, it's going to be a game changer. Yeah. Yeah.
I agree. I'd love to know your take on full stack development as well as kind of a final touch because you've done both back end as well as front end and for me coming out from a kind of a same journey as you I dove into the front end and it was more as like a sink or swim I guess because I actually needed to deliver stuff and teach myself on the fly as well but in there I was like man people that really have a good understanding of both concepts right a lot of things back end related and a lot of things front end related those are rare usually i find people that can make stuff happen on the front end or can make stuff happen on the back end uh and and are really apt on the other side but what i see on the market is a lot of people also ask for that full stack role or even full stack with devops experience or even taking a step further and knowing a lot about cloud and security and even test development and everything like that like it's a whole package and i get that if javascript and and react and the frameworks that we use are simpler and things are a bit more established and opinionated, then you don't really have as much choices anymore. So it kind of becomes more tangible and things are still within your grasp when you want to be effective.
But as it is now, I think it's a big ask sometimes to allow people or to ask from people to be apt in a lot of technologies. And I feel like sometimes we even keep asking more on top of that, right? Because companies also ask for years of experience, both in the front end, both in the back end.
for technologies that are for example years old and they ask for 10 years of experience in that technology it's a bit ridiculous sometimes how that comes across because is a full stack developer still like a realistic thing in your take What are your thoughts on that? Yeah. So I would say if you asked me this question like five, 10 years ago, I'd say, yeah, it's a reasonable thing to ask because your project is going to have a focus in one way or the other. Most projects are either going to be more complex in the front end or more complex in the back end, unless you get to like the scale of like Facebook where it's complex everywhere.
But at that point, you don't have full stack engineers. You have hundreds of each part. You know, you have hundreds of front and hundreds of back end developers. You don't have to worry about front end or full stack engineers.
But on most of the projects that aren't massive projects, I feel like. five ten years ago it was 100 possible because you could be specialized in one area and you could have enough knowledge in the other area to get the you know thing done but i think now the front end has gotten a lot more complex than it used to be it used to just be javascript html css now you have react now you got next.js which pushes you even into the back end a little bit you have view you have svelte you have all these different frameworks and they keep getting more and more complex i think it's harder and harder for someone to be specialized like in the back end with enough front end knowledge to get things done as these more complex frameworks come out it's definitely possible But I think if you're a company, you'd be better off hiring a dedicated backend and a dedicated frontend developer than hiring, you know, one full stack developer to try to take both those roles, because they're going to be better at one versus the other. And they're just going to lack in that one department, you can't be an expert in both, because it takes so long to learn all the skills needed. And even if you become an expert in backend and an expert in frontend, five years from now, whichever one you do more, you're going to become an expert in and then things in the other department are going to change, especially if you, you know, lack on frontend, it's going to be way different in five years than it is now. So like, You're no longer to become an expert in that area because you spent more time on one specialty than the other.
I think it's important for people to have an understanding of both backend and frontend if possible. It makes you a more valuable developer because you can understand if you're a frontend developer what the struggles of the backend are and what is and is not possible. You don't need to be an expert. You don't need to be the person doing both the frontend and the backend.
Yeah, I agree. I like being apt at both to a point where I can be effective, right? and if our if our front end guy that's really specialized and knows a lot about the front-end ecosystem is gone we can still continue as a team right because we fill those gaps in that way but if it comes to making our front-end application very performant or the bundle size a lot smaller with a lot of tree shaking and different package management things in there as well i would love someone that's specialized in that because that right now is not really what i'm what i'm comfortable in but that's also where a team comes in right where you have those specialities and they come together And you can make decisions as a team because in the end, I think you're also responsible and accountable as a team for the end result, right? So if you can align on your specialties in that way or kind of fill those gaps rather, I think you can be very effective in a way. Yeah, I agree.
Like when I worked at the agency, some of the projects I worked on were smaller projects. So I may be the only developer on that project. So I had to fill both the back end and the front end role and even sometimes the DevOps role, which I would.
always try my best to push off on someone because i hate that section of hype come on i'm so bad at it like terraform config files are the worst thing i've ever seen in my entire life like i was like oh i almost want to quit now just doing the terraform but like i feel like if you're on a small team like that and you're working on a smaller project where it's small enough you can be one developer it's probably fine if you do both the back end and the front end it's not going to be perfect in either section but it's going to be good enough and if you're the only developer it probably doesn't matter as much because the project is probably going to be small enough It's okay if it's not 100% performant on the back end or 100% performant on the front end. But once you start to scale up beyond that kind of level, I think it's really important that you go and you become, you know, proficient in just one of those sectors, which is why if you learn only front end development, you can still find a job. Even if places are asking for a full stack developer, I think they're trying to find something that doesn't exist. And they'll kind of realize if they hire someone as a full stack developer, that they're actually just, you know, a front end developer with some back end knowledge or a back end developer with some front end knowledge and not a full, full stack developer. Yeah.
Yeah, I like that. I mean, the key thing there is you can get it working on a smaller scale, but once you want to scale to, I mean, just throw a number out there, hundreds of thousands of users, millions of users, multitudes of millions of users, then it becomes a lot more preferable that you have people that are specialized in optimizing things, right? Whether it's front end or back end or more of the DevOps side of things as well, your platform and your infrastructure. It makes more sense because those smaller optimizations, those smaller efficiencies will have huge effects on your actual applications or your actual user experience in that way as well.
And that is, in the end, what you want to optimize. So optimizing your technology through that will optimize your user experience. And that's, I mean, that's what we're doing it for, right? For the people that love using whatever we're building.
Yeah, 100%. Like, I think people focus too much on performance when the scale is small and not enough when the scale is large. Like, when you're only serving 100 people, you don't need to have Facebook levels of performance. It doesn't matter if it takes them a little bit of time to access your website because it's so small, it's probably not going to make a big impact. But when you have a million people accessing your website every day, like, every millisecond of performance is going to make a huge difference on, like, your server cost and your server load and the experience for the user.
Like, even if you can shave 10 milliseconds off a million requests. That's a huge amount of server costs that you're saving because you don't have to make those 10 million or what is it 100 million milliseconds? Like that's a lot of time.
I don't want to do the math, but that's a lot of money you could be saving. And also your users are going to see that difference. Yeah. Yeah, I completely align with that. I really enjoyed this conversation.
Kyle, is there anything you still want to share in there? I would say if you're just starting out learning, don't focus and worry too much about, you know, the technologies and things like that. Learn, you know, the concepts, like programming concepts, how to think like a programmer. Those are the skills that you can transfer anywhere. It doesn't matter if you learn React, JavaScript, Angular, backend stuff, game development.
If you understand how to think like a developer and you understand the different programming concepts. those are transferable between every language and between any different specialty so learning those skills is the most important i think and most people flip it where they think that those are less important than learning how to actually code yeah yeah i completely agree with that as well cool thanks everyone we're gonna round it off here call cook web dev simplified i'm gonna put all his links in the description below check him out let him know you came from our show and with that being said thanks for listening we'll see on the next one