How I Structure My Learning Time as a Self-Taught Dev

When I started learning to code, I had no system. I'd watch tutorials until I got bored, switch to another course, forget what I learned, and start over. Rinse and repeat for eighteen months.

The breakthrough came when I stopped treating learning as passive consumption and started treating it like a skill that needed its own practice.

Here's the system I built from that point forward.

The Problem With "Learning Everything"

Most self-taught developers fall into the same trap: trying to learn everything before building anything.

I had a Notion database with 200 bookmarked tutorials. I could tell you what React hooks do in theory. I had opinions about state management libraries I'd never used.

But ask me to build something real? I'd freeze.

The problem wasn't intelligence or dedication. It was how I was spending my time.

The 70/20/10 Rule I Actually Follow

After too much wasted time, I settled on a framework that changed everything:

• 70% of learning time: Projects - Build things that solve real problems for you or others
• 20% of learning time: Just-in-time深度 - Go deep on concepts that come up during projects
• 10% of learning time: Breadth exposure - Quick overviews of things you might need later

The key insight: projects create the context that makes deeper learning stick.

Spaced Repetition for Code

One of the biggest lies we tell ourselves: "I'll remember this."

You won't. I didn't.

I started using spaced repetition for programming concepts, and it was a game-changer. Not for memorizing syntax - I always Google that. But for building mental models that transfer across languages and frameworks.

// Example: A flashcard I actually use
// Front: "When would you use useMemo?"
// Back: "Expensive calculations that don't need to re-run on every render.
//       NOT for values that depend on props/state that change rarely.
//       Profile first, optimize second."

I use Anki with a programming deck I add to whenever I learn something that feels fundamental. Anki schedules reviews so I see concepts right before I'm about to forget them.

The result: concepts that used to slip away after a week now stick for months.

The Project-First Approach

Here's my actual workflow when I want to learn something new:

1. Pick a project that scares you slightly - Not so hard you quit, not so easy you learn nothing
2. Build the ugly version first - No architecture, no best practices, just shipping
3. Notice where you struggle - Those friction points are your curriculum
4. Go deep on one thing at a time - Pick the biggest struggle, understand it completely
5. Refactor with new knowledge - Now you have context for why the pattern exists

This is slower than tutorial-bingeing in the short term. It's infinitely faster in the long term because you actually remember what you learn.

Note-Taking That Works

I tried every note-taking system. Notion, Obsidian, roam research, apple notes, physical notebooks.

What finally worked: keep it simple and capture at the right moment.

My current system:

📁 Learning/
  📁 By Topic/
    - react-hooks.md
    - css-grid.md
    - git-advanced.md
  📁 Projects/
    - my-blog-notes.md
    - cli-tool-learnings.md

Each note is just three sections:

1. What I learned - The concept in my own words
2. Why it matters - When would I use this?
3. Example code - A minimal, working example I can reference later

The discipline is writing notes while you're learning, not after. That's when the context is fresh.

The Weekly Review Ritual

Every Sunday, I spend 30 minutes:

• Review notes from the week
• Add anything to Anki that feels fundamental
• Plan next week's project based on gaps I noticed
• Delete things that turned out to be rabbit holes

This one habit prevents the "forgot everything I learned" spiral that used to derail me every few months.

What This Actually Looks Like

A typical week for me:

Monday: Start new project feature, get stuck on X Tuesday: Deep dive on X, add notes, add Anki card Wednesday-Friday: Apply X to project, ship feature Sunday: Review, plan, prune

The output isn't just completed projects. It's a growing body of knowledge that compounds.

The Compounding Effect

Here's what nobody tells you about structured learning: it compounds.

Six months in, I started noticing patterns. Concepts from one project made the next project easier. Notes from last year were suddenly relevant again.

My second blog took 20% of the time of my first. Not because I copied myself, but because I had a system that captured what I learned.

The developers who grow fastest aren't the ones who learn the most - they're the ones who learn deliberately and remember what they learn.

The system isn't complicated. Projects for context. Spaced repetition for retention. Simple notes for reference. Weekly reviews for momentum.

You don't need a perfect learning environment. You need a system that works in the margins of your life.

Start small. One project. Three flashcards. Ten minutes of review.

The compounding starts immediately.