YouTube Deep Summary

## Skipping the Fundamentals [00:00] 10 programming mistakes that'll ruin your life. Okay, I'm being a little dramatic. Number one, skipping the fundamentals. Wait, is this for real? People do this. Please don't skip the fundamentals. Look, I get it. You want to learn how to code, be a cool kid, automate your life, get rich or be homeless, replace humans with AI, make goofy looking games, whatever. But if you don't understand the fundamentals like variables, loops, and functions, and a lot of other stuff that I uh can't seem to remember, uh you're trying to run before you can even crawl. Damn. How do I know? Because I did that. Yeah. Wait, is this for real? People do this. Hi. If you're new to the channel, I'm a terrible programmer. Now, here's what actually happens when you skip the fundamentals. You end up copy and pasting code from AI without understanding what it does. And then when something breaks, and it will break, you're completely lost. And not only does it mess up your learning, it could also affect your career. You're going to become that developer who gets exposed in a technical interview when they ask you to explain a simple concept. Now, I'm not going to lie to you. The fundamentals are pretty boring to learn. You don't get to build the cool fancy stuff. You got to stick to the boring stuff. But it is very, very important. Once you survive the boring stuff, you'll be able to create the cool things way faster and it'll be way more enjoyable because you actually know what you're doing sometimes. So, please learn these concepts. And if you don't, then just put my fries in the back. Number ## Writing Clever Code [01:16] two, writing clever code over readable code. This one's mainly inspired by those leak code gods who drop oneline Python solutions in the forums because what are these? And you know what? I respect it. These people are definitely geniuses, but I'm not. These answers look like they're speaking Minecraft Enchantment Table to me, and I love the people that post these, but bro, please. Your solutions have given me more brain damage than the actual lead code problem. I mean, yeah, these oneliners are cool and all, but please never ever write code like that in an interview or in an actual codebase. Your interviewer is not going to stand up, slow clap, and make you the CEO. They're just going to stare at your code like you just committed a war crime. If it takes an entire YAP session to explain your code, it might be too clever. Unless the code has crazy performance benefits and it can't be rewritten in a readable way, there is zero reason to make your code look like a cross word puzzle. Oh, and by the way, if you're interested in programming and you want to learn more tips and tricks, you should check out my ## Sloth Bites [02:12] newsletter, Sloth Bites. Oh, you don't know what Sloth Bites is? Sloth Bites is my weekly newsletter where I share byite-size programming information every week to make you a better programmer. And the best part about it, it's free. All you have to do is give me your email. I won't do anything with it. I promise. Number three, being afraid to break things. You know, when I started out, I treated my code base like a bomb. I was scared that one wrong move and this project was But I learned something. The best way to learn is by breaking things, change a value, break a feature, refactor if possible, see what happens. You're not going to destroy the universe. Your project probably isn't even public or has any users, so who's going to notice? Now, I know this sounds counterintuitive, but the moment I stopped trying to write quote unquote perfect code and just started experimenting, that's when things started to click and I was making real progress. If you learn how to mess around without fear, you're going to learn 10 times faster than someone who just reads tutorials and tiptoes around their own project. Now, uh before you start breaking things, please learn version control with Git. Version control is basically the programming equivalent to a quick save. And once you learn Git or you have some sort of backup, start testing things out. Now, if you do mess up something, worst case scenario, you just hit control-z. Or if you know how to use get and branches correctly, just switch and delete that branch into the void. If anything, just delete the whole folder and start fresh ## Overengineering [03:26] because you probably only had hello world written. Number four, overengineering. I swear every programmer has fallen into this trap hard. I know I did. You see this book right here? Design data inensive applications. This starts every programmer's descent to overengineering. Okay, it's not just this book. There's a lot of other reasons. I remember I was in a whole system design and scaling phase. So I was really into reading engineering blogs where I understood like 20% of the information and um one time I was reading Discord's engineering blog and I thought you know what what if I built a full Discord clone using this blog and try to copy their architecture all of it. Needless to say the project died before it even rendered a login screen. But once you have some experience programming and you start moving away from the beginner stuff, you start learning these best practices and all these fancy system design techniques and technologies that enterprise companies use. And now every time you want to build a personal project, you start to think about these concepts and think, I should build it like these enterprise companies because that's how real engineers do it. And now all of a sudden your project needs microservices for every tiny function, multiple specialized databases, message cues, elastic search, cafka, blah blah blah ## Dont Overengineer [04:35] blah. But you start to forget some things. One, the reason these companies made these decisions is because they had to. Two, they evolved to this complexity over years, not days. Three, they have entire teams dedicated to each component. Four, they're serving millions of users. Your project is serving one yourself. Please don't overengineer your projects. Now, my advice to you, if you're in this overengineering phase or you're starting to reach it, don't worry about this stuff unless it's for system design interviews or, you know, you need it. If you're actually trying to implement this in a side project, you're going to waste some time. I'm not going to lie. But if you're doing this purely just to learn, just for the love of the game, go ahead. ## Use Gmail [05:13] Bonus mistake. Using Gmail. What? Okay. Honestly, I just don't know how to sneak this in. Sneak one in. Today's sponsor, Notion. Woo. Look, we all know email is a nightmare. Your inbox is probably a mess right now with hundreds of unread messages you're pretending don't exist. Notion realized this problem and they created Notion Mail. Notion Mail is one of the first emails that organizes your inbox, draft responses, and schedule meetings exactly how you wanted, helping you get back to the real work. It's easy to get started as well. All you have to do is connect your existing Gmail account, and you'll upgrade your email experience for free. Check out some of the cool features. Instead of having to manually categorize emails with stars and labels, Notion Mail automatically labels and sorts incoming emails based on what's important to you. I love this feature. I use this for my newsletter when people reply to it. I don't have to manually label them and I don't have to scroll through hundreds of emails to find those responses. It's great. And one of my favorite features, you can use AI to help you write emails. You can use their suggestions or if you need to adjust your tone or check your grammar, you can ask AI to help you out. And of course, you can write your emails using the same clean Notion editor you already know. So, if you want to try out Notion mail and upgrade your email experience for free, click the link in the description. Number five, forgetting that users are not developers. You know, a lot of programmers live in a weird bubble where they think everyone understands technology like them. Well, guess what? They don't. You can build a website that you think is super intuitive and then you watch someone else use it and they somehow break it. This happens every single time. Regular people are going to give you a reality check. You might think hamburger menus are universal knowledge. It's not. Try asking your grandma or grandpa. They're going to look for an actual hamburger menu. And here's an unfortunate truth. The more time you spend programming, the worse you become at predicting how normal people use your software because you've been brainwashed with technical knowledge. So remember, try to make websites that make sense for regular people because they touch grass, unlike us. Number six, starting too big. ## Starting Too Big [07:05] Imagine you have a big project idea. The productivity app to end all productivity apps. It's going to have real-time syncing, cananband boards, calendars, habit tracking, pomodoro timers, AI task suggestions, and you know what? Maybe it'll even order you breakfast. You open up your code editor full of hopes and dreams. You write a readme file explaining what the app will do if you ever finish. You're trying to set up your database schemas for 18 different features, and all of a sudden, you stall. You burn out. You question your entire existence. You think you're a bad programmer. You stop programming. The project dies. You die. Now, here's some ## Start Small [07:39] advice to a lot of you. Start small, feature by feature. Focus on one thing, one small thing. Like literally just making a button. For example, you want to do a note-taking app. How about you start with, oh, I don't know, creating note. Make that one thing solid. Don't worry about any other features. If you start worrying about a lot of other features, you know what that's called? Feature creep. Nobody likes feature creep. Don't fall into that trap. The features you want, those can come later, or maybe not at all. If you're trying to build everything all at once, you're just going to end up with 5% of a mega project and 95% of a mental breakdown. This is why I personally like the MVP approach. Minimum viable product if you didn't know. This isn't just startup jargon. Well, nah, you can decide that one. It's honestly the only way most of us will ever finish anything. But I do have to say this, MVP does not mean garbage app. It's just a smaller app that works properly. Build the simplest version that does one thing well and then add features one by one. If I can't describe my project in one sentence, it's too big. Scale it down before you end up with another abandoned GitHub repo. Number seven, no comments or documentation. The four lies every programmer tells themselves. Number one, I'll remember what this does. Number two, it's obvious what this code is doing. Number three, the code is the documentation. Number four, I don't need to document this. Do not lie to yourself. Add documentation, please. What does documentation look like? A readme file would be greatly appreciated. Comments that explain why, not what. Here's a test that'll help you out. If someone with reasonable programming skills, but zero knowledge of your project can understand what your code does, you've documented pretty well. If not, you must be a massochist because you clearly love pain. Number eight, reinventing the wheel. We've all been here. You need something for your project, but instead of using one of the 5,000 existing solutions, you decide to build your own from scratch because it's not that complicated. Stop right there because you're wrong. Trust me, someone already solved this problem better than you ever will. The only time you should do this is if you actually want to learn how something works or you have some weird edge case or requirement that these libraries can't handle right now. But if you don't care about it, don't make it from scratch. It's a complete waste of time. Unless you're one of those rare 0.1% engineers that have skills, then please make our lives easier. We need it. But for the rest of you, your authentication system is not better than a lot of these libraries. Trust me, many have tried. Number nine, comparing yourself to other programmers. You open up Twitter or X, I guess, and boom, I built a SAS in 4 hours, made 10K in a week, quit my job, and now I surf in Bali every morning. And then you scroll down and see some 16-year-old like, "While you're all applying to colleges, I just launched my third AI startup." Meanwhile, you're here trying to figure out why your calculator is adding numbers like this. And look, I've been there. I'm still there. It feels like everyone else is sprinting while you're still trying to learn how to tie your shoes. But here's what you need to remember. You're watching everyone else's highlight reel while you're living through your own blooper reel. You did not see the 300 hours they spent debugging, the projects they abandoned, or the existential crisises they had at 2 a.m. wondering if they should have gone to law school. So instead of trying to compare yourself to them, compare yourself to what you were like 3 months ago. Are you improving? Are you learning new things? Are you making fewer mistakes? That's what truly matters. Number 10, having shiny object syndrome. ## Shiny Object Syndrome [11:04] This is what shiny object syndrome looks like. You start working on a project. You make decent progress. You see a cool article or video about a technology. You abandon your project to learn the technology. You start a new project with the new technology. You see another cool article or video about a different technology. You abandon that project to learn this new technology. And you're going to repeat this until you realize you have it or until you quit programming. Here's some signs you have shiny object syndrome. You have more projects than lines of code written. You can write Hello World in 12 different languages, but you can't build an app in any of them. 40 different ultimate guides to random technology articles that you'll read later. You'll never read them. Pick one thing and commit to it. If you make any of these mistakes, you're a terrible programmer. And I know this because I've made all these mistakes and I'm a terrible programmer. See you in the next video. [Music]