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.
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.
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.
[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.
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.
I've been in the industry about 9 years, and coding since I was a child. My parents caught me staying up late with a flashlight under the covers as a teenager reading books on C instead of nudie mags. My first program with an event-driven UI ran on a NeXT Color Station. This is not to brag, it's to say I've been doing this basically since I could decide what to do, and I still have a lot to learn about coding, computer science and software engineering.
So you've made your third biggest mistake; you've vastly underestimated what you are in for. You have never "learned" to program, you are "learning." Every year will ask you to acquire new skills and use new models and learn new domains.
I am afraid your comment is even more mistaken. Even more it is discouraging in a really bad way. Read carefully and I'll explain. Even if your HN score is 10 times mine.
In my opinion you are creating a false dichotomy between having learned and learning. Someone who has just started to walk/bike etc has still learned to walk/bike. They are by no means near entering Olympics for the next few years but they have made their own life very much simpler and more enjoyable. (Father of small children here.)
Comments like yours are discouraging at least one specific subset of people from doing the one thing that can possibly help them increase their skills, namely use them. I even think that for most people even if they can learn a lot about coding by just reading, reading and immideately applying it is by far a quicker route.
Anecdata: I once told a 16 y.o. intern how to use basic perl and Visual Basic for Applications. After 14 days where he would run his scripts, check, check with his supervisor, fix the code, learn more perl and vba and so on he came back with a report that would have taken weeks to finish by hand. He is now on his last year on a Bachelor with Honors study and this was his first useful program. Still makes me happy.
(By the way, I also started coding at age 12. Having programmed for both $100+ million companies as well as startups I am not one of those struggeling to learn the basics. Anymore, that is : )
The fundamental difference here is that bikes are ridden in a way that's fundamentally unchanged for decades. Contrary to this "settled" field of knowledge, programming is constantly invalidating itself. Even if you achieve competency in a limited field (perhaps operating system design or web development), that field will almost certainly overturn itself within 5 years for any reasonably broad definition of field. Consider what modern linux looks like compared to the original version; a lot of new techniques have emerged to address requirements.
To enter that field, this new knowledge is not "optional." It's required. The goalposts for competency aren't just shifting; they've got a nuclear power supply and tank treads and they're out of control.
In this, it is not unlike being a doctor. Their knowledge base is similarly in constant flux (although not quite so violently as ours). A doctor who does not constantly improve and update their knowledge will be a substantially worse doctor than one who does. A perfect example of this is pre-scientific doctors like homeopaths, who basically do nothing with an almost frightening level of dedication and fervor.
> Comments like yours are discouraging at least one specific subset of people from doing the one thing that can possibly help them increase their skills
I did not direct this at some 16 year old kid or a non-programmer, nor did I put it in a venue where non-tech people read. Even if I did, citing final consequence is hardly a good argument. In any case, the industry does a pretty good job of discouraging people from joining as it is. When I was in college, there was a 60% dropout rate between lower and upper division classes.
Try Haskell before you have too many preconceptions of what "should" be to burn away. :)
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.
10 PRINT "COCKS"
20 GOTO 10
Step 2 in learning to code:
10 INPUT "How many cocks do you want",C
20 FOR I = 1 TO C
30 PRINT "8===========D"
40 NEXT I
I'm not recommending that your first steps into programming be in BASIC, or involve cocks. (On both accounts I would recommend the exact inverse.) But this is how a million programmers got started: useless programs that amused us. Never, ever, ever underestimate a useless program, especially for beginners. The author of this article seemed to want to focus on building a prototype for his Web startup. And that's fine, as a long-term goal. But if you're brand new to the world of programming it's probably a good idea to start with the basics, like printing or drawing stuff on the screen, doing some simple (or, later mor complicated) mathematics, or munging or transforming data in interesting ways. This helps keep the budding programmer focused on the patterns and "shape" of their language, which knowledge they can then later direct to a specific purpose like Web or smartphone apps.
Also, 1/2 a downgrade for the lame, childish example.
they provide immediate gratification in terms that non-developers find humorous. which is a great way to spark interest.
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.
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.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.
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."
I learned CakePHP by coding my thesis with it. Now, I wanted to learn python + postgres by planning to port my thesis to 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.
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.
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.
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.
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).
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.
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.
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?
Creating small achievements by prototyping simple ideas in unfamiliar technologies gives me small, concrete rewards to celebrate the journey.
I agree with that sentiment. The whole "focus on what works" is not the same thing as "understanding what the hell you're doing."
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.
HTML/CSS/JS (View)
jQuery (View Framework, couldhave been YUI, for example)
Programming language
Framework in said language
I still think actual SQL / DB knowledge is requisite to do all but the most minor of apps, but he is specifically trying to get people from being overwhelmed.
I'm struggling with Play!, because I need to know HTML/CSS/Java/Scala subset (templates)/EBean ORM/the massive library that is Play.
Just a simple app touches on so many libraries and helper functions, it's hard to get a grasp of what's going on. I don't even build a form anymore, I build a form-ish object that I pass to the controller that fills in data to the ORM that inserts stuff into the database. o_O