Most advice about learning Ruby is a list of resources, which is the least useful shape it could take. The resources are plentiful and largely interchangeable; what is scarce is an order, and a way of telling when one stage is finished and the next is worth starting. This page is the order.
Stage one: read it
Enough of the language to read a method and say what it returns without running it. Blocks, hashes, arrays, the common enumerable methods, and the fact that everything is an object. Days rather than months, and the temptation to keep going is the first thing to resist.
The finishing condition is checkable: open a small gem, pick a method, and predict its return value before running it. Getting that right most of the time is the whole of stage one.
Stage two: build one small thing
Something with a real end: a command-line tool that does one job, a script that solves an actual annoyance. Not a tutorial application, because a tutorial ends when the tutorial ends rather than when the thing works.
What this stage teaches is not syntax. It is the shape of a project: where files go, how a dependency gets added, what happens when something is required, and how a program is run more than once. That is where gems and Bundler first becomes real rather than theoretical.
A tutorial ends. A tool is finished when it works.
Stage three: change somebody else’s code
The step most people skip, and the one that separates being able to write Ruby from being able to work in it. Adding a feature to an existing codebase requires reading far more than writing, and it is the first point at which the conventions of a framework stop being trivia and start being navigation.
An open-source project works, and so does any codebase at work that nobody has claimed. The size of the change matters much less than the fact that the surrounding code was written by somebody else with different habits.
Stage four: fix a real bug
A bug reported by somebody else, in code that was working. This is different from every earlier stage because the goal is not to make something happen; it is to find out why something already happens, which is a different skill and the one that actually gets used most days.
What it teaches is reproduction before diagnosis. The instinct is to read code until the cause appears; the method that works is to make the failure happen reliably first, then narrow. A test that reproduces the bug is the natural artefact, which is where testing stops being a chore and starts being a tool.
Stage five: name the layer
Given a problem, saying whether it belongs to the language, a gem, the framework or the environment, before investigating. This is the skill that makes everything else faster, and it is the one nobody finishes acquiring.
It is also the reason the earlier stages matter in that order. Somebody who arrived through a framework without stage one cannot tell framework behaviour from language behaviour, because they have never seen the language without the framework on top of it. That whole argument is on learning Ruby, and the framework side is on Rails.
What to skip, and when
Skip the full set of framework conventions until stage three, because they are discoverable at the moment each is needed and unmemorable before it. Skip types until there is a codebase large enough to be worth annotating, which is covered on static analysis. And skip choosing a version until stage two, where the release timeline answers it in one line.
The one thing not to skip is reading other people’s code. It is the highest-yield activity at every stage and the one most reliably postponed in favour of another tutorial.
For where a conference fits into any of this, the short answer is stage three onwards: a talk is a poor way to learn a language and a good way to find out what is worth learning next. That is on beginner tracks, and the rest of the section is at Ruby and Rails.
Questions
How long does stage one take?
Days rather than months. The finishing condition is being able to open a small gem, pick a method and predict its return value before running it. Getting that right most of the time is enough to move on, and continuing past it is the first temptation to resist.
What should the first project be?
Something with a real end: a command-line tool that does one job, or a script that solves an actual annoyance. Not a tutorial application, because a tutorial finishes when the tutorial finishes rather than when the thing works.
Which stage do people usually skip?
The third, changing somebody else’s code. It is the one that separates being able to write Ruby from being able to work in it, because it requires reading far more than writing and makes a framework’s conventions into navigation rather than trivia.
Why is fixing a bug a separate stage?
Because the goal is inverted. Every earlier stage is about making something happen; a bug is about finding out why something already happens. It also teaches reproduction before diagnosis, which is the habit that separates a short investigation from a long one.
What is worth skipping early on?
The full set of framework conventions until stage three, types until there is something large enough to annotate, and the choice of version until there is a project. The one thing never worth skipping is reading other people’s code.