Speaker 1: How I plan my coding projects will often times vary. In a professional setting, everything's gotta be calculated, dialed down to the T. But when I work on my own projects, sometimes I'll just sketch something up, do a little bit of research. If I'm, you know, building a game, I have to understand the mechanics and then implementing an AI on that game. But then I really just get a loose understanding of it because up here I already know what I want and then I hop into my text editor and I start coding. Honestly, I find the latter to be the most enjoyable. When you're not really overthinking it, you don't have to pick out these little tasks to do and maybe that makes it a little bit easier, but I like just exploring with code and having fun with it and that's typically how I did it. But now I have found a slightly better way that I still have the enjoyment from the winging it aspect of doing my own projects, but a little bit more calculated, somewhere in between the professional setting in my own projects. And in this video, I'm taking you through that process. If you wanna help me out real quick, leave a like, subscribe. If you already subscribed, hit the bell. Now the vast majority of what I do is web development. So this will mostly pertain to web development. If you do any other type of development like mobile development or anything like that, then this will probably apply. I'll try to reference some of my other projects that I've done in the past, like the rebuilding a game and implementing an AI on that game and how I went about doing that because it is different. But I wanted to let you know out the gate that this will be mostly surrounding web development and particularly web app development. So I start out the same way as when I just wing it. I come in here, I draw out how I want that website to look. I don't know if y'all can see this. It may be blurry, but that's okay. But this is a little sketch that I did recently for a personal website that I plan to create for myself. I mean, it's not gonna necessarily be a full-on portfolio, if you will. I think it's gonna be more catered to my YouTube channel and that sort of online presence that I have. I'm going to just create a website to add onto that. It's kind of weird that I'm a web developer and I have a YouTube channel. I'm online, but I don't have my own personal website. So I figured I'm gonna build one, probably HTML, CSS, JavaScript, and yeah, that's probably it. We'll see what front-end framework, if I decide to pick one like React, we'll see. But if it's something like a game or something that you need to rebuild, that's already been done before, then you start doing research because you have to get a little bit of understanding of the mechanics. But not every idea I have up here comes to fruition. It has to be something that I really like that I plan to create in order to put pen to paper. After having the idea, that's step number one. And by drawing it out, that gives me an understanding of the layout, the flow, the different pages, and all that. I'm really not too worried about the minor details like the color or the border radius or the font, unless I'm absolutely certain this is how I want it. I kind of just push that off for later because that's something that can easily be changed. Now that I have this, I begin to do some research. What stack do I want to use? What frameworks? Front-end framework? Back-end? Do I need a database? Maybe an external API to pull in some data? Data? Data? Whatever needs to be a part of this, I do all of the research to get an idea of it first. But when rebuilding a game that already exists, I study the mechanics, the physics, the scoring system, anything that goes into the game that I need to replicate, I just do research on that because everything else is already laid out for me. But now that I have an understanding of how to go about it, I do go about it by figuring out exactly how I want to go about it first. So in the instance of a web application, a website, whatever it may be, where we have multiple different pages, which page do I want to build first? Typically, I've always leaned to the login and signup page. That's something that's part of my app because I like to go through the flow of how someone is going to come to that webpage and go from there. I want to start from the beginning and then just go to the end, just like you would when visiting the website and how I develop the website. But with Social Leader, I'm just working on a very basic MVP where it is a leaderboard of you all and no one needs to sign in right now. It's really just a single page application, so it was a pretty easy decision to make. I start off with that, but there are a few other nuances to this because it's not just a front-end application. I am doing a full-stack web app with Social Leader, so we need to pull in data from YouTube. We need to be able to put that data into a data structure that we can then pass to the front-end after storing it in a database because we don't want to have to formulate that data every single time, but then passing it to the front-end to then display on the web app. So we can't really create, we kind of can, but we can't really create the leaderboard until we have the data to populate the leaderboard, and you can't really do the data to populate the leaderboard until you have the overall app kind of put together what I just call the boilerplate. But with Social Leader, I'm not really going that route because I want a very simple, this is how you probably should go about it, I want a very simple MVP, minimum viable product, and I know exactly what I want to do with Social Leader. If you don't know, Social Leader is a leaderboard that I'm creating of people who comment on my videos and other people's videos, but more on that later. You probably already know about it. There's gonna be a lot more content about that here soon, so just stay tuned on that. Anyway, I know I wanted to pull in data, properly store it in a data structure and how I wanted to display it, and then pass it to the front-end and display it in leaderboard format. And that is the MVP, something I can bring to a small subset of my target audience and get feedback on. And it gives you a smaller scope to encourage you to get started. You may want 100 features in this application, but you don't know if those 100 features are necessary because you haven't gotten any feedback from your target audience. You gotta start with the bare minimum, get some feedback, go from there. That has been proven, tried and true in the industry as the best way to go about it. And at this moment, where you figured out the layout, the flow, the languages, the tech stack, and now what part of the app you want to build first, well, this is when some people would say you should lay everything out like a professional dev would. I disagree. Mock-ups and wireframes in Adobe XD, UML diagrams to visualize the system design in DIA, and split up everything into user stories and tasks to create your first sprint. Personally, at this stage of my career, which is the most experiences I've been across the board, I say you don't need to do that, for your personal projects, that is. Now is the best time to get started before you get bored with the project before you even start it. Because while many of these things are practiced in the professional world, a lot of it is to ensure that the entire team is on the same page. They have a visual understanding of the UI, the flow, the layout, they know what tasks need to be done next and in which order and who is doing what. But if you're doing this all by yourself, no team, then you don't have to worry about others understanding that because you do. And at the end of the day, the tools that they use aren't too hard to pick up on anyway. Adobe XD for wireframing and mock-ups, which you probably won't use anyway as a developer, Idea for UML system design, just watch a video that I created, very short video, years ago, and boom, now you know how to create UML diagrams. And the project management software, Jira, Asana, Monday, Issues, and the hundreds of others that seemingly pop up every single day, it's not that hard. But like always, at the end of the day, this is just one man's opinion from one man's experiences and what one man likes to do. If you find using those tools to improve your workflow, so be it. But don't feel the need to use these tools because you see everyone else doing it or because you want to learn how to use these tools before you get into the workforce because you can learn it easily, very easily. So all of that, just to say it's time to code. Just start off with the boilerplate for whatever stack and languages that you're using, understand the file structure that you wanna use, and begin your MVP. Just figure things out as you go. Research, pseudocode, and maybe even have a schedule. This is actually something that I have learned recently that is a big help because I'm a very sporadic individual. I'm not much of a scheduler. I like to do things when I feel like doing things. But if you can figure out a time slot every day, every other day, something that is fairly consistent so you don't spend 30 minutes to an hour trying to remember what you were doing the week before on this project, that'll be a huge help. Now, I would recommend against deadlines because you don't know how long this is gonna take. We try to estimate all these different tasks all we want, but again, I don't recommend you on your personal project need to do tasks. So don't set deadlines because once you miss a deadline, then you just stress out and you push it off, procrastinate the next time you have a time slot because you just are stuck and you don't know what to do. And you don't wanna be discouraged by missing deadlines. Just pick some time slots. Say I'm going to work on this for two hours that day, and whatever you get done, you get done. If you spend the whole day researching, you spend the whole day researching. If you get a lot done, you get a lot done. Just focus that time slot, no distractions on your project on a consistent basis, and you're already ahead of most of the other individuals trying to do the same thing. I'm just tired of the structure and it needs to be done like this or done like that or whatever it is that the industry says that you need to do. Screw all that. I'm gonna sound a little bit cliche saying this, but just treat coding a little bit more like an art than a science. Add a little finesse in there and don't be too strict on yourself. That's all I had to say. That's how I plan a coding project. Not too strict, just having fun with it. Oh, and one last tip if you made it this far, always leave yourself with something to do the next day. Take with that what you will, leave a like, subscribe, hit the bell, and I'll see y'all here soon. I'll see y'all here soon.