While some people prefer to get to know every tool in the toolbox before they start, others prefer to learn about them as they need them to solve a problem.
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 😃
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
Learn while I make - sometimes it's frustrating, sometimes things just work, in all cases you learn a ton more than imagining to build something while learning
I have over 20 years experience primarily developing line of business applications, for a UK clothing retailer. My mantra is good naming convention trumps everything!!
A bit of both, but I really find making whilst I learn most productive. It tends to sink in more, plus learning before you make is often based on contrived examples that mean you don't really learn it until you start to make anyway!
I personally prefer making while learning, simply because if I start reading too much stuff without really knowing what I'm doing it doesn't stick and quickly forget as I start focusing on figuring out how to make something out of what I learned, and maybe remember bits as I write code. So I usually get a rough idea of what I need to do, then add to my knowledge as I find obstacles or feel like something can be done better.
For 3 years been diving in head first. I only care if code can for my ideas and concepts. To me, it's much more gratifying to see something happening, it keeps me engaged.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
My feelings exactly
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:
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.2since you can figure out what 9 * sqrt(9) means.Divide and conquer.
I love this approach!
it works for pretty much everything. including those days for when your critical, programmatic thinking is in the toilet
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
Arraypage 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.
We are really similar hahaha, thanks for sharing your thoughts, Sine :D
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
Learn while I make - sometimes it's frustrating, sometimes things just work, in all cases you learn a ton more than imagining to build something while learning
A bit of both, but I really find making whilst I learn most productive. It tends to sink in more, plus learning before you make is often based on contrived examples that mean you don't really learn it until you start to make anyway!
I personally prefer making while learning, simply because if I start reading too much stuff without really knowing what I'm doing it doesn't stick and quickly forget as I start focusing on figuring out how to make something out of what I learned, and maybe remember bits as I write code. So I usually get a rough idea of what I need to do, then add to my knowledge as I find obstacles or feel like something can be done better.
both actually , but i do love learn then make
For 3 years been diving in head first. I only care if code can for my ideas and concepts. To me, it's much more gratifying to see something happening, it keeps me engaged.