How You Should Optimize Your Time Learning to Code

Have you ever wondered how much time you should invest into different things when learning to code? Then this one's for you. I also shared advice and most importantly the right perspective for standing out in the job search.

---------------------------------------------------

💻 Learn Frontend (20% off): https://scrimba.com/the-frontend-developer-career-path-c0j?via=donthedeveloper
⚙️ Learn Backend (25% off): https://boot.dev/?promo=DONTHEDEVELOPER
🤖 Learn AI Engineering (20% off): https://scrimba.com/the-ai-engineer-path-c02v?via=donthedeveloper
🐱 Learn NestJS (free) - https://scrimba.com/nestjs-c0n7djgjma?via=donthedeveloper
🧠 Advanced Coding (40% off) - https://app.codecrafters.io/join?via=donthedeveloper

👥 1 on 1 Mentorship - https://calendly.com/donthedeveloper/coaching
👁️‍🗨️ Join Discord - https://discord.gg/TpQe2k8Ab3
🐦 Follow on X - https://x.com/thedonofcode
👾 Follow on Twitch - https://twitch.tv/donthedeveloper

Disclaimer: Some product links are affiliate links which means if you buy something I'll receive a small commission at no extra cost to you.

Transcript

Don Hansen: 0:00

If you're wondering how to structure your days, you know, to optimize your schedule while you're trying to become a developer, I want to share my tips for you. Now, in a lot of my videos, probably in the near future, I don't really want to make an outline. I feel like I went down this road of, you know, trying to like maybe create a blog post first or a detailed outline. Then it was a generic outline. And I find that the more that I have to do that, the less videos I record. I am just someone that needs to rant. So that's what I'm going to be doing in this video and a lot of future videos. Sometimes I'll have an outline, but mostly not. So yeah, there might be some dead air or I'm making mistakes. I don't care. We're going. So I see a lot of people that for good reason want to come up with a perfect schedule, right? To become a developer. I'm going to compartmentalize this here and here and here. And I'm going to create a bunch of modules throughout my day, and I'm going to create a pattern. And those are all really good things. But I before I go into this, I want to stress that it's okay to go outside those bounds, but you need to know yourself. If you are someone that does really well with momentum, right? You like linking those chains, and then when one of them is broken, throws everything off. I'm like that. And that's kind of harder. So I like a consistent schedule. And each day I actually like to give myself a little bit more freedom in the day for, you know, just hanging out, chilling, and not like not work stuff. And then I'll actually work on the weekends as well, usually. That works best for me. But that's one of the most important things. You have to recognize like, do you just like do you need like a purpose every single day for work? Do you just like a consistent pattern or not? You should test that out. Some people like the weekend off, some people don't. Some people, you know, they can only hang out with their family during the weekend or whatever. You you have your circumstances, but these kind of things you have to test the waters and figure out if it works for you. So if you're trying to figure out like, do I code during the week? Do I code in the weekend? Only you can figure that out. You just got to test it out and be consistent over many weeks and see if it works for you, and then try something different. But let's go by your daily tasks. In the beginning, when you are first learning to code, let's say maybe the first three to six months, unless you're like coding boot camp style and you're like kind of cramming a lot of stuff, you have a lot of hours, which a lot of stuff doesn't get retained that way. But if you um let's just say you're the average aspiring developer and you are going through courses, you're learning, we'll just use front end as an example. You're learning HTML and then CSS, and then you kind of like start building some landing pages. So you went through a small course, you build a couple landing pages, and then you start going into more advanced CSS stuff, right? So you got a taste of like getting something on the page. Now we're going back through more course stuff, and we want to learn more advanced CSS techniques, or like to really flush out a layout very well, or dive into different ways of structuring a layout. And maybe now we start learning flexbox. Now we start learning CSS grid. Um, again, you don't have to rush it. I think a big mistake people make in the beginning is they just cram that they just all these concepts that they gotta learn. Um, whether it be flexbox or CSS grid or the block model or anything else, like just semantic HTML, or maybe they start learning JavaScript and they're trying to remember functions. I think people too often treat it like a checkbox. Okay, now I learned this. Okay, this is on the next, this is on the timeline. Now this is on the timeline, now this is on the timeline. So as long as I go in order and I learn these things, then I'll eventually get a dev job. But you never use them. And that is sad because people will dump years into doing this and just learning, getting certificates. But they never build anything with it, they never use it, they never really learn why they need it. They just learn it and kind of use it to just sl quickly reinforce it and then they forget it and move on, right? You you have to break out of that traditional educational model and fucking build stuff. Like you have to use it in a practical way. You have to think through the implementation and why are you using this implementation in this project, in that context that requires that implementation of the project, it further solidifies this concept. The more you can think about and use these concepts, and then be able to explain it to other people, the more it gets reinforced. So, why did I tell you all of that? Because if we're looking at an eight-hour day, you shouldn't be spending more than two hours learning. Two hours tops. Two hours is a long time, it's a lot of material. Now, I'm talking about like two hours kind of just going through a guided course. If you are really stuck on this concept and you are really drilling it in, maybe you're learning classes, and you learn, and then you maybe read like a different way of implementing classes. Okay, now what are classes used for? Um, and you practice a little bit in between, and you're actually coding, and you are moving out of the perfectly curated, gamified environment that is this interactive editor, and you are forcing yourself to think outside of that context, and your brain has to work a little bit harder to understand what it what you're trying to implement because you've trained it to just kind of memorize things with this perfect editor and um that auto-fills everything, that auto-completes everything, that auto-hints at everything, right? So this is why, like, when you like people say, I can't believe like people are expecting me to write it down. Well, like actually going out of your code editor and writing down an algorithm or something like that showcases that you actually really know it. Because you would be surprised at how comfortable you get at memorization that creates an illusion that you think you understand it and you don't. And forcing you into a different context to then think about this implementation and then execute on it, it is really hard. There, this is why, like DSA stuff, I find there's a lot of practicality to it, depending on how it's tested. I think most companies shouldn't be testing for like dumb niche algorithms, but a lot of the DSA stuff, it gets you to use a lot of your syntax in a way that um might be a little out of bounds of what you're used to. But if you understand the fundamentals, you understand the building blocks, you can do very well starting off with DSA stuff. You still want to practice, but there's some practicality to that. Two hours learning, two hours going through articles on a course, max. If you don't hit that time, it'll be even better. You are spending four hours building, building, building, and building. And so I might shift this around a little bit because I didn't plan this, but we have now we're gonna shift it. We're shifting it already. We're gonna say maybe about like an hour and a half of learning, and maybe three and a half hours of just building. And I would say project here. Here's what I'll do. Here's what I'll do. I think this is gonna be better, and I've seen this be better for a lot of people. I think in the beginning, you're gonna be spending more time in the in your actual course, about two hours, and you're probably gonna spend about the same amount of time outside the course practicing what you're learning. That's four hours of learning and practicing. That is going to take more mental energy than you think. And you some people force themselves to go way longer. Retention is scarce. I find for the average person, retention tends to be scarce after four hours. Now, when you kind of learn enough fundamentals to be building basic things, building basic sites, a lot of people might start with their portfolio. Why not? Easy concept to practice kind of just some HML and CSS and a little bit of JavaScript. Um, but you're eventually going to shift into like an hour, hour and a half of learning max, and like three and a half hours of project work. Project work, it does not feel like it takes the same mental energy that it does with the learning. They're just different. By the way, if you are diving deep into Node and you've already built a few things with Express, it might be time to challenge yourself with a more scalable framework, NSJS. It's one of the most popular frameworks for Node, and I personally use it to build my projects. It's one of the reasons why I decided to build a course for it, to get people up to speed with the basics. Find that course at Scrimba.com. Oh, it's also free. If you use my link in the description to sign up for Scrimba and you decide to upgrade to the pro plan, which unlocks a ton of different courses, you actually get a discount. Again, I partner with them because they are actually really good at building up junior developers. Check it out. What do you have to lose? Now let's get back to the video. And you'll find that even when you are struggling to build something, as long as you start having fun with it, it just gets so much easier. And I find when people start getting things to appear on the page finally, and they're finally getting their bugs to work, and they're finally kind of getting more success rates with CSS, and they're finally just building something. You kind of just see it building slowly over time. I find that's when people start having more enjoyment with it. If you are finding a lot more enjoyment in the learning, the platform itself, that is just a dopamine trap. And be careful about it. It's very easy to make the reason why you like it is because you feel like you're making progress when you're making very little going through that coursework. Very little. And you have to remind yourself of that. You want to get to a point where you're enjoying the project work, even if it's simple stuff. But you should be building a project. And so this stays consistent for a long time. So let's say we've like gone through the course stuff, we've done some challenges, small things on the side, and then three months in, now we're ready to build our first project. It should be about like an hour, hour and a half of learning, and then three and a half hours of project work, maybe four. Um, but what you're gonna find is you'll start probably leaning into project work a little bit more and it's fun, and you wanna be careful about the trap of not putting yourself out there to start learning how to navigate the job hunting thing. It's a career in itself. It it's um it is something that is truly underestimated, and it's just a whole like the I have never seen a coding boot camp. I have never seen um self-taught courses, even the people that are the my partners, my affiliate partners, I would flush out a way more thorough job hunting program with them. It's just always so short. There's so much to it. I don't envy people having to learn it. The only reason I know it so well is because I've been focused on it for eight years and I went through the job hunt myself uh for two years. I made a crap load of mistakes too. Um, I don't envy people. Again, is why I want to build that course to just solidify everything. But you have to put some time into it. And so, what does that mean? That means once you get your first project up, you're applying to positions. I think sometimes people get trapped into like just mass applying for positions, and there's just this mentality of like, we're just throwing spaghetti at the wall. It's one of the worst ways that you can do it. It's why positions are getting a thousand applications per, and it's just annoying employers. You have to have a very targeted approach. You can blend your old industry in, you can build projects for your old industry, and then you have experience in that old industry, you can apply for those positions, right? Um, it you should be aiming for companies where you're gonna be building stuff that you want to build, problems that you want to solve. Like, what the hell do you want to solve in tech? That should be a question that you eventually should answer, especially around the time, preferably way earlier, but around the time you start looking for a job. Around the time when that first, well, actually, your first few projects are probably gonna be templated projects just to reinforce things, anyways. But, you know, when you're building that capstone project, you really should know what kind of problems you want to solve because your capstone project should speak to that. Templated capstone project tempted or templated main projects on your portfolio, they don't work. Everyone does them, they don't work. You're competing with everyone else that's doing the same damn thing. You need that capstone project that is just truly this piece that represents the type of developer you are, honestly, a type of person you are based off of the problems you want to solve, and it just reflects your style and it's documented well. And it a lot of the technologies that you're using, it's going to easily be adaptable into whatever positions that you're applying to. You need to think about these things. But that is kind of part of the job hunt because you need to know what companies to apply to. You need to, like, if you're applying to more than 15 companies per week, you are doing it wrong. You are fucking up royally. You are just another developer that no one gives a fuck about because you have no focus, you uh you have no tailored applications, you're probably just using some chat GBT cover letter, you're not following up, you're not connecting with people in that industry, you are just another number that goes in the trash. When I say that, I mean your resume. You just you don't matter to companies. And so the perspective you need to have going into the job search needs to be one where you have a focus. You've kind of honed in on the things that you enjoy in tech, the problems that you want to solve, and you start using coding, you start becoming a better software engineer to be able to solve those problems better. And you showcase that through your capstone project, right? But very limited applications. If you want to do like one or two a day, that's good. That's good. That's really good because you should be spending a little bit of time, you know, researching companies. If you get it down, like you get it really optimized, you can spend for each application, you could spend maybe an hour or sorry, half an hour doing a little company research, see if there's alignment, and you're going to show that alignment in your cover letter. Um by the way, personalized cover letters do way better than templated. I don't know why people pay for cover letter services. Like everyone uses chat, or not not everyone, but the people that are failing use ChatGPT to generate all this templated garbage and they change things here and there. So it's more efficient. Everyone wants to be more efficient. Honestly, a less professional cover letter that is very much it shows your interest in the company, but it, you know, it's not the most professional or it's not the perfect template, is going to do way better than some templated garbage. There's just this exhaustion that recruiters get from reading AI crated cover letters. No one wants to read them. You're just the most unimpressive person on earth in that moment to them. It's just like you're so fucking boring. Stop being boring. That's my message. Like, stop being fucking boring with these job applications. How the hell are do you expect to stand out with these template-driven approaches? You're just not. Resume, it's a little bit different, right? I think there are a lot of good practices with resumes, but man, do most people fuck up the cover letters. You might as well not even do one. And then you're again you're just throwing spaghetti at the wall at that point. But an hour. Two job applications, a little research with a company. Um, and then also like spend a little bit of time like going to meetups, spend a little bit of time maybe contributing to open source, spend a little bit of time getting involved in dev communities, um, spend a little bit of time participating in a hackathon. And you could replace a lot of your personal projects with hackathon stuff. Like really cool projects come out of that. You get to work on a team, you get to show that you've worked on a team and you were able to work with other developers. But I want to really emphasize the chunk of your day is project work. It's just a little bit of learning, and even that hour and a half learning will start shortening, and you're gonna start doing targeted learning. I gotta look up this article because I don't really understand subgrid that well with CSS grid. I think that's what it's called. Really cool, by the way. Um, but you're just kind of gonna start with project work for the day, and then maybe like a half, like, you know, six months in, a year in, you're kind of starting with project work for the day, and then like a little bit of education on the side. Maybe it's like, well, you gotta learn Docker, but a good time to learn Docker is when your application is, you know, the MVP is finished, and now we need to figure out how to containerize it. Because a lot of companies, especially if you're going like applying for full stack or backend positions, like us to know how to deploy our application that is containerize. So you have the deployment part of it, which is another thing, but you have Docker. So you start learning these technologies as you need them. It's a it's just a perfect way to reinforce it so much more deeply and remember it. But you shift away from the education more towards project work, and this is a really important piece that most people just skip out on. Most of your days should be spent towards project work. I don't care if you're like a year in, two years in, three years in, five years in, if you aren't spending most of your days with project work or volunteering for like a free internship or participating in hackathons, like if you're not doing project work, what the fuck are you doing? Why do you think anything else is going to get you the depth of knowledge you need to stand out? How are you gonna build that really impressive capstone project? How do you expect to stand out from others? Obviously, you should be applying for jobs. And networking is still king. If you have meetups in the area, you should definitely, definitely go to developer meetups and just meet people, even if it's just a sanity check, like, hey, other people are struggling, and I get to just chat with people about this. I, you know, we get so siloed in just doing this on our own. I don't know about you, but I was like that. You know, I in Northwest Indiana, there's I think there's like one tech meetup, no programmers. I I don't know who to connect with. So what did I do? I streamed because I wanted to connect with some developers, and that was a cool way to do it. But that's like if you have an eight-hour day, I don't even know if the hours added up correctly. I don't even think I estimated like the half or the meetup time or anything like that. But I just want to emphasize it's really a small portion of the time that goes towards a job search, small portion of the time that goes towards the learning, big portion project work until you get a job. Now, what happens if you're working full-time? You know what? This video is long enough. I'm gonna save that for another video. And in fact, before I go to bed tonight, I'm gonna record that video. Because I have some thoughts on that. It's really hard. I was warning you right now, it is really hard. But I will I will share my thoughts on that. But I hope this helped, and I hope everything's going well with the job search. Hope you're building yourself up, building your projects up. No matter what, just don't stop. The only people that don't become developers are people that just give up.