Did you know that a huge number of aspiring developers get stuck in this thing called the tutorial hell? And if you're watching this, maybe you know the feeling. Maybe you've been coding along for months, maybe even acing the quizzes that these platforms give you, but when you finally sit down to build something from scratch, which is your own two hands and a blank code screen, blank, you don't know what how to proceed from there. And this was me, exactly me a few years ago. Um, I spent six months doing every free coding course under the sun, CS50, free code camp, um, code academy, endless YouTube, um, videos, and I still couldn't build anything on my own. Um, you know, I was honestly questioning if coding really is for me, and it was just really frustrating. So, I remember opening up a code editor, and I created my first project and I just sat there staring at it thinking, why is this so hard? If, you know, doing those tutorials was so global and I felt like I was doing well. So, who am I and why should you listen to this video? Well, my name is Derek and I am a former finance graduate turned into a self-taught developer and I eventually broke out of tutorial hell, started building real projects and even started my own coding agency and my coding boot camp that has helped people land tech jobs in 3 to 6 months. So, our approach is simple. We focus on output based learning which is a fancy way of saying you learn by doing and in fact we we are so confident in our pitch because I understand what the industry needs. I speak to hiring partners and CTOs of different companies, understand the use cases and the needs and the requirements they have when it comes to hiring developers. We're so confident that we say that if our students don't get a job after graduating from the boot camp, we give them a full refund. So, let me just tell you this, right? I've seen dozens of beginners from exarketeteers to um ex construction workers to um you know, you name it, doctors even, right, go from zero coding skills to actually being employed as software developers once they've escaped tutorial hell. I'm not saying that to brag but to give you proof that escaping tutorial hell is absolutely possible and if they can do it if I can do it you can too. So in this video I want to share how I escape tutorial hell and the first principles strategies that you can use to do the same. And this is not just some abstract highle advice. I'm going to share it from a more personal um from my own journey and it's the same approach that I use with my role models right people like Jason Freed Navar Ravikhan and Peter levels. Um this this is exactly what they would advocate which is a more practical hands-on learning over endless theory. And by the end of this video, you will have a clear game plan to break free from the loop of tutorials and start building real coding skills. So let's dive in. So first we're going to understand what exactly is tutorial hell and why so many get stuck in it. Tutorial hell is that vicious cycle where you keep taking tutorial after tutorial without ever feeling ready to build something of your own. You feel like you're learning and the instructor's code uh makes sense. You feel like you can follow along. But the moment you face a blank VS code window, you you panic and suddenly you realize that you've never truly internalized the skill to create something from scratch actually, right? And everything has been spoonfed so far. And why do so many of us fall into this trap? Let's break it down from a first principles view. If you look at traditional learning versus coding, most of us grew up with a classroom type mindset where you sit quietly, you listen to lectures, you do the assignments, and you pass the test. We got used to the being taught and tested way of learning. But coding doesn't work like that. There is no final exam that magically gives you developer job if you score 90%. The real exam in coding is can you actually build something that works and the only way to pass that exam is by actually practicing code not by memorizing syntax and in other words you learn to code by coding just like how you learn to swim by actually swimming. You can watch a thousand hours of swimming tutorials or coding tutorials but it won't make you a swimmer or in our case a programmer until you jump into the water yourself. As I wrote on my blog during my journey, a thousand hours of watching tutorials will not help you learn to code. It's harsh, but it's really kind of true. So, the comfort of tutorials is that it feels safe and it gives you a form of structure. They handhold you through challenges and you get a dopamine hit of like, hey, I just finished the module. Yay. All right. Um, it feels like progress, but often it's just an illusion of progress. I I was guilty of this myself. I I felt great checking off lessons, you know, back in the days and every single day. I was grinding through 8 am to like 12 a.m. every single day, but I wasn't applying any of it. I was just putting in the boot force work, which by the way, it's very important, right? It's just not enough. It's comfortable because someone else is doing the hard thinking and the planning for you. And the moment the crutch is gone, you realize you never actually learn to stand on your own. It's like always using training wheels on a bike. Sure, you're you're going to be able to move forward, but taking them off will make you fall and we need to take the training wheels off as soon as possible if our goals here are to be um to be able to be hired as a software developer. So, the fear of failure and perfectionism is another first principle reason why we stay in tutorial hell, right? Because building something from scratch is actually very scary, especially if you don't know how to build it or you've never done it yourself before. You might fail and you may realize that you know you you may have tried and gotten stuck somewhere and then you know that the project just ended and you feel like you know you couldn't get past this and and and you you you realize that you don't actually know how to do it. So the tutorials that you do they actually what they do is that they serve a purpose of protecting your ego. If your project doesn't work well well it it's the tutorial's fault. It's not your fault, right? And studying your own project removes that safety net. Okay? I I've been there before, right? I I was afraid to deviate from the script at all because it might just go wrong and I I'm just stuck forever. Right? But one thing I've learned and you know entrepreneurs and indie hackers like Peter Levelvels reiterate is that doing something even if it's not perfect is always way better than doing nothing. As Peter levels famously wrote about his own journey by just doing something you position yourself ahead of most people you will figure out what you need to do by exposing yourself to the world and by doing nothing you figure out exactly nothing. In coding that means if you never write your own code you'll learn nothing new. You have to try you have to screw up. You have to drown a little bit. You have to debug. You have to learn from those mistakes, learn from those bugs, and that's where the real learning happens. So, if you feel seen by any of this, if you're nodding along because you've watched hours of tutorials but still can't seem to build a project, you're not alone, right? And trust me, all the vibe coding guys who has never built a foundational understanding of how coding works, they're going to get stuck, too. And if they're able to vibe code themselves to to to make a really good progress, it also means they've also overcome that level of like getting stuck and overcoming it and figuring things out as well. This is a reiterative process that you can never gain by just watching videos. And this is very common, right? I would say everybody who's learning to code must have gone through this stage. And I would estimate from my experience mentoring and running a coding school that majority like 90% of beginners hit this wall. And the good news is everybody hits it regardless of some people may hit it on day one, some people day 10, but at some point everybody hits it because it's a sign of growth, a sign of learning, it's a sign of um progress. And it's a temporary wall. You got to know that. That's the good news, right? And you can absolutely smash through this wall uh with the right approach. So let me share with you how I finally did it. So to make the the sharing that I'm going to do more concrete, let me tell you a personal story of mine when it comes to escaping tutorial hell. Right back in 2019, I was I was working in corporate finance in in venture capital, more like a financial analyst kind of guy who decided to switch to tech. So I quit my finance job to learn coding full-time, right? Pretty crazy, I know, right? Uh for a standard Malaysian fresh graduate to be doing that. Um people were asking like what the hell are you doing? Anyways, I I threw myself into this whole self-learning uh route. I started off with CS50, Harvard CS50 free course, which is absolutely amazing, by the way. Check it out. Um, then I did free code cam exercises every single day. I did a bunch of coding YouTube tutorials and I was just literally studying 8 a.m. to like sometimes 8 12 p.m. every day. Literally locking myself in my room just coding along with videos. And for a while, it actually felt like progress. I was absorbing a ton of information. But after about 6 months, which is a really long time by the way, right? I couldn't monetize things. and reality just really hit me hit me in the face. I realized that I still couldn't build anything from scratch. I could follow along really well and I could repeat what instructors did. And trust me, I've learned so many different programming languages. I've done most of the videos that you've seen on YouTube. I've done it. But as soon as I tried to start a simple project of my own, I just froze and all those concepts that I thought I knew, they just evaporated. I was basically just copy and pasting and coding along without truly understanding how to create. Well, in today's AI world, uh that's what vibe coders are doing. copy pasting and just hoping the AI gets it and gives it to you. With VIP coding, it's amazing what you can build. You can probably build an MVP of a startup pretty well along the journey of building a startup. If you're just VIP coding along, but you don't call yourself a developer cuz that's just that's just you copying snippets of code, pasting it somewhere else without understanding what's going on. That's not a developer, right? And for me, the content I'm building and the kind of like sharing I'm sharing is always in terms of how can you get to a good enough level to actually get hired as a developer, right? We do cover videos on VIP coding and using AI to code as well, but that's two separate paths and I want to just be very clear with anyone who's watching this right now. So that was uh coming back to my story that was easily the most demoralizing period of my life. I started doubting myself. Um maybe you know I was just thinking to myself maybe I just I'm just not cut out for this. Maybe I'm not smart enough to be a programmer. I I even dabbled in other things right like UIUX design uh digital marketing data analytics. So whenever coding got tough, I basically just procrastinated by learning um other skills because I was so frustrated, right? Finally at the brink of giving up, I had a breakthrough, right? I said to myself, you know, enough is enough. Um I don't want to waste any more time. If this isn't working out, I'm just going to move on with life. No more coding along, no more copying solutions, no more watching others code. I decided that it was do for me and do for die for my coding dream. I said, you know, I was just being rational. I said, you know, in in the real world, you're not going to be able to watch some YouTube tutorials to, you know, work in your role as a software developer. So, I was like, okay, if I'm not able to just go all in and build it myself, right? If I was going to actually become a developer, I had to start acting like one and that that meant building something without tutorials guiding me. So, I devised a simple plan. And in hindsight, it was from very much from a first principles approach to learning. So, I decided to number one pick one tech stack and just stick to it. No more jumping between JavaScript. I did Python and Ruby and Ruby and Rails and tutorial hell made me a bit of a wanderer I would say right I hop to a new language or or framework whenever I got bored or whenever I hit a snack whenever I you know get got stuck on a plateau when it comes to learning which happens all the time right and that stops now I chose one thing which is to master and to be good enough in the JavaScript ecosystem so think HTML CSS I did VueJS back in the day but it's more react now um I do JavaScript then I do some JavaScript framework like expressjs or node for the back end and I commit committed to it. So, so basically just one set of tools until I can actually build something deployable in production. Number two, choose one project to build and commit to it. Something small but meaningful. And at the time, there was a popular Korean drama called Start Up. Watch it guys, if you're in this whole route, this whole building your own hustle, building your own grind route. Go watch that. It's pretty good. Where the characters built an app called Nungil back in the days. So, what the app does was it helped blind people see using image and pattern recognition, which was pretty cool. like object detection. You put a camera there, it tells you what's there. Maybe if you're watching this today, it may not sound impressive to you anymore because chat GBT does it out of the box, right? But back in the days, we had to connect our own APIs to make that happen. And it was really cool. I built that um I put on LinkedIn and it blew up. We got like thousands of tens of thousands of impressions. And I thought, you know what? If I could build a simple version of that, you know, it was a cool concept that inspired me and it had a clear goal. What it does was it taught me how to build a software that takes an image, use an object detection API, return a description, and importantly, it was something that I hadn't seen a step-by-step tutorial for. So, I built it from scratch myself and I truly have to figure it out by myself, right? So, figure it out no matter what. Right? That that was our part, right? You got to Google, you got to read documentations. I used to use Stack Overflow and to ask for help. Basically, just be stubborn. If I hit a wall, I wouldn't immediately run back to the cozy comfort of a step-by-step video. I would struggle through like a real developer do does in their own real world jobs. I will search error messages or console log or read documentation. I'll maybe ask on Stack Overflow or Discord communities. This was a pact that I made with myself. No quitting and no immediately switching back to passive learning. So with this plan in place, I got to work and let me tell you, the first day or even the first week, it was rough. It was tough. It was tough. I was trying to set up basic express server and get an image recognition API working and nothing was working. So I had to learn right that's exactly when I was forced to build my own APIs myself with express and but I kept reminding myself that this is exactly what I signed up for. The confusion is good because it means that I'm learning every time I successfully solved a small problem like figuring out how to send a file to the API or how to render the output on a web page. It felt like so good felt amazing. Those little wins became so addictive that and became way more satisfying than completing a chapter or a tutorial and getting a meaningless certificate. So amazingly I finished a prototype of that app in a few weeks. Whatever I just mentioned it was not pretty and I definitely was not writing clean code but it worked and I had built a real functioning app completely by myself. Right? Full disclosure I didn't build my own machine learning uh model. I was just using an open source API for object detection but writing it all together was still a big challenge. And hey, look, that's literally what developers do, connecting APIs, right? Most of the time they don't even build the algorithms that they're using today, right? We use um external APIs for authentication, for payment, for getting currency uh pricing, but API is like a day-to-day for developers. So, seeing it almost replicate that like like to a 95 99% accuracy, I actually did it. Seeing it almost replicate that fictional app from the show was such a huge confidence boost. And more importantly, I learned so much more in like a few weeks than in the six months prior. And it hit me that there's actually no secret sauce when it comes to learning code. No miraculous tutorial that I haven't found yet. No secret pill that you eat and you become a developer. No secret course, no no university program. The secret was the old boring truth, which is you have to grind it through and you have to practice and you need to learn how to do it by actually doing. Just like no one can force you to do your push-ups for you. No one can get your apps for you, right? No tutorial can replace you writing and running the code yourself. And from that point on, I fundamentally changed my approach to learning anything in my life. I embraced the outputbased learning methodology. So instead of consuming content endlessly, I made sure I was producing. I was I I ran community groups where I taught people how to code. I was building software projects. I was taking on projects and getting paid for them. So I gave myself a challenge to build one small project every single month. Right? It could be anything. a to-do app, a personal blog website, a simple game, whatever kept me interested. The key was that I had something to show at the end of each month, however basic it was. Quantity over perfection for me. And each project taught me new things, new new frameworks, and it reinforced old concepts. And I was finally just internalizing the knowledge by using it in in different um context and seeing them come to life. I stopped rotating between tutorials. In fact, I stopped doing tutorials altogether, right? This whole shiny object syndrome thing, it had to die. I picked the curriculum and I just stuck to it supplementing only when I needed right I learned on the job I learned on the projects I took on and in my case I just focused on one and just went all in on JavaScript and whenever I encountered a concept I didn't get I would search for specific explanations or ask a mentor rather than jumping to a whole new course which I used to do right I was like oh no I face a blocker let me just try Ruby Ruby maybe Ruby I heard Ruby is easier that was that's what I used to do right no more you know Python looks fun maybe I'll try that for a while no none of that stuff so at least not until I I achieved my goal in JavaScript and the goal was that focus was so crucial. So I started seeking mentors and I built a community called hacker collective. You know learners come together every week to learn how to code and at some point I was also a mentor in the community teaching all the other um self-arners how to navigate this space right that that's what really brought me to my whole new level and even helped me start monetizing my skills. That's that that's such a that's a story for another day. Right. Yeah. But I did that instead of watching pre-recorded videos. And this is big right because in tutorials during a one-way interaction I realized I needed feedback and the ability to ask questions. So I connected with a more experienced developer who later became my co-founder and my partner for the hacker collective which is a pure learning group that I started in my city and having a mentor or at least peers who are somewhat in this journey together with me is I think the most important thing right when when it comes to things like coding boot camps sometimes you know I I I truly believe the curriculum is not the moat the moat is with the support that the instructors provide the the jobs that the school connects you to and and what's more importantly it's the people who are on this journey together with you right like it or not by fate of by choice guys, this is a group of people, the same exact goal as you have, the same singular focus as you have for the next 3 months of your lives, and you're all in this together. And like that that that whole energy just brought me to a whole new level. So having mentors, having peers, that's that's that's so much more amazing than just grinding yourself through tutorial hell, right? So even if you don't have a formal mentor or get involved in Discord, coding servers, a subreddit, or a local coding meetup, when you see others building and you can ask like dumb questions and get answers, you break out of that isolated loop. And and guess what? If you're a junior, there's no dumb questions. just go out there and ask it, right? Especially if you're young, no one's going to judge. Plus, explaining your problem to someone often makes you understand it better, right? Um the method that I like to get my students to do and myself would be what I call the rubber ducking method where sometimes you just articulate the issue out loud and your brain just kind of works in wonderful ways that that helps you um kind of pseudo code and get answers for you. I learned to embrace being stuck as part of the process. Initially, whenever I got stuck, I would feel awful and incompetent, but now I see it differently. Being stuck means I'm about to learn something new. I adopted this new mantra that I tell my students today. Struggle is not failure. It's the tuition you pay for progress. So every bug you debug, every message you painstakingly fix, it's like a rep at the gym. It's making you stronger. Even if it makes you feel uncomfortable, that mindset shift, I believe, will be gamechanging to a lot of you. So over time, these changes paid off. I went from tutorial junkie to a fledging developer who could literally build anything I wanted to build. The real validation came when I started freelancing and even teaching others. And I remember looking back at some of the older code from those first solo projects. It was so damn messy, but I could literally see how much I've improved since then. Since then, I could spot things so much more differently now. I could structure my code base so much better. And that's when I knew I was growing. If you want a reality check for yourself, save some of your early code bases and revisit them every 3 to 6 months later, right? You will be shocked at how much more clearly things are in hindsight. And that feeling is just so incredible because it tells you, hey, you know, you're objectively being able to measure your own progress and know that you are getting better at at this. So, fast forward, those little projects and freelancing gigs and software projects eventually snowballed. I ended up co-founding uh you know a peer learning community and then a boot camp which is Sigma school to teach coding with this hands-on philosophy that I used. I even interviewed over 100 computer science graduates for hiring at one point and I was shocked that most of them couldn't code a simple application despite their degrees. And that really confirmed it for me that the traditional theoretical approach creates a lot of tutorial hell graduates too. People who learned to pass exams but not solve problems. The only way out is by practicing and by learning. The ones that I did hire, the ones who succeeded in my program were those who had built stuff on their own, those who were curious, those who put in the extra work. There are those who had proof of work to show, right? All right. So, enough about me. I think I think you know went on and on about my journey. But let's distill this into a few key takeaways that you can use for your own journey if you're going through one right now. Even in the age of AI, all right, let me let me tell you that, right? Even if AI today, you cannot run away from this. And this applies to everything in your life, everything you're trying to learn, it all boils down to these few principles. All right? So, five tactics to escape tutorial hell. These are practical steps that I I have accumulated over the years, right? And whether you agree with it or not, it's just my my way of doing things. So, now that you know how I stumbled through this, you you have some context in terms of how my life played out. Let's lay out a clear game plan for you to escape tutorial. And these are the ground steps that the same ones that I wish someone had told me back in the days when I started and the same principles that I've seen in action with so many successful selftaugh developers. Number one, shift to a project-based learning immediately. Don't wait until you feel ready to start a project. You become ready by starting. Trust me on that. After you learn a new concept or watch the tutorial module, pause and go and freaking implement it in a mini project. Even if you just learn how to create a simple HTML and CSS page, go and make a personal homepage from scratch without picking at the solution. And if you learn a JavaScript loop, use it to build a tiny game. FSB, you know, that very famous uh programming game uh kind of kind of code, one of the first ones that you do in a lot of the tutorials they do. Uh it's a number guessing game, whatever. Right? The key is to integrate new knowledge by applying it right away. A good rule of thumb for every hour you spend watching or reading, spend at least an hour coding on your own. Even early on, 50/50 learning versus doing is a great balance. Trust me, this is where 95% of beginners fail because they consume for 100 hours and produce nothing. Don't be that guy. Don't be that person. Start building something small from day one. It can be toy programs or fragments of a large larger idea. For example, one of my um early mini projects was just creating a tweet component UI because I was learning CSS positioning. I literally tried to replicate the look of a Twitter tweet card with HTMLS. It wasn't a full app, but it was just me taking the abstract ideas from the tutorial and making them concrete on a page that I built. And those little wins, they add up, right? Okay. Number two, learn how to simplify and focus one stack, one project at a time. The tech world is vast. It's it's so broad and it's so tempting to try a little bit of everything. But when you're stuck in tutorial hell, variety is not your friend. Focus is especially in the early days. Pick one language or pick one text stack, right? For example, if you're doing web development, it's always going to be JavaScript. It's king, right? If you're doing data, choose Python. That's king. Whatever excites you and stick to it for decent period of time. Whatever you've done, just stick to it several months at least. All right? Um, choose, you know, don't don't spend 10 hours looking Python or JavaScript, Python. No, just choose one. They're both they're both good enough, right? This avoids the trap of shallow knowledge in 10 different things. instead you will become deeper in one which actually makes learning the next thing so so so much easier. So along with this one stack pick one main project to be your capstone for that learning phase. This project should be something you care about that solves a problem you have or an idea you find cool. It does not have to be original. It just has to motivate you good enough. And the reason for this is when you hit tough spots and you will having a purpose for the project keeps you going. And for me it was that Netflix Korean drama thing that I told you about the nounil clone app. I was excited by the idea of helping visually impaired users. So, I was determined to make it work. And for you, it might be a personal budget tracker, uh, a simple game, a clone of a favorite app, or a tool to help your own business, right? Jason Freed, the co-founder of Basecam, my role model, often suggests scratching your own itch, solving a problem that you actually have, and that ensures that you you become invested in the outcome. So, focus one stack, one project. Put on blinders to other shiny tutorials until you finish that. Number three, embrace the the concept of just in time learning or um or what I would also call just enough learning. All right, when building your project, you will inevitably hit something that you don't know how to do. This is completely normal. Now, now you have the context to learn the thing that you need, the skills that you need. And this is just in time learning versus just in case learning. That makes sense, right? Tutorial hell is full of just in case learning. You learn features or syntax just in case you need it, right? someday and you you promptly just forget 90% of it anyways. Instead, when you're actively building, you pull in new knowledge as you as you need it and these are things that are actually being used. So, you get to see a trend of what's being used more frequently and you learn to adapt to it. So, for example, maybe you're building your project and you realize you need to implement a user login, but you have no idea how authentication works. Perfect. Now go find resources specifically on how to implement login in XYZ framework or authentication basics and you'll be amazed how much faster you learn something when your project actually demands it when it requires of it and because you immediately apply to solve a problem it sticks in your head so much better this way you're learning from the first principles of necessity when you have a problem for example users need a login you learn the concept so for example sessions or JWT etc things like that to solve it and then you implement it it's goal oriented it turns your learning into an active treasure rather than a passive lecture. Plus, using official docs and searching online in this targeted way trains an essential developer skill, which is researching and problem solving. Trust me on that. Okay. Pro tip here is to try to use official documentation or reputable sources for these answers rather than immediately running back to the comfort of a full tutorial series. You might find the official docs actually make sense now. And and once you've learned how to read documentation, you know, best practices of writing documentation and it helps you understand other other documentation so much faster as well. And if someday you're building your own framework or your own codebase, you will have to also write your own documentation. So next would be to explain what you've learned using the rubber duck method. This one might feel awkward, but it's so effective. After you learn a concept, try to explain it in simple terms either to another person or literally to a rubber duck sitting on your desk. I'm I'm not kidding. Developers joke about the rubber duck debugging methodology where you explain your code and you tell the duck line by line what each line of code does until you find a bug. So, this works for learning too. Let's say you just learned about JavaScript closures or or Python decorators or something that twisted your brain a little bit, right? Pause and teach it back to an imaginary student or your pet or the duck. When I started doing this, I realized how many holes there were in my understanding, which pushed me to fill them if you can't explain it simply. You probably haven't fully grasped it yet. This technique forces you to confront what you think you know, right? And sometimes it I I would even write a quick blog post or forum answer to a question about that topic not because I was an expert but really to solidify my learning and also share my learnings with the people who may be struggling this concept as well. As Charlie Mer who is a famous investor and Warren Buffett's business partner for many many years. He would advise the best way to learn is to teach. It's humbling but it cements um concepts in your mind. So talk to the damn duck. You might be surprised at the insights that you get. Okay. And the next one would be to get feedback as well as mentorship. I touched on this earlier, but it's worth its own point. Not right now. Don't learn in a vacuum. When you start building, share your code with others. Write on LinkedIn. Push your code on GitHub. Ask for a review. Join a community where you can say, um, hey, I built this. Any feedback? You know, if you know someone experience, ask them to take a quick look. Critique can be hard to swallow. As a newbie, I remember the first time someone commented, you know, that my code this function could have been better structured. I felt a little bit defensive but it's incredibly valuable for growth because that person is giving you an opportunity to understand and see things from his perspective but look he may not be right but the point is you get to welcome new ideas and new perspectives for you to consider right okay and even if you don't have a personal mentor being active in community um can expose you to advice and encouragement also consider pair programming or working through problems with a peer so when I was learning I formed a small study group with in the hacker collective where we would hop on video calls or meet up in person and help each other true bugs or just co-work account for accountability and that social aspect keeps you motivated and it breaks the cycle of isolation. So if you're in a boot camp or a school definitely 100% take advantage of your instructor's office hours or mentorship opportunities instead of um struggling 100% alone. And if you're truly solo don't be afraid to reach out to people on LinkedIn or Twitter who are a bit ahead of you. Many developers are so much happier to give quick pointers to beginners uh because we know you know how it's like struggling as a beginner. In short, mentorship helps you accelerate to escape from tutorial help by guiding you around common pitfalls and giving you tailored advice. And I attribute I attribute a lot of my rapid progress to the mentors and the peers who has helped me. So remember that asking for help is not weakness. It's actually a very smart strategy. And finally, you know, as part of this uh tactical session, here's a mindset hack. Start viewing tutorials as tools, not crutches. When you do use a tutorial or a course, do it actively. Pause often. Um experiment in the code, pick things up. Don't just follow along blindly. Treat the tutorial as a guided warm-up, but then quickly move into your own workout by building something related. If the tutorial makes a to-do app, challenge yourself to add a feature to it that wasn't covered purely for your own effort. Turn the tutorial into a springboard for a mini project. And this way, even when you consume educational content, you're actually integrating it into your own project and not just theirs. And that mindset will help you get out of this whole tutorial loop. So, finally, I want to talk about the mindset shift from a consumer to a creator beyond the practical steps um that I've discussed just now, right? the mindset that will ultimately set you free from tutorial hell, right? Everything boils down to this. If you see yourself as a creator and not just a student, you you train your brain to think bigger. And in tutorial hell, you're forever a student following a curriculum someone else set for you. To escape out of this, you have to step into the role of a creator or a problem solver. Think for yourself. This means embracing uncertainty and you got to take a lot of initiative. So, a few mindset shifts. The first one will be to allow yourself to fail publicly if needed. And this is huge because part of why I stayed in tutorial hell is because I hated feeling incompetent. It's tough on the ego to write code that doesn't work or to build a project that it's so basic while seeing others on Twitter building really fancy apps, right? But you have to make peace with being a beginner. Every expert was once a beginner who was not afraid to look like a full wall learning. It's okay if your first project is basically held together with duct tape and stack overflow snippets. That's how we all start. Okay, you don't have to s show it to the wall if you don't want to, but internally don't judge yourself too harshly. Instead, celebrate that you've built something at all. Right? I remember how proud I was at at that clunky first app. It was far from perfect, but it was mine and it felt so good. Number two, measure your progress by output and not hours. It's either easy to say like I did, right? I spent 5 hours today. I was coding 8 to 12 uh a.m. 8 a.m. to 12:00 a.m. the entire day as if that's an accomplishment by itself. But but if those five hours were just watching videos while half distracted, it's not actually progress. It's just fine busy work. Instead, measure things like I solved three coding challenges today or I built and deployed a simple web page today or I finally debugged that issue that was blocking me. Use all these outcome based or output based uh uh outcomes to track yourself. Okay? Set smart goals for yourself. Those are concrete wins. Even reading code or troubleshooting about for hours, those counts, right? It's it's the effort to win an outcome. When you start thinking this way, you will see momentum build. You might complete a tutorial in half the time because you're eager to apply it and move on. So time may not be the best measure. Another thing would be to remember to reflect on your growth regularly. I hinted at this earlier. Keep a journal or log of what you've learned and built. U this is a very memorable time in your life. Every week note down what new things you did or you understand when you feel stuck or you feel down flip through it. You will often realize you know much more than you did a month ago. And one thing I did was keep some of my early projects even as I got better. Sometimes when I felt, oh, I'm not improving, right? I open up my old code snippet and I cringe. which paradoxically made me smile because the present me could immediately see how I could improve and do better, right? That's a proof of growth and that's so motivating. And finally, you know, remember your why. Why do you start learning to code in the first place? Was it to land a highpaying job? Was it to work remotely? Was it to change careers? Was it to build an app that you were dreaming of? Whatever your personal motivation is, keep it front and center. For me, I wanted to break into tech to have more impact and eventually start my own tech business. Whenever I got frustrated, I pictured the life that I wanted, running a startup, building products, having the freedom to create. I eventually, you know, hit a point where my coding business was doing well enough so I could relax. But I realized that I was not ready to chill. I wanted to push myself further to build bigger impact to reach a goal of 100 million ring in revenue per year, right? Create more jobs, innovate with tech, upskill more lives. And all that drives me to keep coding, to keep building, to keep learning. In the same way, your why can pull you out of the ruts. And if your dream is to become a game developer, for example, imagine people playing a game that you build. That vision can pull you through a lot of the tough learning days. So before we wrap up, let me address a common question, which is, "How do I know I've escaped tutorial hell?" Honestly, the moment you take those training wheels off and start building something without following a script, you're already climbing out of it. But I would say you will feel you've escaped when you approach a brand new small project and have a systematic way to tackle it. Break it into parts, Google things as needed, and piece it together. You will know you're out when you're facing an empty repo and and you feel excited instead of feeling terrified. It doesn't mean you know everything. You never will, by the way, right? It just means that you're no longer paralyzed by not having step-by-step instructions. You're becoming a self-sufficient learner. And that's an amazing feeling. Not only can you build things, but you've proven that you can learn and figure things out on your own. And that confidence, it compounds. So to conclude, you know, escaping tutorial hell is not easy. It's not easy at all, but it's a very simple process, right? It comes down to the simple formula of build, fail, learn, repeat. Every developer duet Mario has gone through this. Even my heroes like Charlie Mer or Naval Raikihan even though they not they're not developers per se they echo the same sentiment in their fields. Focus on the fundamentals, learn by doing and keep on iterating from there. As Naval Narrahan might say, your rate of learning will determine your rate of success. And the fastest way to learn is to do meaningful work. I want you to know that if you're struggling right now, feeling like you're banging your head against the wall trying to code, you're on the right track. It may not feel like it, but this is the process working right. You are building the mental muscles that tutorials alone cannot build. Every time you break out of a tutorial and write your own code, no matter how big or small, you are escaping out of the tutorial hell. It's like pulling yourself out of a quicksand one inch at a time. Keep at it and one day you will look back and realize the quicksand is far behind of you. Right? To recap, remember these points. Number one, you learn to code by coding. No way around it. Use tutorials as support, not as a crutch. Number two, start building small projects as soon as possible. Done is better than perfect. Number three, focus on one path long enough to get somewhere. Don't hop around whenever it gets tough. Number four, embrace struggle and bugs as part of learning. Debugging is your teacher. Number five, seek help um and community. You're not in this alone. You will progress so much faster once once you start doing that. And number six, keep the creator mindset. You are not just a student. You are a maker from day one. If you implement this, I promise you will see transformation. It might be weeks or months, right? And but you will suddenly realize that hey, I can actually make things now without handholding. That's literally what my student said to me uh the other day and it really warms my heart and I'm so happy for him. Right? This is the ticket to wherever you want to go in tech whether it's landing that junior developer job or launching your own software product. One more bit of encouragement I can give you is I nearly gave up when I was in the depths of tutorial hell. I had those thoughts of maybe I don't want this. I even started applying for jobs. Right? But if I had quit, I would have missed out on an entirely different path in life. I would have missed out on this incredible journey that I'm on today. switching careers, building multiple startups, teaching others, making money, achieving a life that I genuinely love. So don't quit on yourself. You have no idea what opportunities might open up once you get past this initial sticking point. Think about this way. You spend three years in universities wasting your time, you know, whatever living living and parting away. What's another three to four more months learning how to code and and then transforming your life, doing something for yourself, right? It's nothing. It's 10% of the time you're spending, right? So you have no idea what what this opportunity might open up once you get past this this this pain. As someone who climbed out of this hole, I'm almost laughing now at how my mind was telling me I couldn't do it. Imposter syndrome, frustration, confusion, they're all just temporary clouds. You can't push through it. Okay, I hope my story and these tips help you on your own coding journey. Proell might feel like a trap, but it's actually more like a cocoon, right? If you do the work, you will emerge with real skills ready to build your own version of the future. So, go out there and start coding something today. No matter how small, just start. As the saying goes, the best time to plant a tree was 20 years ago. The second best time is now, right? The same goes for learning how to code or learning a new skill for yourself. Start now. Good luck and happy coding. I am rooting for you.