There's a big difference between learning how to program and starting a library/project every month. If you want to learn how to build something, which is what programming is, there is a straitforward way of learning how to do so.
Phase 1 is where you learn what programs look like. Pick any language. Learn all of the syntax and and meanings behind everything. Get to the point where you can start a project and write some code down and get a simple solution to a 1-step problem.
Phase 2 is when you pick a long term goal. Something you want to build. Maybe a game, maybe a website, maybe automate some portion of your life. After that, you write out all of the things that go into making that happen. An itemized list of absolutly every feature you want to include. Then you go to phase III
Phase 3 you break every goal into sub-goals, and those sub-goals into further subgoals so you have a tree. Stop breaking into sub-gaols when your goals are something like "Read config from file", "Grab user from database", "Render N many objects sequentially to the screen", "Wait to hear from clients wanting to connect".
Phase 4 is when you read up on how everyone else is doing all of the things you want to do. Make a huge list of mappings from sub-goals to stack overflow links on the topics.
Phase 5 every day, pick one of your sub-goals and implement a little prototype doing that sub-portion of your code.
Phase 6 reduce your tree. Go through every sub-goal and merge it into it's partent subgoal's prototype. If you get to the point where the code is messy and hard to follow abstract, optimize, and clean your solution as needed. Do not proceed to the next sub-goal until you are completely happy with how your current sub-goal looks.
Phase 7 test, test, refine, refine, clean, clean.
Doing this may take a year to get 1 project done but it will be the cleanest, most organized, and probably gest example of how you can write code. I think this one project would be worth more then 100 other projects where you "do it live".
That's certainly a good way to learn, though it's by no means the one and only best way. I personally think the best way is to go to MIT and do an EECS major. But we all have our different ways of approaching education, and I respect yours as much as I respect a person who learns based on building simple applications the can relate to and engage with better because they're more interesting.
No college education will teach you the material if you don't actually care. Many people hear "go take a CE degree' or "CS degree" and think "Now I'm a programmer" when they get out. They feel they know everything they need and as soon as they hit the real world reality drops on them like a sack of bricks.
I'm at a "decent" university and currently in my 3xx level classes people don't know how to "do coding" and I'm constantly having to help people learn some material that, had they taken the time to program on their own, they'd know. There is value to a degree but it's not in knowing how to do your skill. The value comes from 1) having a degree, 2) knowing people who have degrees, 3) being able to talk the lingo to people who respect degrees.
Now granted, 6.001 is great and I love SICP but I don't know if you can show me data of people who know absolutly nothing about computers/electronics going into those courses and being able to "do electronics" or "do computers" after getting out. I'd wager that the data will show there's a higher corilation of people who come in knowing something about computers or electronics from their own experiance who are able to get more out of the classes.
Sadly I don't think universites publish this data (would probably be bad press for them).
I'd love to be proven wrong though. It would remove another large chunk of my cynical world view.
I doubt it given all the IT people, including HN readers, saying the college grads usually cant program worth anything. Whereas, the people who learned a creative, building skill by building straightforward or creative solutions to various problems often program better. Surprise!
The vast trove of empical data out there on activities like programming suggest that practice is main way people get better. There's also a sizeable anount of evidence saying ideal practice is a series of problems that increase in difficulty, a bit harder than before, and not insurmountable. Plus, learning techniques & observing examples from experienced professionals.
College isn't likely to teach you much programming skill at all. Now, programming practice + a college education in CompSci concepts can make for a programmer with more tools in the toolbox (taps head). It's not a substitute for repeated, informed practice of act itself.
You actually didn't say anything. You implied 7 arguments existed that would dismiss the comment. Your comment itself was a dismissal with no content. So, I instead argued against it by using the status quo of evidence on going to college vs practicing a skill for building a hands-on skill.
Phase 1 is where you learn what programs look like. Pick any language. Learn all of the syntax and and meanings behind everything. Get to the point where you can start a project and write some code down and get a simple solution to a 1-step problem.
Phase 2 is when you pick a long term goal. Something you want to build. Maybe a game, maybe a website, maybe automate some portion of your life. After that, you write out all of the things that go into making that happen. An itemized list of absolutly every feature you want to include. Then you go to phase III
Phase 3 you break every goal into sub-goals, and those sub-goals into further subgoals so you have a tree. Stop breaking into sub-gaols when your goals are something like "Read config from file", "Grab user from database", "Render N many objects sequentially to the screen", "Wait to hear from clients wanting to connect".
Phase 4 is when you read up on how everyone else is doing all of the things you want to do. Make a huge list of mappings from sub-goals to stack overflow links on the topics.
Phase 5 every day, pick one of your sub-goals and implement a little prototype doing that sub-portion of your code.
Phase 6 reduce your tree. Go through every sub-goal and merge it into it's partent subgoal's prototype. If you get to the point where the code is messy and hard to follow abstract, optimize, and clean your solution as needed. Do not proceed to the next sub-goal until you are completely happy with how your current sub-goal looks.
Phase 7 test, test, refine, refine, clean, clean.
Doing this may take a year to get 1 project done but it will be the cleanest, most organized, and probably gest example of how you can write code. I think this one project would be worth more then 100 other projects where you "do it live".