The Developing Developer

 Accepting Busyness I've been able to up the hours I'm putting into coding. I've been surpassing 6 hours a week pretty consistently. I'm proud to nearly double what I was putting in before. However, my hope to code on the weekends continues to be unrealized. The realities of being a responsible adult keep catching up with me on the weekend and coding keeps getting dropped in the juggling act. And that's okay. My goal is ambitious, but my current job is flexible. If I need another month (or two) before I've got the skills needed to land a job I'm really wanting, they will work with me. I'm really glad to have that kind of buffer, especially now that learning everything come January looks less and less realistic every week that goes by. Streamlining Processes I'm getting better at recognizing when I've hit a wall and then changing my approach to break through that wall. I'm in the midst of building a to do list web app and there's a lot of

 A Restaurant Page I just wrapped up my latest project: a simple website for a (made up) restaurant . The major things that consumed my time included wrapping my head around how to use webpack , remembering how to set up CSS for successful styling, and trying to isolate the different pages and elements. I enjoyed putting this project together, but I was a little discouraged by how long it took to complete the project. I worked on this project from the 15th to the 22nd of this month. I'm recognizing just how complex these projects can actually be an it's hard to recognize that doing well on the projects is part of why I'm behind on my goal of wrapping up this Odin Project JavaScript Course come January. Remembering Why CSS Can Drive Me Crazy A big sink hole of my time was remembering some CSS basics. I was having the worst time getting all my elements to center on the webpage. This led to an hour or more of trying everything I could think of, before remembering the simple

Creating the Timeline I finally crunched the numbers and I'm falling far behind on my deadline. I'd like to wrap up The Odin Project's JavaScript Course by December 18th (so that I have time to do some interview prep before I'm applying for jobs come January). Right now, I'm working on material that I should have wrapped up the week of September 19th. That puts me about 3 weeks behind on my 16 week (as of the beginning of September) schedule. It does not feel good to be that far behind. I'm hoping to log a lot more hours over the next few weeks to catch up and be "on schedule." Logging More Hours Over the last two weeks I've averaged 6 hours and 45 minutes a week. Pretty close to my hope of a 7 hour a week average! I've been able to cover more ground, but I'm also recognizing that spending time on the various projects can take up a week or so of my time. I'm considering dividing my time between projects and working through the articles

 Feeling The Heat Here's what I'm up against. There are eight modules, total, in the JavaScript section of The Odin Project's curriculum. I'm almost half-way through the second module. Now, it is true that this is the longest module (with 11 sections compared to an average of 5 section per module), but it's still jarring to realize that I only have 13 weeks and 3 days until January 1st has its debut. It's a lot of work (and pressure!) to learn, build projects with new knowledge, and then feel somewhat prepared to interview in a fairly short amount of time. Ramping Up So what does this mean practically? The minimum, is that I'll need to spend more time coding. I've been pretty consistently working on coding for around four and a half hours a week. I'm trying to set a new goal of an average of one hour a day. Which should give me more like seven hours a week. I'm hoping to be able to work my way through the remainder of the JavaScript section with

 A Personal Code Library I'm currently in the middle of the first project in The Odin Project's JavaScript Course . One of the things that I've been realizing as I've built a handful of projects is that I can reference code I've written before. This gives me a starting point for solving novel, but similar, problems that existed in previous projects. Unlike college, self-plagiarism is encouraged in this industry because there's no good arguments for working from scratch on each and every new project you come across in the programming world. It would just be a waste of time and energy. So, like a bad college student and a good programmer, I copy and paste code from previous projects. One Big Problem? Another aspect of coding that has stuck out to me recently is the reality that a large project is just a the process of solving a handful (or a lot!) of small, interconnected problems. In other words, big problems are rather modular, and you build the different parts

 Calculator Project The latest project I completed (this past weekend) was a basic working calculator . It turned out to be a bit more challenging than I initially expected. Part of that was my desire to jump in without fully digesting the initial instructions given to me. Once I reassessed the initial instructions, I got out of the first real rut I had found myself in. The main thing that this project centered around was how to hold onto all the different bits of data (numbers and operators) the user entered, and then having the math play out in the same order entered by the user. I had to figure how how to take in one thing at a time into an array, make sure multi-digit numbers were understood correctly, and then apply the correct operator to the numbers input. This was a lot of array manipulation and testing different combinations of multi-digit numbers and the different operators to make sure that different inputs would always give the right results.  Moving Forward The calculator