The first extremely important thing to realize when starting to teach yourself how to code is that this journey is different for everyone. When I mentored for a major online bootcamp, some students would pick up things in days that would take others weeks. And sometimes the ones who took weeks to understand simple topics had jobs months before the ones with whom it clicked right away. There is no winning formula. These students went to the same bootcamp, at the same time, and had the same instructor, yet their experiences differed wildly. Measuring yourself up to others is a route to frustration. Instead, you should focus entirely within yourself, trying to become the best version of you that you can be. If you can achieve that, then it really doesn't matter how you stack up compared to others, because you will know you have lived to your fullest potential. I know this might not be what some of you want to hear. You want me to give you a number "In six months you can have the job of your dreams if you just do XY and Z". That's true, a lot of people can learn how to code in six months. A lot can't though, they have different circumstances and experiences.
Get Rich Quick
When I first started learning how to code, there was a hip new startup on the scene claiming that they could teach you how to code in an incredibly short amount of time. They were so confident about the timeline they named the company after it... Let's call them "TwoFortnights". Their whole mission statement revolved around being able to learn how to code in just 4 weeks. I never ended up using this product, I couldn't afford it, but it left an impression in my head that a good course would be able to teach me how to be a great programmer in just 4 weeks. This left me feeling like a total failure when 2 months into my coding journey it became obvious to me that I was nowhere near the level I needed to be to get a job. I was nervous that the cheap or free curriculum I was using was the problem, and it wasn't. In fact, there was no problem at all. I was learning how to program at a totally normal speed. However, I had let slick marketing convince me otherwise and it really tormented me.
Convinced there was a problem, I created one for myself like some twisted episode of That's So Raven. I hopped around from course to course convinced that time was of the essence. This was exacerbated by my living circumstances at the time. I was extremely poor (was homeless shortly prior) living with my girlfriend (now wife) who was having extreme complications with her Crohns disease. The more I panicked about all this, the worse the problem got. I know given this info it might seem like time really was of the essence, but it wasn't. It took me years to get into development, not weeks, not months.
If you told me how long it would have taken me to get into software development, that I would have to take the route I did, starting in QA, working to the bone to prove I could automate some tests, and doing that for years. I would have never started, and that would have been a terrible mistake. The time would have passed anyway, and who knows what I would be doing now. Either still working odd jobs to make ends meet, or worse, maybe back to living in my car or on the streets.
Long Haul
Instead of focusing on how quickly you can "get a job" you should set smaller more achievable goals, these goals should take about 2 weeks. If something takes longer than that, don't count it as a goal. That is a future aspiration to be reserved for "one day" in an indeterminate future. Not something to be focused on, just something that might inspire you in the background. You should leave this chapter thinking something like "In the next two weeks I will design and code the home page for a personal website" and not something like "My goal is to start my own company". This is important for a couple of reasons. The pie in the sky style goals of "get my dream job" is not clearly defined. What is your dream job? That is a goalpost that will move on a monthly basis. Aside from that even if your goal is clearly defined if it is too large by the time you realize you are not on track to hit it you have wasted months.
My advice is to forget about how long it might take you to get a job or start a company. Either decide that you want to learn to code, and accept that may take a very long time. Or decide you want to do something else (that will probably take a long time too). Basically I am saying, pick a direction to orient yourself where you will be happy with the eventual outcome independent of a timeline. For me, it was important to make lots of money from home, and looking back I realize I don't really care how long it took me to end up there. That is where I wanted to end up. If you have the same aspiration as me or another one that learning to code might fulfill then I think this is a good direction. If you want a guarantee then I have some terrible news for you.
Sprints not Marathons
Why did I pick two-week goals? For a few reasons, first and foremost. If you want to get a job in software development you will have to get used to "sprints" eventually. Sprints are focused two-week blocks of time where you take and estimate tasks and then are expected to finish them. Being able to gauge how much you can do in two weeks is actually a skill that is highly rewarded in software development. The earlier you develop this skill, the better it will be for your career. Second, I don't think people can really accurately estimate any more than two weeks out. To be honest, I am starting to think two weeks is a stretch itself, but one week is a bit too short and we need a stable, repeatable, measurable interval. Third, you need a timeline short enough to enter a cycle of iteration. At the end of the sprint, you should reflect on how it went. Did you achieve your goal? Did you come close? What could you have done better? What did you excel at? Then you use all of that information to make a new goal two weeks out and repeat. This process of reflecting and setting new goals is crucial to real growth. If your timeline is too long, and you don't enter an iterative process, you start to stagnate, weeks pass, they turn to months, then you realize you are nowhere near your "6-month" goal you set. You don't know where things went wrong or how to do better. Avoid this drift and set short focused goals.
I don't like the name sprint very much either, I think it evokes the wrong emotion but whatever I can't change the industry. I am not telling you that every two weeks you should go all out redlining yourself to get as much done as possible only to repeat it indefinitely. Each sprint should be a normal, non-overwhelming amount of work that you think you can accomplish in a two week period. This is much less about maximizing productivity and more about course correction. It is also a way for you to start gauging and measuring performance.
Honestly, it can be hard to know what you are capable of, and when you can't tell what you are capable of, it's impossible to tell if you are progressing. However, it is pretty easy to spot trends. Where these two weeks better or worse than the two weeks that proceeded that. You probably have a pretty clear answer to that. This is one of the major values of sprints, if you record those trends over time then viola, you can find out if you are improving, stagnating, or getting worse. Since tracking this is the real payoff, you need something to track your progress in. I suggest a journal of some sort alongside with eventually learning an industry-standard tracking tool, any of them would be fine, Jira, Monday, Asana, whatever, just pick one, wherever you work will probably use a different one anyway.