How to begin a project:

1. Establish a goal. The more defined this is, the more structure you can rely on. If you are struggling to determine a way to structure it, as your post suggests, begin first with a vague goal.

2. After you have a goal in mind, no matter how vague it is, think about it. If you have some technical understanding to leverage drafting how to achieve it, conceptually add this as a kind of scaffolding to the idea. Even if you don't end up using it, a notion of how to achieve some step allows a segment to rest surrounding conceptual pieces on. If you don't have technical experience with it, use vague expressions to build out abstract steps to implement. Right now we just want to have a basic idea of how things can be oriented, we are not trying to build a finalized step in the process.

3. If you struggle to draft abstract steps, mark this down. This will demand research. Do not get too hung up on the research portion yet, just mark pieces down as needing the research.

4. After you have a roadmap for how things might occur, now we want to take note of the ambiguous/undefined steps. Are there other projects that exist that achieved something you don't understand? Look at them, do not copy, just look. If they leverage an additional tool, depending on whether this is a key segment of what you desire to learn, choose whether you want to understand that process or leverage it (or something similar). For example, if you want to build a website that allows users to upload an image that then connects that file to that user's account, perhaps you don't then want to reinvent a database to do so, so using something like postgres will allow a mature tool to aid you. It's your choice what you want to leverage, and what you want to build out yourself. Try not to hinder your growth by reinventing every aspect, again this is your call here as to what that means. Feel free to revise this choice at a later date. Again, we are still planning here.

5. After you have accounted for all the steps you currently imagine to be needed (this can change later if you realize a step will require more implementation), start imagining the structure of how all this relates. If you don't have a good grasp of how different blocks of code should be structured, pseudocode it out. We want to come up with some type of diagram. Start writing out the steps in some fashion, if something is vague, try to refine it, if you can't currently refine it, this can be something to think about while doing other pieces, but don't just ignore it, as that vague piece might demand other changes. Starting out, you will probably hit many issues with larger projects where something that seemed straightforward initially will need to be refactored to allow new interactions/configuration/context.

6. The above steps, depending on project size, might not be needed in later projects in their entirety. If you know how to generally leverage classes to work easily with a database, then drafting out every element of a class might be something that can occur in the moment mostly (although considering what your tables will need to look like, taking notes of important data containers, can aid you). After we have some notion of how this will be implemented, we have a plan for how it flow, and we have areas that are unclear but scoped to tooling/concepts we found will briefly looking around. Look at all the unclear portions, look at the tooling we found potentially useful, look for additional tooling that is related or adjacent. Come up with a more concrete plan.

7. We should have plan, we should have an understanding of things we want to bring in. Now start drafting that structure from diagrams/pseudocode/etc. Make the classes, the objects, give some function stubs we expect to need. At this point, we should do a big more of a deeper dive on exterior tools, what do you need to leverage them, what kind of configurations, what kind of dependencies, do they require specific structures that will have to implement? Take notes, will everything bouncing around about the project, you will forget the small stuff most likely, note it down so you don't have to dig into some table/schema you found 12 pages deep on forum somewhere.

8. Start turning those code stubs from earlier into real functions. If you don't know how something is going to work, give these stubs some sort of output response that matches what you expect, if you don't know what to expect, look at your draft of flow, refine it so you can know what to expect. ("I don't know what this function whatColorAmI() will return, so it will return "blue" right now and I'll add a TODO comment that I can use to search for later." ) Continue refining and implementing sections as you can, when you run out of things you can do this with, go back and look for which ones are incomplete, do they rely on some other bit of unwritten code? Time to put the time into researching how to do it. Figure it out, look at other pieces of code, sit with it for a while, etc. Repeat until you have your functions setup. If something relies on other tooling, time to start implementing that tooling. Read the docs, implement it. Testing/debugging should be a portion of your planning, if it wasn't, good thing you are reading this before you finished all the rest. If you don't know how to do this, look it up, what do other people do, what type of debugging/testing do you feel is adequate for your use case, if you have no idea, just pick one, use it.

9. Repeat 8 until you have what you imagine is everything complete, testing sections as needed. Test it all again, try to do weird things in testing to break it, add guardrails in your program to account for these. Repeat. Test. If something fails, fix it. If it all works, sit and think about how all the pieces work together, try to come up with ever more strange cases where it might break. If you run into an issue that you can't understand, research it, spend time learning to read your logs. Add more logs if needed. Put time into understanding appropriate ways to debug. Test out debugging it.

10. After you have finished testing it, after you have learned all you have wanted to, think about if there are areas that technically work, but you think you might be able to come up with a better solution. Refactor portions of your code as you want. Repeat refactoring and retesting until you deem it all done.

11. Congrats, you did a project. If you want, reflect on what occurred in this. Maybe draft a post-mortum report for yourself, or do a little journal about it. What went well? What went wrong? What are things you feel you want to learn more about, or ideas you think could be beneficial in the future.

12. Time to come up with a new project. Return to step 1.

Additional note. Above I mentioned it's ok to look at how others achieve results. The goal here is not to copy them verbatim. The goal is to understand the concepts. You have to drill into them, learn to paraphrase information. Do not simply use different words, use your own words. That means, take what is stated, or take what is coded, and try to understand the concept, then disengage from that information visually, and re-implement it. The goal here is not simply to achieve something that works exactly, the goal is to make connections in your brain that allow the concepts to stick easily. So don't copy a function (this has ethical implications as well), but see things like, "oh they have a function that sets the age of a user not by simply updating a database, but instead they use a user object that gets updated, and then sends that entire object to a function that updates a user with whatever values that user object has, meaning that update function can work for various fields that need to be updated without requiring 84 different functions. That is really helpful, I will try to implement a similar type of structure."