Study Guide¶
How to learn a new technology efficiently. For tips on working with AI coding assistants, see Tips.
The Three Resources¶
To pick up any new tech, triangulate between these:
- Official documentation — authoritative concepts and reference.
- Real codebases — see how others actually use it in production.
- Source / open-source implementations — when you need to understand the internals.
Documentation tells you what; codebases show you how; source code reveals why.
A Rapid Learning Loop¶
- Master the fundamentals first. Understand the problem the technology solves and its core mental model before touching advanced features.
- Apply the 80/20 rule. Focus on the 20% of features that give 80% of the value. Leave edge cases for when you hit them.
- Build small, real projects. Start minimal, grow incrementally. Rebuilding a feature from an app you admire is one of the best exercises.
- Practice with intention. Set a concrete goal each session. Review what you learned afterward.
- Write tests early. Tests force you to use the API and catch your misunderstandings.
- Read the docs deeply. Start with tutorials, then the reference, then the "design philosophy" section if it has one.
- Learn the tooling. Build tools, package managers, debuggers, and IDE features are part of the tech.
- Keep a learning journal. A cheat sheet of gotchas, patterns, and snippets pays for itself within weeks.
Accelerators¶
- Spaced repetition for vocabulary and idioms.
- Teach what you learned — explaining forces you to understand.
- Pair programming with someone more experienced.
- Time-boxed exploration — set a limit before asking for help, so you struggle productively without getting stuck.
Measuring Progress¶
You're making progress when:
- Problems that took an hour now take ten minutes.
- You reach for the docs less often.
- You can explain the technology to someone else without hand-waving.
- You can debug an issue by reasoning about the system instead of guessing.
Onboarding to a New Codebase¶
When joining a new project or platform, explicitly ask about:
- Security — measures in place, vulnerability process, audit history.
- Documentation standards — where docs live, how they're kept current.
- Onboarding path — the recommended order for new engineers; buddy system.
- Troubleshooting — common issues, debugging tools, where logs live.
- Performance — known bottlenecks, profiling tools, optimization guidelines.
- Community and support — where to get help, key maintainers.
- Version control — branching strategy, review process, release cadence.
These are the questions that separate "can run the code" from "can make changes without breaking things."