This is my first post on dev.to but I really like the platform so I thought it'd make a good place to make this slightly charged post.
Developing ...
For further actions, you may consider blocking this person and/or reporting abuse
The non-linearity of the software path is incredibly underrated.
There are absolute "basics" I'm certain that I have blindspots towards. On the other hand, in some important areas in our field, I'm probably among the world's leading experts (which is a very weird thing to even think about).
A metaphor I've been kicking around in my head lately is that the software path is like the way an infant child learns. They sort of poke around the world with wide eyes, observing everything, touching things here and there, taking it all in, getting immersed in what it means to be human, and before they know it they're a functioning language-using walking person and can't even remember a time when they were not that way.
Agreed―and it's definitely a path and not a destination.
The infant child learning process is a good metaphor. The primary difference between learning to walk and learning software is that there is generally one type of way to walk (we learn from seeing those around us do it), but the software we might come across―by happenstance or situation or random choice―is practically infinite (and always growing).
That's likely why you (and I, and all of us) don't know the absolute basics in some (or more) areas, but feel an oddly uncomfortable level of expertise in others areas. This area of expertise can be thought of warmly as a superpower, or it can be viewed in opposition to the chasm of things we don't know to bring on a wonderful case of imposter syndrome.
I'm trying to remember that I literally can't know everything and focus on learning well the tools I need to accomplish the things I want to accomplish.
There are some underlying pressures to sort of know everything in this industry, and you need to remind yourself about the opposite.
You should check out Kathy Sierra's Making Badass Developers talk.
That's a great metaphor! I think it also quite accurately explains why it's generally really hard to teach beginner programming well. If a baby asked you how you learnt to walk from crawling you wouldn't be able to recall your experience, all you could answer with is the mechanics. Only by actually trying (and failing) multiple times will they learn.
"Graduate students are often disappointed to learn that their professors are human and that they don't have all the answer."
YES! Don't be afraid to dive in and break stuff. (On side things for learning. Not work stuff.)
If I have a thing I am learning at work I want more practice on, I make something related to that topic and let myself break it and twist it and do whatever I want with it in my free time. (I am someone who is always coding outside of work, so as far as I'm concerned it's a double win. I'd be less inclined to suggest this to someone who didn't already code outside of work, because then it's more like working-outside-of-work.)
I just don't learn well super linearly. I can sort of follow an outline, but I still need to basically jump to the end and work backwards and break everything as I go, so that when I learn it correctly I understand why those are correct, etc. I've had teachers gawk, one in particular who basically said (as he could see the commits etc) "You should slow down, you will have to rewrite most of that." to which I went "Yup, I know!" and indeed did have to rewrite most of it -- and learned infinitely more from it.
Your learning experience is not unique, and I'd say there's a danger in dismissing "how to learn" advice from seasoned developers. Having trained interns for over half a decade, I know from experience that, without exception, people learn programming best by doing. Theory without application falls short. Conversely, application without theory goes much farther, but you'll hit a wall sooner or later.
In short, you always need all of the following, ideally (but not necessarily) in this order, if not learned concurrently.
The line between "basic principles" and "advanced theory" is quite subjective: in short, the former is "it works", and the latter is "it works well." Premature optimization is the root of all evil, and all that.
As to what language and tools to learn first, that's answered only by your project needs and personal interests. But we learn everything in the same basic manner: do it.
I'm under no impression that my experience is unique and of course it's unwise to dismiss advice from experts.
I also completely agree with your 3 points which very succinctly describe my journey into Software Development.
The biggest thing that I was hoping people would get from this, which perhaps I should've tried to emphasise more in the post is that when I first tried learning new technologies, I did it the way I had my entire life the way the British education system taught me: read a book, read it again, do the thing. This didn't work when applying it to development and it led me to believe that developing just wasn't something for me but the problem was wholly the approach I went about it.
Sure, but that's more because the Western educational system is utterly broken. ;) That's a rather typical disillusionment once you get beyond secondary school, whether it be in the UK, US, or elsewhere; the system of study that was supposed to be so good fails to equip us to learn anything practical, and we have to start over. It's a good thing to be aware of, as you pointed out: "read, read again, do" doesn't work in coding; I'd just add that it doesn't work anywhere. "Do" must be relatively concurrent with "read/listen/watch" for it to stick.
Incidentally, effective primary school (and secondary school) math education doesn't even follow that broken formula: instead, you do the math problems both during class and after. Of course, note that I said "effective"...I've tutored many college students who experienced the "read, read again, do" formula for math, and as a result, required complete fundamental reeducation once they reached community college.
Learning programming is like riding a motor-cycle but also knowing the traffic rules. You must experience it practically and you must know different rules.
The community will ask you to learn the rules first. Of course they will because it makes sense. There are two ways to learn faster in that case.
1. Try and break things, learn by doing.
2. Learn the basics first, and then learn by doing.
Guess what will be faster and better?
Learning the very basics and then doing it. It will be faster because you will understand faster, and build something better.
Otherwise you are just learning how to ride the motorcycle, and killing people while trying to learn the traffic rules by yourself.
If you want a more proper answer, it would be trying to learn with the companies most valuable production code. Well, you should try to learn but not with the production code on line. Not if you can manage the risks.
There is another way to learn,
3. Learn and well, don't do it.
Well, that's what most people do. They don't learn because they are super lazy to do it. They read books, watch videos and that's all. No putting anything into practice because they are afraid of breaking and making mistakes.
Come on! You will make mistakes every now and then when riding the motorcycle, maybe you will break few rules. But if you learn rules and never put them into practice, you are gonna kill others.
Human lives wasted just because you were lazy. tsk tsk...
...umm well, learn basics, practice hard, finish this in 1 year, or, just try to do anything without any guide, maybe you will be able to finish the same amount of learning in 5 years, who knows.
Experience matters. If we don't learn from others experiences and also don't experience it ourselves, then we are not actually learning anything.
I understand the metaphor, however I do think it's a little over the top. There is a reason that you must pass a test to ride a motorcycle and as you say it's because you put lives at risk.
When you're learning how to code, an uncaught null pointer exception will not be the difference between life and death.
Of course there is software out there that literally is life and death stuff, but you need to pass an interview and be fully vetted before you get to that stage which you could equate to passing your motorcycle test.
To maybe take the analogy further than intended. A new learner who has just passed their test will be more dangerous on the road than someone who's been driving for 20+ years. Theory doesn't give you experience, but experience inherently leads itself to theory.
I used two different examples just to show how dangerous the thought is. Ofc I exaggerated a bit just to explain, but it's dangerous nonetheless.
It's like you want to learn to play guitar.
The only way to really master the guitar is through HARD practices.
But you really need a good "teacher" to speed up the learning process.
In the end, without practice, you don't master anything.
I really don't know what the take away from this piece here is, but mostly I would say I strongly disagree.
First of all: Yes you learn the most by doing things yourself and even more important you learn by doing mistakes on yourself, however: As far as I'm concerned that's really how every course back in my university time was structured and also every book considered as being the reference for ENTER_TECHNOLOGY_HERE I've seen so far has examples and advices you to try on your on.
Figuring out stuff on yourself does only help you so much, since you can spent hilarious amounts of times on certain problems you don't understand correctly (since you don't understand the underlying theory or technology) or even, because you are not able to use the correct phrasing to express your problems to a search machine simply because you lack the correct vocabulary. Even worse, you might embedd incorrect imaginations of how certain things work. This can lead to so called "cargo cult programming".
All of the above can extremly hinder your progress in acquiring new skills and / or knowledge. Learning programming / some framework / a language can (IMHO) only go side by side with learning the related theory.
So yes: You may not learn only by consuming the theory, but you also have to practice. Even more important, you have to find which parts can be blanked out because they are currently not relevant (certain parts of java script in your above example), but completly ditching theory can also hinder your progress.
Not directly related but I just saw someone asking for the best tutorial on X. For Me, all I expect from a tutorial is to tell me the syntaxes and something peculiar with the language or the framework.
You do not learn programming by watching a dude typing stuff on his screen over a video. Try things, break stuff and learn as you go.
I feel like learning, as long as you don't use just one resource with coding its ok.