![she[ships] profile image](https://media2.dev.to/dynamic/image/width=50,height=50,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Forganization%2Fprofile_image%2F14874%2F02a17400-4acf-4473-83a5-9b512b1a3084.jpeg){kind=small}
I used to think learning meant reading, watching, absorbing. Now I think learning mostly means breaking things and finding out why.
The loop that actually works for me: learn → attempt → debug → understand → ship → reflect. Not learn → learn → learn → maybe someday attempt. The tutorial-first approach always left me with a weird kind of knowledge — I could follow along, but I couldn't tell you why any of it worked, and the second something didn't match the tutorial exactly, I was stuck. What actually sticks is trying something, watching it fail in a specific way, and having to figure out why that specific failure happened. That's not a bug in the learning process — that's the whole mechanism.
And I write things down — publicly, even the messy parts. That's basically the whole premise of my open learning notebook: field notes, half-formed thoughts, and the connections I'm making as I go, with no curriculum behind any of it. Writing something out is often the moment I actually understand it, not just the moment I record that I understand it — and keeping that record public means I can't quietly pretend I learned something faster or cleaner than I actually did.
And I've stopped trying to impose order on top of that. No color-coded study plans, no structured syllabus. Just: what's the smallest next thing I can actually attempt today? Small concrete next actions beat ambitious productivity systems every time, because the systems are things you plan and the actions are things you actually do.
Consistency over intensity. I used to swing between all-or-nothing — a manic week of nonstop learning followed by weeks of nothing, restarting from scratch each time. What works better is showing up smaller, more often, and not breaking the thread. Leaving myself breadcrumbs. Picking up exactly where I left off instead of re-deciding where to start every single time.
I want to understand the "why," not just get a working answer. This matters a lot right now because I use AI a lot in my own development work — and it would be very easy to let it just hand me finished code. But that's not the point for me. I want to come out the other side of a problem actually more capable than I went in, not just holding a solution I can't explain. AI as a pair, not a replacement — something that helps me think through the architecture and tradeoffs, not something that thinks for me.
None of this is a system you can buy or a framework with a name. It's just what's actually true about how my brain learns, after paying attention to it for a while instead of trying to force myself into someone else's method.
Top comments (3)
The specific failure is the part that does the work. A tutorial that runs first time teaches you the happy path and nothing about the shape of the thing. What I still remember years later is always a bug that ate an afternoon, never a chapter I read.
The failure-first loop you describe has a concrete trick worth keeping: write down the exact error message and the smallest reproduction together, not just the lesson. Three months later, "module resolution failed" paired with the 5-line repro teaches more than "I learned about import paths" ever will — and it doubles as a regression test for your future self.
On AI-as-a-pair: one thing that works is making the AI defend tradeoffs instead of writing code — ask it to explain why option B breaks under load before touching the keyboard. If it can't articulate the failure mode, that's the cue to go read the source yourself.
And +1 on breadcrumbs over systems. The highest-leverage breadcrumb I've found is a one-line "what broke and why" per session — it turns the restart cost from "where was I?" into a 30-second read.
Great article and after 2 decades in IT, I used that exact learning path you said to get hands on with AI, writing SKILLs, agents etc. I was a bit afraid to get back into coding with 10 years in mid level management. Too much of learning was hurting my head and the quick tutorials helped me remember what I learned and now things have persisted. Your field notes is just the best idea, I do it too. I save on my Apple Notes. It syncs across devices. Sometimes I will pause tv and take a note and later I use AI to put it all together. I file things away as learnings in my Obisidian vault and occasionally rediscover things when I am looking. What you described is exactly what I am following and it’s working for me!
Btw, messy is okay - if it makes sense to you and AI, it’s all good :)