For a while I assumed there were two kinds of learners: people who pick things up fast, and people who take longer. I put myself somewhere in the middle, depending on the subject. That framing held up right until I looked at two learning projects that ran through roughly the same stretch of my life and noticed they had nothing in common except the word “learning.”
The first was my master’s thesis. Vigil went from a rough MVP before Christmas to a defended thesis by spring, about six months of learning an entire research area, a testing framework, and how to write and defend a technical argument, compressed into a fixed window with a hard deadline at the end.
The second was Finnish. I’m still doing Mochi reviews most days, still doing a weekly Tandem chat, still nowhere near fluent, closer to a year after I started. By the thesis’s standard, that’s slow. Glacially slow.
Except comparing the two on speed alone misses what actually made each one work.
What made the thesis fast
The thesis wasn’t fast because I’m a fast learner. It was fast because someone else owned the clock. Biweekly meetings with my supervisors forced me to show up with something changed every two weeks, whether or not I felt ready. The defense date sat at the end of the calendar, immovable, and everything before it had to fit around it. That structure did the actual work of “learning quickly.” It wasn’t willpower, it was an external forcing function I didn’t design and couldn’t opt out of.
Once the defense happened, that clock stopped existing. There is no biweekly meeting demanding I keep learning testing frameworks. The system that got me through six months of intense work was never built to run past the point where someone stopped grading it, because it didn’t need to.
What made Finnish survive
Finnish never had that clock. Nobody schedules a defense for a language you’re learning for yourself. I built the system knowing that, which is a different design problem than the thesis ever was. It had to work on days I didn’t feel like it, with a daily minimum small enough to survive being tired, and reviews that live in Mochi so there is nothing to set up before I start. It wasn’t designed to be fast. It was designed to still be running a year later, which it is.
The variable that actually mattered
Speed wasn’t the design choice in either case. In the thesis, speed was a side effect of a deadline I didn’t get to choose. In Finnish, the absence of speed was a side effect of deliberately building something that had to work without one. Neither system is a template for the other. Running the thesis’s pace on Finnish would have burned out inside a month, because nothing forces it to stop and nothing rewards the sprint. Running Finnish’s patient, low-friction pace on the thesis would have meant showing up to a defense with nothing done.
The small systems piece I wrote earlier makes a related point: the version that survives is the one that stays small enough to keep going. That’s true, but it’s not the whole story. Some things are not supposed to keep going forever. They are supposed to finish, hard, on a schedule, and then stop. Knowing which one you are building before you design the system for it would have saved me some confusion about why one felt effortful in a good way and the other felt effortful in a bad way when I tried to rush it.
Closing
“Learning fast” and “learning slow” are not different skill levels. They are different answers to the same question: does this need to survive after the pressure that is currently forcing it goes away. The thesis did not, so it was allowed to be intense and temporary. Finnish does, so it was never allowed to be intense at all.
