Learning to Learn

>you need to find the very best learning resource there is. This is a must.

I think there's a line around "good enough", unless your goal of course is to be on the road to "become the very best". I think the better metric is making sure you have a accurate resource over a quality one. The 15-20 hour "sprint hard" methodology isn't stopping after that first sprint, just slowing down.

So if you find/can now access a better resource later, just start the sprint again on that. I know from experience (in real time, unfortunately) how easily "find the best resource" can end up becoming "spend weeks collecting resources but not consuming them".

The other problem is: How do you recognize what is "good enough" if you lack the skills/competence required to be able to say "this is good enough"?

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?

^ This is exactly it. It's Dunning-Kruger.

I understand the struggle but may not be able to offer an exact solution. People usually expect you to just throw something together without structure, but if you don't have preliminary experience with doing anything similar at all, you are stuck with a blank piece of paper and no ideas, and it feels absolutely terrible.

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.

I'm giving a C# class at a university-like institute (for the first time in my life) and I'm glad I had the time to learn the language while it evolved over the last 15 years. Learning nowadays is daunting because of the size of the language and the N ways to do even simple things. You also need to understand the programming landscape before C# (mostly C and Java) to understand some decisions made by language designers.

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.

>then reach out to Reddit or some other community for resources, to receive the commonsense advice "just build something"

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.

I ran into this issue when diving into the world of Rust. What ended up getting me to move forward was asking Claude/4o to design a curriculum that would teach me the basics in a way would lead to completion of a project I had in mind.

I ended up dropping 4o and going exclusively with Claude. Claude is amazing at teaching.

By the very fact that the resource is "good enough" implies that it won't have the holistic and beginner-tolerance required of a good instruction set.

A great text will get you upto beinngin in 2 weeks - month. A "good enough" will mean a year if it isn't your primary focus.

Try learning RL from any other text than Barto-Sutton.

Get in front of an expert and ask them what they should have read first.

In most fields the best will know. And the process of getting inf ront of the best will also teach you about the field.

Well yeah. Time and budget can be limited. The "best" way to learn a language is to travel to a country native to it and immerse yourself, constantly attempting to speak to others. But that may not be accessible in time nor costs to travel and live. The "best way" to learn many topics is to immerse in a community that's a mix of learners or experts. ie. A classroom setting. A place to constantly iterate and quickly correct mistakes. But education is only getting more expensive, and not all communities are equal.

If there's a great beginner textbook out there, that can definitely help. But not every field has its Bart-Sutton easily accessible. But the time it takes doesn't necessarily matter as much as the mastery itself.