new file mode 100644
index 0000000..45c89d8
@@ -0,0 +1,109 @@
+---
+visibility: public
+---
+
+# 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 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.
+
+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 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.
+
+## 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.
+
+## technical depth tracks
+
+### ML / AI
+- **start:** fast.ai course → build a classifier for something you care about
+- **go deeper:** Andrew Ng's Stanford CS229 (MIT OCW equivalent) → implement papers from scratch
+- **go even deeper:** read papers on arxiv daily. pick one paper a week and implement it.
+- **the 2024+ reality:** with LLMs, the game has changed. you don't need to train models from scratch for most applications. the skill is knowing how to use APIs, fine-tune, build RAG systems, and build agentic workflows. the people building AI applications right now are winning.
+- **my path:** I started with p5.js in 6th grade, moved to ML in 8th grade, published an EEG research paper (CNN anesthetic depth classifier). the key was always having a specific problem to solve — not "learn ML" but "can I classify anesthetic depth from EEG signals?"
+
+### web dev / product building
+- **start:** build a personal site. HTML/CSS/JS. deploy it.
+- **go deeper:** pick a framework (React/Next.js is the current default). build a full-stack app with auth, database, and deployment.
+- **go even deeper:** learn infrastructure. how does DNS work? what's a CDN? how do databases scale? what's a message queue?
+- **the builder's path:** React/Next.js → Vercel for deployment → Supabase or Postgres for database → Stripe for payments → you now have everything you need to build and charge for a product.
+
+### hardware / embedded
+- **start:** Arduino. build something physical that responds to the world.
+- **go deeper:** Raspberry Pi. ESP32. learn about sensors, actuators, serial communication.
+- **go even deeper:** PCB design (KiCad), 3D printing for enclosures, embedded C/C++.
+- **the reality:** hardware is harder than software because debugging is harder and iteration is slower. but hardware projects are more impressive because fewer people do them, and the problems are more constrained (which can actually make them easier to reason about).
+
+### research
+- **start:** read papers in an area that interests you. take notes. try to reproduce results.
+- **go deeper:** find a gap in the literature. can you improve on an existing method? can you apply it to a new domain?
+- **go even deeper:** reach out to a professor whose work you've read. ask specific questions. propose a collaboration.
+- **my path:** I read papers on EEG classification, found an approach I thought could work better, built it, tested it on real data, and wrote it up. the key was having a specific hypothesis, not just "doing research."
+
+## 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. 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
+
+I'm not going to give you a reading list of 50 books. here are the ones that actually matter:
+
+- **"Hackers & Painters" by Paul Graham:** the essay collection that defines builder culture. read at least "Hackers and Painters" and "How to Make Wealth."
+- **"Zero to One" by Peter Thiel:** contrarian thinking about startups and innovation. you'll either love it or hate it, but you should read it.
+- **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."
+- **"The Lean Startup" by Eric Ries:** MVP thinking. build → measure → learn. the methodology that most modern startups use.
+- **"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. the gaps in your knowledge will reveal themselves, and then you'll know exactly what to learn.
\ No newline at end of file