Learning RoR w the "Sweat Lodge" approach

Personally, I think the best approach to learning RoR is to learn the basics of Ruby first, then move on to Rails. It also helps to work on your own project.

Tutorials are ok, but I find them more useful as a tool to see how someone else would approach a particular problem, as opposed to a learning tool. The reason I say that is because many tutorials breeze through important concepts for the sake of brevity.

Picking a simple project and using books or online info to work through the process is, in my opinion, the best way to actually learn. Once you have a grasp on the language, start looking for good code examples and study those. In the end, the more you read and write code, the better you'll be. I'd say you could certainly make good headway in a week with a schedule like you describe.

Different strategies work for different people. I've found I can't pick up more than an hour or two worth of material a day before I start to hit diminishing returns. The longer I press on, the less productive that time is.

I think an hour or two a day is ideal. Work through a single tutorial, finish a chapter in a book or watch some screencasts then implement what you learned. Build a bunch of toy apps that will be thrown away using what you learned that day. At first, you'll start out just doing some command line stuff.

I think most people learn Ruby and Rails at the same time. I personally found that I got more out of it if I focused on Ruby first (a couple hours a day for a couple weeks) then went through some Rails stuff.

I think the "Sweat Lodge" technique is flawed, because it presumes that you'll eventually stop learning. I think it's better to get in a habit of learning a little every day. You're always a work in progress, and you're never "there", so it probably doesn't help to try to speed the process up for getting "there".

If you finish up railstutorial.org (should only take about 30 hours or so) you'll have a good footing to take on whatever else. A lot of what learning programming is is beating your head against the wall solving a specific problem. None of those hours are wasted because it's a certainty that you're learning answers to other problems while solving your current one.

I really appreciate the advice/comments. Spending 12 hrs a day when you hit the "wall" at hour 4 probably doesn't make a ton of sense the more I think of it... One thing for sure, I'm only going to look for help on issues that come up as a last resort- as many have pointed out, what you learn taking the time and effort to find the solution is usually much more valuable than the solution itself!