Suggest edit — learning-paths

Title

Name

Note

---
visibility: public-edit
---

# learning paths

this is not "learn to code 101." if you're reading this wiki, you probably already know how to code, or at least how to start. this is about going from "can write code" to "can [[shipping-products|build things that matter]]" — and the specific paths that get you there.

my fundamental belief: **you learn by building, not by studying.** courses are fine for initial exposure, but the real learning happens when you're stuck on a real problem at 2am and have to figure it out.

## the core skill: going from "can code" to "can build products"

this is the gap that separates hobbyist programmers from builders. it's not about knowing more languages or frameworks — it's about the meta-skills:

1. **scoping:** knowing what to build and what to skip. the hardest part of any project is deciding what NOT to do.
2. **shipping:** getting something in front of users. 90% of projects die in the gap between "it works on my machine" and "someone else can use it."
3. **iterating:** using feedback to make it better. the first version will be wrong. that's fine.
4. **debugging production:** when real users hit your thing, everything breaks differently than in development.
5. **reading other people's code:** open source, documentation, stack overflow. 80% of building is reading, 20% is writing. a good [[knowledge-management]] system helps you retain what you read.

how to develop these: **build 3 real projects.** not tutorials, not clones, not todo apps. real things that solve real problems for real people.

- project 1: build something for yourself. automate something annoying, build a [[personal-infrastructure|tool you wish existed]].
- project 2: build something for someone you know. your school, your club, your family's business. now you have a "user" who gives you feedback.
- project 3: build something for strangers. put it on the internet. deal with the chaos.

after these three, you'll have the meta-skills. the specific technologies don't matter nearly as much.

## my path

I started with p5.js in 6th grade — just making visual things because it was fun. moved to ML in 8th grade, not because "ML is hot" but because I had a specific question: can you classify anesthetic depth from EEG signals? that question led to a [[publishing-research|published research paper]] (CNN anesthetic depth classifier).

the pattern: **a specific problem pulled me into each new domain.** I never sat down and said "I should learn ML." I said "I need to classify EEG signals" and ML was the tool that could do it. the learning was a side effect of the building.

## self-directed learning vs. courses

my take: **no courses. pull from resources, build things.**

the problem with courses is they teach you to follow instructions, not to solve problems. a course gives you a path; real building requires you to find the path.

that said, here's how I'd use structured resources:

### for initial exposure to a new topic
- **MIT OCW:** the best free resource for learning any technical subject deeply. the lecture notes and problem sets are more valuable than the videos.
- **3Blue1Brown:** for mathematical intuition. his videos on linear algebra and calculus are genuinely the best way to build geometric intuition.
- **fast.ai:** for ML/AI specifically. their "top-down" approach (build first, understand theory later) matches how builders learn.
- **The Odin Project / Full Stack Open:** for web dev. project-based, not lecture-based.

### for going deep
- read the docs. seriously. React docs, Python docs, MDN for web. documentation is the most underrated learning resource.
- read source code. find a well-written [[open-source]] project in your area and read how they solved the problems you're struggling with.
- read papers. once you're past the basics, academic papers are where the cutting edge lives. arxiv.org for CS/ML, Google Scholar for everything.

## the "vibe coding" path

this deserves its own section because it's genuinely new.

AI coding tools (Claude Code, Cursor, Copilot, etc.) have changed what's possible for solo builders. see [[tools-stack]] for my full AI coding setup. you can now build in a weekend what used to take months. this is especially powerful for young builders because:

1. **you can prototype faster.** idea to working app in hours, not weeks.
2. **you can work outside your expertise.** don't know CSS? AI handles it. need a database schema? AI generates it.
3. **you can focus on what matters.** product thinking, user problems, design — not boilerplate.

but there are traps:

1. **you still need to understand what the AI is generating.** if you can't debug the code when it breaks (and it will break), you're stuck.
2. **AI is a force multiplier, not a replacement for skill.** the best AI-assisted builders are the ones who already know how to build. they use AI to go 10x faster, not to go from 0 to 1.
3. **don't let AI make you lazy about fundamentals.** understand how the internet works, how databases work, how auth works. you don't need to implement these from scratch, but you need to understand them.

my approach: use AI tools aggressively for boilerplate, styling, and things you've done before. write the core logic yourself (or at least understand it deeply). I've done 500+ Claude Code sessions — it's my primary coding tool. but I also spent years learning fundamentals before AI tools existed.

## key books and resources

- **"Hackers & Painters" by Paul Graham:** the essay collection that defines builder culture. read at least "Hackers and Painters" and "How to Make Wealth."
- **Paul Graham's essays (paulgraham.com):** the single best free resource on startups, building, and thinking clearly. start with "Do Things That Don't Scale" and "How to Get Startup Ideas."
- **"Designing Data-Intensive Applications" by Martin Kleppmann:** when you're ready to understand how real systems work at scale. this is the book.

## the meta-advice

don't follow a "learning path." follow your curiosity.

the best builders I know didn't follow a curriculum — they had a problem they wanted to solve and learned whatever they needed to solve it. the learning was a side effect of the building, not the other way around.

if you're stuck on what to learn next, the answer is always: build something. and find a [[communities|community]] of people building alongside you. the gaps in your knowledge will reveal themselves, and then you'll know exactly what to learn.