Make while learning or learning before you make?

Unless you start making you're not really learning. And I know I'm often so paralysed by choices that I just put off the making to another day and pointlessly consume another tutorial where I don't really have to take any responsibility.

i want to learn the very basic fundamentals before i make, then after i have fundamentals, i learn while making. for example:

suppose i want to write a function in js that adds two numbers. to someone new to js but not new to scripting or programming, it should be easy to pick up on. this is important. languages usually share these things:

keyword name parentheses variable parentheses
curly brace
do a thing semicolon
curly brace

name parentheses parameter parentheses semicolon

and if not directly or explicitly these, then they have a similar graph like chronological order to them.

i pick up new languages, libraries, and frameworks really quickly because i brush up on the fundamentals before i go in. then i let my lack of focus do its job and i just wander about, learning small skills very quickly all at once while looking for a bigger goal because ive got the fundamentals acquired to learn on top of

you cant learn how to sqrt(9) until you know what sqrt() means, what 9 means, and what math is. but if you know these things, you can figure out sqrt(9 * sqrt(9). in this case it equals ~5.2 since you can figure out what 9 * sqrt(9) means.

Assuming I have the time to do it as I prefer, I like to have a very, very, very vague idea of something before I go in -- and I mean something as vague as "I should open up the Array page of the docs probably" -- and start to code-sketch as I go and see what blocks I hit. I draw up with what I know already and start seeing where the issues are, which lets me know where to start focusing and what to start digging into. Then, once I know what I want to be using, I will dive deep into that as I go, which pretty frequently involves making a bunch of wrapper objects/functions/whatever so I can see how I like things to fit, where the sore spots are, what are the errors I make over and over and how does that reflect my understanding, etc.

I like to have a pretty deep amount of research before diving into a project and then learning nuances. The biggest thing I never want to run into is not knowing what I don't know, so I think doing a bunch of reading prior to starting a project helps map out the technology a bit before using it.

Like, conceptually, I know a bunch of ES6+ features. But before my summer project, I'd never used them, and all TypeScript examples assume you're a master of ES6, so I had to do some digging. Since I had that inkling of a foundation, I've been able to Google things more effectively. I probably read too much about Angular before jumping into a real project on it, but I think the TypeScript side of it had a healthy balance of knowing parts of it but just enough to know what to Google.

That’s a great question and I actually do both. Going into a project without any prior knowledge it’s risky because you spend more time being stuck and frustrated than if you did some research first. This happened to me when I tried to get weather data from the OpenWeatherMap api, use axios, use vue and geolocation. I spent a good 3 days struggling with the results that I was getting because I did the bare minimum research.

On the upside I probably did learn way more struggling than getting a sure answer.

Now if you need to deliver something quickly it’s best to work with the tools you know to avoid wasting time trying figure out how to work with something - which usually could be fixed by a bit of research.

I guess the best would be a combination of both sides, use something new with something you know so you see progress and still struggle enough that you will learn something 😃

I prefer to learn while I make.

There is so much widespread knowledge out there nowadays about so many programming technologies that it makes it really easy to find good learning materials and examples.

I like looking at examples, but I always try to understand why someone wrote code the way that they did. I try to comprehend someone else's thought process so that I can determine the clearest path forward.

Ideally I try to learn as much as possible first. But in practice I've found that route to be really unfruitful but learning while making to really pay off. So, in my mind, at first I always thought learn as much as possible first. But in practice I've found the opposite to be more valuable. Now days I will basically do a beginner tutorial and get to the "hello world" level. Once I hit that point, I find something simple to make with whatever I'm learning ASAP. And if I have something work related to try and accomplish that forces me to learn, that is the best scenario...

I prefer a mix of both. Curiously, I find the harder subjects are easier for me to learn by making. Simply taking an example and learn by breaking it, then fixing what I broke has produced some quick results with sustained retention. This is then back filled by reading and expanding the example into the larger experience.

Code along classes have a place in this as well. Usually after the initial break fix cycle. Concurrently, there's a lot of additional reading on the subject.

well in my opinion making while learning is the best way to go, this way you can apply the knowledge you gain into the making of the thing your making and you will have a better understanding of the learning part.It is like "kill two birds with one stone"

I like to learn about big concepts, best practices, philosophy of the tech I’m about to use before diving into the project
And usually I learn how to really do things by making it
I believe having an idea of how to approach a project depending on the chosen technology and its design / architecture patterns is necessary to avoid a needed gigantic refactoring afterward