There are so many benefits to jumping right in.
You’ll quickly get over any fear you may have of programming.
You’ll start seeing the fruits of your labor right away.
This did it for me. I've been having this exact same thought for the past two weeks. After hitting development bottlenecks on my last project, I committed to learning to code to the point where I could hack together functional prototypes. I've been training by manual, and was just speaking with a friend about how dry it is and the fact that I'd be more fulfilled working on a project and couldn't wait for that.
We have an extremely small, simple project that we've been talking about. Screw it. I'm dumping the book and starting on that as soon as I get home.
Plus Mig Reyes's quote "Just make a bunch of shit" or the more eloquent way that Ira Glass put it "the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions."
It is funny. I was talking to a kid that was learning to play guitar because he wanted to play cover songs, and was frustrated by the lessons that seemed to have nothing to do with what he wanted. I told him that he didn't have to wait even one more day, since playing covers songs is one of the best ways in which you learn guitar. His ultimate goal could be accomplished almost immediately by choosing one song he liked that only had 3 chords, and just strumming those three cords over and over again in succession until it didn't sound half bad. Would take less than a week, -tops.
It's the same principle, and one I value highly. I think tackling a new discipline, and the wave of information that rushes toward you as you put your toe in the water can sometimes distract us from simple grounded approaches that we know have worked well for us in the past.
I learned piano in a similar way. It was a lot of fun, and allows me to play some songs passably, but I still feel hobbled by not knowing certain basic techniques that I would have learned sooner in a more conventional set of lessons. Maybe it comes after the "project" type learning, but at some point, to move up, you have to learn the boring basics.
Agreed! I'm also a pianist, but because I started young, I was lucky that my parents and teacher forced to me practice technique all the time. You should check out the Liszt exercises, they will make you strong and fast: http://books.google.com/books/about/Liszt_Technical_Exercise...
With coding, there was no such outside pressure, so until I joined Yipit, I had tons of bad, hacky habits. In order to get to the next level, I had to rebuild from the ground up and learn the fundamentals really well.
I agree with this. I think the hardest part of learning a new skill is starting out. Working on a concrete problem provides a positive feedback loop that keeps you engaged, learning, and moving foreword. But that doesn't mean you should skip fundamentals.
For coding you could hammer out a project, get familiar with a language and the technologies you used to implement it, then download a Stanford lecture on proper Programming Methodology.
This is such a nice comment and I'm glad my post could help! Good luck hacking on that project. Let us know how it goes. I'm sure you will learn a ton :)
Great insight. Every time someone says, "I want to learn to code." They should have a project/task in mind and just go. The stack that Suneel lays out is a good foundation for web dev, but as he admits, he like many others invested more time than was necessary in books/documentation/tutorials.
More people need to just jump in. If you get to a point that you want a feature from jQuery, look it up and implement it, but don't feel like you need to wrap your mind around every feature before you can begin. Great work and keep at it.
>Every time someone says, "I want to learn to code." They should have a project/task in mind and just go.
If there was a list of software projects somewhere, ordered by difficulty, with tips on how to get started and how to extend it later, I would be very interested.
I can code (somewhat), but I find that any time I have an itch to scratch, it's much easier to google it and solve it through existing software and configuration changes. Every time I've had a project in mind, I'm quickly in over my head. I'd like to move beyond scripting and actually build self contained software I can post on Github and give to my friends, but I guess I don't know where is a reasonable place to start.
That's a nice list to help people when brainstorming. I wasn't necessarily implying that the project had to be something new or different, or even specific to the user. A lot of people learn rails or django by making some microblogging twitter clone. On a recent relevant topic, sometimes the best ideas come from emulation and slight modification, so maybe you just challenge yourself to replicate a site or web app you use.
The problem you're probably having is that you're saying, "I want THIS" and THIS is too big for you to imagine. So, just write a small subset, maybe 3% of that. Then you'll realize you can easily build this next little bit over here or over here and eventually get there.
Agreed. I am largely self taught as well, and have found a lot of value in reading texts on CS / programming fundamentals :
* 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.
What was the order of learning for loop, function and class? Did those proceed architecture, algorithms, data structures, etc...?
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.
We can certainly agree to disagree, but I don't think that being "really good at making things" is a pre-requisite to understanding some of the principles underlying said "things". In many ways they are related-yet-distinct disciplines (Computer Science vs. Software Engineering).
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 have some friends/colleagues like that, and they are a certainly a minority. All very deep thinkers and great to work with. I could see how learning all of the abstract material would help with that learning type, so I don't think we disagree. Everyone should use whatever approach works best for themselves. This is probably a better point than anything else.
I was focused on my own experience and the experience I've had with the majority. Generalization and such.
I disagree. You didn't learn to talk by studying rhetoric. You imitated sounds and words that people made around you. Then you started being able to express your own ideas. Then, maybe, you learned how to say things well.
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.
Human speech is a bad analogy. A better analogy would be grammar and spelling, which would make OP's argument stronger. The very argument you disagree with.
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.
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.
thats why cs courses has projects, to test the theories in to practice, the good thing about fundamentals is that it teaches you that the language its not an end for it self instead its just a tool to express yourself
True. I think there may be two camps though. It depends on if you want to learn and be able to master the fundamental theories that ground everything or have a more pragmatic approach where you accomplish things using tools you doesn't fully understand.
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.
Speaking only for myself, I "learned to code" six years before I got to college to study CS. CS taught me a bunch about what I was doing right and what I was doing wrong. My first paid programming job, as a senior/first-year master student taught me what all that meant when applied to what a business operation needs from its coders.
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 disagree (at least that this is universal). If you start with just fundamentals but no specific language, you can't whip up anything to play with. The amount I was able to learn easily without doing anything was quite low, so I'd say start with a language with a responsive interactive shell so that you can quickly see what things do for yourself, and (crucially) see what happens when you make small changes to whatever examples you might be looking at.
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.)
I would talk a more organic approach. Jump right in and when you come upon some bigger subject matter (sorting algorithms for instance), take a break and go study the subject a bit..
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.
We all have different ways of learning. When it comes to programming, learning the fundamentals first can save a lot of time and frustration. Not everyone can pick a language and start learning right away.
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.
I agree to an extent, but this shouldn't be construed to mean what I think is a bigger mistake that new programmers[1] make: bounce around from language to language when you're still trying to learn how to program. I made the same mistake when I was learning. The language is (largely) irrelevant, so by trying to learn Ruby when you've barely learned C (vice-versa, whatever), all you're doing is overloading yourself with syntax, when you should be focusing on nailing down the syntax of some language, (essentially) any language, so that you can begin to focus on learning how to program and not what the asterisk means in that context.
[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.
My biggest mistake was trying to decide which language was most suitable. I kept reading article after article about the advantages of ruby over python, or why nodejs is better than anything else.
In the end I just ended up writing my prototype in PHP (ironically the language that no one recommended - and most hated) simply because it was so simple to jump right in and get started. More so because PHP ran on the server I used to host my static HTML/CSS files.
My first side project is www.youfm.org and its doing great (150k hits, 40k uniques, hundreds of people spending over 5 hours on the site).
So the most important advice I can give is to just pick a language and dive right in. Don't worry about the right language, don't worry about which is the easiest to learn, or scales the best, or anything like that. Just pick any one and start coding.
I'd be wary of recommending Django to a beginner, unless their project definitely required it.
Flask is lightweight, simple, and you can understand most of it in a very short period of time. I'd say it taught you to code more, whereas Django teaches you to use Django.
As much it pains me to admit it, Nikes' "Just Do It" applies here (and in life) as the author has learned. The procrastination and anxiety that comes with tackling something new can be overwhelming. The task oriented approach narrows focus and makes you think about what you need to learn. Fear is also a great motivator especially when your lead is breathing down your neck with a 'JGID - just get it done' attitude. :)
YMMV But I typically do #1 when learning / starting anything I don't know about. That is I some proportional amount of time googling/wiki reading/pinging friends for all the info/standards/tools/libs around subject. Review* them for worth, spend more time with ones that pass.
It is very helpful to have a idea of the breadth of and resource for a subject.
Review typically means "experimental coding". The 2nd point "start coding now" is a Truism. Just don't start coding "production". Learn some, think, first.
I think the problem is a lot of people jump in, start coding and then never go back and learn about the nuances of a language.
Case in point was myself when I was learning Javascript. Sure, I could get the JS to do what I wanted, but it was clunky, used a lot of memory and was slow. Fast forward a few years and I've gone back and read Crockford's books several times, and with more studying, I've gotten much better at writing JS. I now try and make my JS as lean and as fast as possible. It's a totally different approach then when I started.
The problem is thinking once you know how to do something, you're done. Like a friend once told me, "You don't learn to be a programmer, you learn to be a student of the language you choose."
This goes hand-in-hand with people writing lots of code (especially when first starting out) and not reading much.
There seems to be a huge lack of people simply reading code to learn from it, rather than poring through dozens of recommended "Learn to Program in X in 7 Days!". A novelist probably reads more than they write; the same is rarely the case for programers (at least in my experience, especially in the case of people who are less pedantic than others).
However, had you not taken the road you did, the material you read much later on probably wouldn't have made much sense and probably could have made you turn away from it all right at the start, right?
You get excited when you see results right away. Once you do enough things that begin to make you wonder, "Gee, there's gotta be a way to do this faster or more efficiently." When your curiosity drives you to search for answers is when you delve much deeper into the nuances and the grit of a language that becomes important for scale.
You're right, there's always some retrospective bias, but I'll never get back those days of reading about PHP, since reading Python accomplished the same and actually was much nicer for a beginner. The truth is, your MVP will evolve and will require you to learn things, new languages and new technologies. The fun is never over. For me it's continuing and im so glad of that.
Well put. I've been programming professionally for 8 years (and as a student for another 8 years prior--HP48G RPN represent!). And to this day, I find myself regularly attracted to articles, books, and blog posts about "basic" lower-division CS topics: principles of object-oriented design, language design, patterns, compilers, etc. It's the same old stuff, but reading it is more enriching and insightful the more real-world programming experience you have.
yep. When I just started I struggled through GoF's Design Patterns and even sorta tricked myself into believing I understood it. Well, I didn't. At all. 5 years later though it was one of the most insightful and useful reads ever.
I agree that learning the nuances of languages is important, but to demand this aspect of learning to someone who is just beginning to code is actually harmful in my opinion.
As students of computer science, we have strong tendency to learn things bottom-up. We take care in learning the fundamentals before applying theories in real work. This is not a bad thing. Better quality codes are shipped and become more maintanable.
But for someone who is just starting out, the bottom-up approach becomes an insurmountable obstacle. As a result, many give up too soon and never end up enjoying the joy of creating real working applications.
Look back to when we first started to code. I wrote some bad BASIC code in high school abusing GOTO and GOSUB everywhere I could. I knew nothing about programming language paradigms or memeory management, but I had a lot of fun coding without reading any book on CS.
I don't know that #1 was a mistake. When getting into any new field, it is very hard to tell what is important and what isn't, what is a solution to the problem and what isn't. If you are in school, sure they'll guide you, but if you are self-learning, there is no really good filter. So learn about everything. Take a breadth-first approach. Some of the specifics you learn will be wrong, useless, or otherwise inappropriate. However, getting an understanding as to why they aren't relevant is in fact learning the field.
The more information about a topic you have in your head, the more likely you are to see the connections between subfields, how various bits are important and unique or just ho-hum standard implementations.
I regularly see people in some niche area say "look we have found this amazing new way to handle the data-flood", only to tell them they have reinvented NoSQL or a message queue, or a technique for dealing with matrices that the image processing or simulation folks have been doing for years (and all of them poorly, making recognizable mistakes). A breadth-first overview has much advantage.
Agreed. It's easy to look back and know what were needed in retrospect but it's hard to even know which is for what until some time is spent to learn its capabilities
Well, you need to know what is out there, and what is possible. So at least skim over some of the technologies. You could waste a lot of time if you didn't know say, Sass, existed.
There's also a timing problem. If you invest now, and learn technology T, then when you are in the middle of developing a project, the marginal cost of using T is very low. But if you are up to your neck in a project, and then need to take a week off to learn T, you are not likely to do so.
Personally, when re-starting my tech career I wish I had learned Java (or any JVM language) over PHP, PostgreSQL over MySQL, and Dojo over JQuery.
suneel, many people make this mistake. I went almost EXACTLY the same route you did. Although, I had already known HTML, CSS, and some Javascript, I was wildly unprepared for what I would encounter next just to learn how to get a working prototype. It basically took me 8 months before I got something running on Heroku. I went through four different Django books with some success here and there, including the Django Project's simple Poll tutorial three times without grasping it. Little to my understanding, all of it made sense once I used the book written by one of the creators of Django himself. I also used a lot of StackOverflow and the guys hanging out in #Python and #Django Freenode IRC channels were awesome!!!
The trial and error got me to learn a lot of things. In addition to the six things that you've listed, I forced myself to learn VIM as well. You probably use VirtualEnv, which you've forgotten to list.
Anyway, it's always good to see others going down the same road and sharing their experiences. Do you have some links to some of your early projects?
I disagree slightly, as I don't think that following that path of reading instead of jumping in is inherently worse.
Just jumping into writing code is great for motivational reasons because you'll have something tangible, something to be proud about and to help you get excited and keep learning. But you'll still lack insight in a lot of the surrounding environment, things that any programmer should know.
Attempting to do this the other way, reading as much as possible and as in depth as possible, will be good to give you some insight, but you'll have nothing to show for it until you start coding and it'll still take time for you to learn some stuff that can only really be understood with practice.
What I'm trying to get at is that it doesn't really matter how you start, as you are going to have to dedicate 10,000 hours to learn, polish and excel at any craft.
Start writing code, make it do what you need it to do today. This will focus your efforts to what you need to do at the present moment and you won't end up trying to figure out how to deploy an app you haven't built yet.
I've had a completely different experience. The first few times I tried to write code, I learned only what I needed to know for the specific app. I hated it. It seemed like I was just learning a bunch of random syntax and beating them into shape.
Later, I actually tried the textbook first approach, and this worked much better for me. By learning the framework and being able to observe the patterns, learning new commands was much easier and I could often guess at exactly what I'd need to do. I also remembered commands for much longer than I did with the first approach.
YMMV, but some people have more theory-centric learning styles and some have more application-centric. Test and figure out what works for you.
I wonder if the advent of web programming makes this process all the more confusing?
When I took basic Java and VB programming courses in college 10 years ago, we focused only on Java and VB. There was no HTML, CSS, JS, frameworks, etc. And you could have a complete, functioning program with GUI from the start.
Now, to create a web app, you have to learn all those other things in addition to Ruby, or Python, or PHP. As you advance in skills you'll likely move to either front-end or back-end, but when you start out creating everything from scratch, it feels like there's so much more.
(This coming from someone who did IT work for the 10 years following college, and is not trying to break into the web developing world).
Knuth hath said:
"A person who is more than casually interested in computers should be well schooled in machine language, since it is a fundamental part of a computer."
I agree with that sentiment. The whole "focus on what works" is not the same thing as "understanding what the hell you're doing."
I think you can reduce the list a lot more--and should. I'd choose a single language and learn it well and go from there. And I'd only work the command line features. So Ruby on the command line or JS or Java would be my choices (but only one).
This is bs. No one learns how to code in one year. You bearly scratch the surface. If a musician or a dancer would write about their experiences after one year of playing/dancing, it would be laughable, yet with programming, for some reason, it is acceptable. You know almost nothing about programming after doing it for one year.
You put the cart before the horse (which was actually your first mistake). When you get out of college - get a job, work a while - then start a side business. Your startup success odds will more than quadruple following this advice.
It's easy to worry about every details and learn every piece of tech yourself all at once, but it's a recipe for unstable foundations and disasters of distraction.
Creating small achievements by prototyping simple ideas in unfamiliar technologies gives me small, concrete rewards to celebrate the journey.
Ask a developer who is working in the area that you are interested in to give you some guidance. My girlfriend decided to become a web designer. Do she asked an experienced developer, me. I said HTML, CSS, JavaScript and JQuery. She added Photoshop and some image creation tools. She learned the parts I suggested and decided to go to a community college to get some focus. (Actually, she originally signed up to get the student discounts on the software.) In a few months she will get a job to get some practical experience. Then she will tackle her own projects.
89 comments
[ 5.4 ms ] story [ 159 ms ] threadWe have an extremely small, simple project that we've been talking about. Screw it. I'm dumping the book and starting on that as soon as I get home.
Exactly what I needed to read.
I was inspired by: http://mroosendaal.prosite.com/628/612/work/msced and http://designitcodeit.com/
Plus Mig Reyes's quote "Just make a bunch of shit" or the more eloquent way that Ira Glass put it "the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions."
It's the same principle, and one I value highly. I think tackling a new discipline, and the wave of information that rushes toward you as you put your toe in the water can sometimes distract us from simple grounded approaches that we know have worked well for us in the past.
Thank you for the links!
With coding, there was no such outside pressure, so until I joined Yipit, I had tons of bad, hacky habits. In order to get to the next level, I had to rebuild from the ground up and learn the fundamentals really well.
For coding you could hammer out a project, get familiar with a language and the technologies you used to implement it, then download a Stanford lecture on proper Programming Methodology.
More people need to just jump in. If you get to a point that you want a feature from jQuery, look it up and implement it, but don't feel like you need to wrap your mind around every feature before you can begin. Great work and keep at it.
If there was a list of software projects somewhere, ordered by difficulty, with tips on how to get started and how to extend it later, I would be very interested.
I can code (somewhat), but I find that any time I have an itch to scratch, it's much easier to google it and solve it through existing software and configuration changes. Every time I've had a project in mind, I'm quickly in over my head. I'd like to move beyond scripting and actually build self contained software I can post on Github and give to my friends, but I guess I don't know where is a reasonable place to start.
Oh, it's too big?
Build a piece of it.
Oh, that's too big?
Build a piece of it.
The problem you're probably having is that you're saying, "I want THIS" and THIS is too big for you to imagine. So, just write a small subset, maybe 3% of that. Then you'll realize you can easily build this next little bit over here or over here and eventually get there.
Learning programming fundamentals is a better way to go. That way, you can jump from lang to lang.
Starting is hard so congrats again.
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.
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.
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.
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.
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.
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.
[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.
2 Biggest mistakes when learning to [TASK X]
Mistake #1: I spent too much time learning things that I didn’t actually need.
Mistake #2: I didn’t start [TASK X] right away.
In the end I just ended up writing my prototype in PHP (ironically the language that no one recommended - and most hated) simply because it was so simple to jump right in and get started. More so because PHP ran on the server I used to host my static HTML/CSS files.
My first side project is www.youfm.org and its doing great (150k hits, 40k uniques, hundreds of people spending over 5 hours on the site).
So the most important advice I can give is to just pick a language and dive right in. Don't worry about the right language, don't worry about which is the easiest to learn, or scales the best, or anything like that. Just pick any one and start coding.
Flask is lightweight, simple, and you can understand most of it in a very short period of time. I'd say it taught you to code more, whereas Django teaches you to use Django.
It is very helpful to have a idea of the breadth of and resource for a subject.
Review typically means "experimental coding". The 2nd point "start coding now" is a Truism. Just don't start coding "production". Learn some, think, first.
I learned CakePHP by coding my thesis with it. Now, I wanted to learn python + postgres by planning to port my thesis to it.
Case in point was myself when I was learning Javascript. Sure, I could get the JS to do what I wanted, but it was clunky, used a lot of memory and was slow. Fast forward a few years and I've gone back and read Crockford's books several times, and with more studying, I've gotten much better at writing JS. I now try and make my JS as lean and as fast as possible. It's a totally different approach then when I started.
The problem is thinking once you know how to do something, you're done. Like a friend once told me, "You don't learn to be a programmer, you learn to be a student of the language you choose."
There seems to be a huge lack of people simply reading code to learn from it, rather than poring through dozens of recommended "Learn to Program in X in 7 Days!". A novelist probably reads more than they write; the same is rarely the case for programers (at least in my experience, especially in the case of people who are less pedantic than others).
However, had you not taken the road you did, the material you read much later on probably wouldn't have made much sense and probably could have made you turn away from it all right at the start, right?
You get excited when you see results right away. Once you do enough things that begin to make you wonder, "Gee, there's gotta be a way to do this faster or more efficiently." When your curiosity drives you to search for answers is when you delve much deeper into the nuances and the grit of a language that becomes important for scale.
As students of computer science, we have strong tendency to learn things bottom-up. We take care in learning the fundamentals before applying theories in real work. This is not a bad thing. Better quality codes are shipped and become more maintanable.
But for someone who is just starting out, the bottom-up approach becomes an insurmountable obstacle. As a result, many give up too soon and never end up enjoying the joy of creating real working applications.
Look back to when we first started to code. I wrote some bad BASIC code in high school abusing GOTO and GOSUB everywhere I could. I knew nothing about programming language paradigms or memeory management, but I had a lot of fun coding without reading any book on CS.
The more information about a topic you have in your head, the more likely you are to see the connections between subfields, how various bits are important and unique or just ho-hum standard implementations.
I regularly see people in some niche area say "look we have found this amazing new way to handle the data-flood", only to tell them they have reinvented NoSQL or a message queue, or a technique for dealing with matrices that the image processing or simulation folks have been doing for years (and all of them poorly, making recognizable mistakes). A breadth-first overview has much advantage.
There's also a timing problem. If you invest now, and learn technology T, then when you are in the middle of developing a project, the marginal cost of using T is very low. But if you are up to your neck in a project, and then need to take a week off to learn T, you are not likely to do so.
Personally, when re-starting my tech career I wish I had learned Java (or any JVM language) over PHP, PostgreSQL over MySQL, and Dojo over JQuery.
The trial and error got me to learn a lot of things. In addition to the six things that you've listed, I forced myself to learn VIM as well. You probably use VirtualEnv, which you've forgotten to list.
Anyway, it's always good to see others going down the same road and sharing their experiences. Do you have some links to some of your early projects?
Just jumping into writing code is great for motivational reasons because you'll have something tangible, something to be proud about and to help you get excited and keep learning. But you'll still lack insight in a lot of the surrounding environment, things that any programmer should know.
Attempting to do this the other way, reading as much as possible and as in depth as possible, will be good to give you some insight, but you'll have nothing to show for it until you start coding and it'll still take time for you to learn some stuff that can only really be understood with practice.
What I'm trying to get at is that it doesn't really matter how you start, as you are going to have to dedicate 10,000 hours to learn, polish and excel at any craft.
Start writing code, make it do what you need it to do today. This will focus your efforts to what you need to do at the present moment and you won't end up trying to figure out how to deploy an app you haven't built yet.
Later, I actually tried the textbook first approach, and this worked much better for me. By learning the framework and being able to observe the patterns, learning new commands was much easier and I could often guess at exactly what I'd need to do. I also remembered commands for much longer than I did with the first approach.
YMMV, but some people have more theory-centric learning styles and some have more application-centric. Test and figure out what works for you.
When I took basic Java and VB programming courses in college 10 years ago, we focused only on Java and VB. There was no HTML, CSS, JS, frameworks, etc. And you could have a complete, functioning program with GUI from the start.
Now, to create a web app, you have to learn all those other things in addition to Ruby, or Python, or PHP. As you advance in skills you'll likely move to either front-end or back-end, but when you start out creating everything from scratch, it feels like there's so much more.
(This coming from someone who did IT work for the 10 years following college, and is not trying to break into the web developing world).
I agree with that sentiment. The whole "focus on what works" is not the same thing as "understanding what the hell you're doing."
Creating small achievements by prototyping simple ideas in unfamiliar technologies gives me small, concrete rewards to celebrate the journey.