Just a word of caution about training. Many courses will really hold your hand and feed you the next step. I don't believe that prepares you for real world prog

Just a word of caution about training. Many courses will really hold your hand and feed you the next step. I don't believe that prepares you for real world programming or problem solving. Not saying you don't want to take advantage of courses to nail down core understanding, but it will not be at all sufficient. One of the first steps is to really learn how to use Google and the websites that come up such as documentation to search for and leverage information and tools to solve problems. This is a completely different way of working from many jobs such as finance, management, or perhaps even mechanical engineering 20 years ago. Where you might have a set of learned tools or approaches that you keep applying over and over. One example is this. If you pick a Python course from a few years ago, it might recommend a certain syntax or library that makes it harder for you to achieve a task down the line than it would be if you used a feature that had been invented within the last few months. It is really critical to have the mindset of accepting Google and online documentation or articles as your friend and ally and not some kind of weakness when you consult it. But to go back to the first part, you will want to find projects you can be relatively passionate about at least for a short time. Because programming is about being persistent and nailing down a lot of details. And you will need that level of interest to keep hammering at a problem. Also you need to practice approaching problems from scratch without knowing a preset approach. Rather you do the research as I suggested, try different things related to your specific problem, and really have to evaluate approaches based on experimentation rather than a pre-learned approach. Also you will have to practice interacting with users because requirements are the hardest and most important part of programming. There are two main traps: not listening to users carefully, or listening to them too carefully. Often programmers will dismiss feature requests because they seem too difficult, but sometimes these are the real value add for the business and can be achieved by leveraging existing tools and libraries. The other opposite problem which is very tricky is that users are often quite explicit in what they ask for, and those requests often completely misjudge the business requirements or inadvertently misrepresent them because they don't understand the technology. The trick is not to just take what they say, but actually understand the job they are trying to do, and use the feature requests as hints, but with a grain of salt. It's hard to do that and simultaneously really listen to what they say, because they can throw in quite critical information that needs to be interpreted properly in the midst of a lot of nonsense.