For example, I'm a frontend developer who wants to learn backend. And let's say that I chose C# and .NET for this. I can either do tutorials in Microsoft docs and then reach out to Reddit or some other community for resources, to receive the commonsense advice "just build something", and we're back to zero because now the goal is to build something for learning's sake therefore what is "good enough project" to build to maximize gains?
An expert giving bad advice isn't going to help with your curriculum. To give a charitable interpretaion, forums like Reddit are very used to getting mostly Novices coming to ask questions. To the point where even if an advanced novice is asking about how to reach "Competent" level they will still give novice advice. And the best way to climb from novice to advance beginner is to "just build stuff".
There's definitely an open secret that there's plenty of novice material, and plenty of expert material. But the road to competent and proficient is basically a dead man's land for many subjects. I argue the curve to competent is harder than Proficient and Expert[0]. Such a hard point that you often won't find "best resources" without either education, consulting an expert, or simply work a job in that topic.
I don't have much better advice if you are seeking resources. But the next step up if you get stumped is to put more effort into finding other experts who will help out. try to email those potentially open to give advice on what to find or what's good/bad. Join communities similar to what domains you want to explore and form relationships. If you are getting to that point, offer to help contribute to projects others are working on.
[0]: Expert is steeper, but by that point you have a good sense of judgement to figure out what is a good or bad resource to study from. So it's "easier" to learn how to learn by this point.
As much as I like learning by myself, sometimes I have to admit that taking (and paying) for a class is the good solution. The way I organize notions for my students would take them months/years to understand by themselves, if at all.
I ended up dropping 4o and going exclusively with Claude. Claude is amazing at teaching.
In most fields the best will know. And the process of getting inf ront of the best will also teach you about the field.
I don't know what works for you, but what worked for me was finding open-source projects in a domain I'm looking to write an application or a library in and using them as a reference. With time, you become able to determine which ones are of high quality and are a good example, and which ones are not. You could also ask Claude/ChatGPT for references to starting point.
On C# specifically, I can recommend looking at https://github.com/bitwarden/server which is more "traditional" style but does not have much nonsense/bloat you would usually see in an enterprise codebase. That's what I always reference as a style and project layout guide for newcomers that don't already know how they want the project to look. And then as you go through the code, you can always dump the snippets into a chatbot and then cross-reference the replies with documentation if needed. Chatbots also great at quickly sketching up project structure - it can be a terrible one but it's easier to do "hey, I don't like this, let's change it to X" than trying to come up with everything from the scratch.
If you already have experience with writing TS-based applications with e.g. React components, base router, etc., you can more or less translate this onto structuring an ASP.NET Core application with controller/api handlers, model classes, services, ORM layer and similar. There really is no true right or wrong singular way of doing it, and people who claim there is are dogmatics from a cargo cult.
In general, a lot of C# code out there that you will encounter will take more steps to solve its task than strictly necessary, as the generational trauma of ungodly horrors of 666-layer "Clean" architecture DDD-done-badly monoliths still haunts many, manifesting in a milder form of "write a small three file microservice as a 40-file three-project solution". It is highly useful to approach new patterns and anything that seems ceremoneous with "is this abstraction strictly required or can this piece be removed and done in a few lines of code or maybe a method?".
On tooling - can strongly recommend using .NET CLI which will be very familiar after using NPM and co.:
Create new projects/solutions with 'dotnet new {template name}' (e.g. console, classlib, sln, gitignore).
Add/remove projects to/from a solution with dotnet sln add/remove
Add dependencies with 'dotnet add package PackageName' or 'dotnet add reference path/to/project' if you want to combine multiple projects.
Run projects with 'dotnet run' (-C release). Hot-reload for most scenarios is possible with 'dotnet watch'. Publish into a final complete application with 'dotnet publish -o {path}'. There are many ways to do the last one, but for simple back-ends doing the default output and then copying it to a "runtime" image in a dockerfile will suffice.
