How I Actually Learn New Skills (No Tutorial Required)

I used to believe that learning involved merely reading, watching, and absorbing information. However, my perspective has shifted; I now understand that learning primarily consists of experimenting, identifying errors, and comprehending the causes behind them. The method that effectively works for me is: learn, attempt, debug, understand, ship, and reflect.

This approach contrasts with the traditional tutorial-first method, which only provided me with knowledge that lacked understanding. I could follow along, but I couldn't explain why anything worked, and if something deviated from the tutorial, I would be stuck. The real retention happens when we try something, witness it fail in a specific manner, and figure out why that particular failure occurred.

This isn't a flaw in the learning process; rather, it's the core mechanism. I document my thoughts, including the messy parts, which I do publicly. This is the essence of my open learning notebook: field notes, half-formed thoughts, and the connections I make as I progress, without any curriculum backing it. Writing down what I learn is often the moment when I truly grasp the concept, not merely when I record that I understand it.

Keeping a public record prevents me from falsely believing I learned something faster or more cleanly than I actually did. I've stopped attempting to impose structure on this process. Instead of color-coded study plans and structured syllabi, I focus on the smallest next step I can attempt each day. Small, concrete actions outperform ambitious productivity systems every time, as the systems are planned actions, while the actions are the ones we actually take.

Consistency beats intensity. I used to oscillate between all-or-nothing extremes - a frenzied week of nonstop learning followed by weeks of doing nothing, always restarting from scratch. A more effective approach is to show up consistently, more frequently, and maintain continuity. Leaving breadcrumbs for myself, so I can pick up exactly where I left off without having to re-decide where to begin each time.

Understanding the 'why' is crucial, not just getting a working answer. This is particularly important now because I frequently use AI in my development work. It's tempting to let AI generate finished code for me, but that's not my goal. I aim to emerge from challenges more capable than when I started, not just holding a solution I can't explain.

AI is a partner, not a replacement - a tool that assists me in thinking through architecture and trade-offs, not one that thinks for me. None of this constitutes a system you can purchase or a framework with a name. It's merely a reflection of what is genuinely true about how my brain learns, after carefully observing it instead of forcing myself into someone else's method.