Learning programming fundamentals is a better way to go. That way, you can jump from lang to lang.
Starting is hard so congrats again.
Learning programming fundamentals is a better way to go. That way, you can jump from lang to lang.
Starting is hard so congrats again.
It's the same with computers. While some people may enjoy learning deductively about abstractions like algorithms and paradigms, studies have shown that most people learn inductively, by having something they want to do and figuring out what to do.
Truth is, you first learn the basics of speech communication. You understand sounds come from your mouth and given a specific cadence and tone you can form words to get what you want. This is no different than understanding the basic principals of computer programming. Principals all computer languages use. Specifics of the language (syntax, grammar, spelling) is something that can be mastered later, but without the principals, you're not going to master anything. This is a major reason why there are so many bad PHP examples out there. People don't learn to program, they learn to write PHP code poorly.
Spend more time around young children. They most definitely do not learn grammar before they can communicate. It is not a linear thing at all. People pick up parts of grammar like the Subject Verb Object syntax as they learn to mimmic diction and build vocabulary. They're constantly "wrong" and need to be corrected. With persistence and practice and, most importantly, interest, we acquire taste and style.
Communication is very much a trial and error kind of learning that is holistic rather than linear. "Learn x, then do y" versus "do y, then learn x" is a false dichotomy.
But there's a bit of this I agree with: don't get focused on just one language. Once you can get basic stuff done in one language, it's worth learning how to do stuff in a different language. For me, the second language was almost as hard as the first, but after that it got a lot easier.
(Which is not to say that I don't think fundamentals are important: I'd suggest eventually hitting the core algorithms, data structures, computer architecture stuff—even if it doesn't seem immediately relevant—as well as playing around with more out-there stuff (Prolog was always a favorite of mine). But I don't think all that's going to be interesting at first to someone who's just getting started out of a practical, "I want to build something", not a "I want to learn all of this!", motivation.)
Learning the fundamentals doesn't mean not doing actual programming at the same time. You have to code to have a better understanding on the fundamentals.
My personal experience is that after many years of programming, the fundamentals I learned in school still help me get better. There were many such moments that you were digging into some interesting technical topic and you suddenly realized that some fundamentals had another layer of meaning or application you didn't know or I didn't fully understand before.
Also, understanding different types of programming languages, like OOP, FP, logic programming, declarative programming, etc. help improving one's programming skills, no matter what programming you primarily use at work.
* Computer Architecture
* Operating Systems
* Algorithms
* Data Structures
* Database Fundamentals
* etc.
In addition, more seminal-yet-not-directly-practical books such as SICP are quite valuable. I've been meaning to read TECS (a copy of which is staring at me as we speak), however I have not had the time to devote to its projects yet.Edited to add :
In addition, reading up on web application architecture was quite helpful. This is increasingly important as modern frameworks may otherwise abstract away concepts to the point of making them very black-boxy.
That said, my goal was not to rush towards an MVP or prototype. I intend to be a competent developer first, and a founder second. If these were reversed, I might well have adopted the OP's approach instead.
I don't think anyone is challenging the value of studying those topics. It just seems to be general consensus you don't start with them.
Personally, the challenge of learning the more base knowledge and gaining a deeper understanding of computer science is that until you are really good at making things, you honestly cannot tell the difference.
I readily admit that I may suffer from some bias in this regard, since I find more abstract topics to be a lot of fun. There are many roads to Rome, however this is one that I personally found to be useful.
I was focused on my own experience and the experience I've had with the majority. Generalization and such.
[1] Tagent: am I the only one who hates "code" as a verb and "coder" as a noun? It makes it sound so rote, and reminds me of "code monkey." I'll take programmer/developer/hacker/engineer.
Learning the fundamentals is important, but one must put the theories in to practice by learning a language, writing some code, making mistakes, correcting them, and learning how the fundamentals work in practice.
My example would be: when was the last time you implemented your own merge sort?
True that my knowledge of algorithms benefits me, but maybe all I need to know is that it sorts an unsorted array.
In the end, the best approach most likely depends on the person. Some people need to understand things fully, at the lowest level before they can build on them. Others need to see something in use and be able to play with it to wrap their minds around it. I know I'm personally a combination of the two.
Regardless of the type of person you are though, I think everyone is advocating that you do something to get the ball rolling.
Learning to code, means being able to write a o(n^2) sort, not necessarily being able to tell why that algorithm is bad, or what O(n^2) means.
I think a better way to start is by learning the fundamentals like: - variable declarations - if statements - loops - functions
Those fundamentals are the same whether you're doing backend coding or frontend javascript.
Remember, it's all syntax.
But I think all self-taught programmers (of which I am one) should set aside some time for the fundamentals once productive in one language.