Scrolls
6 min read
On this page

Learning New Tech Fast

The standard approach to learning a new technology is to watch a 12-hour tutorial series, follow along step by step, and emerge with a finished project you do not understand. You built a todo app in Rust, but you cannot write a Rust function from scratch. You completed a Kubernetes course, but you cannot debug a failing deployment. The tutorial taught you to follow instructions. It did not teach you to think.

There is a faster approach. Read the official "Getting Started" docs, build something small that you actually care about, and reach for the API reference when you get stuck. This takes less time, produces deeper understanding, and leaves you with the ability to solve novel problems -- not just reproduce the ones the tutorial author chose.

The Fast Learning Loop

1. Read the Getting Started (30-60 minutes)
   - Official docs only. Not a blog post. Not a Medium article.
   - Understand what the technology does and what problem it solves.
   - Get the mental model: what are the core concepts?
   - Run the hello world example.

2. Define a small project (15 minutes)
   - Something you actually want to build. Not a todo app.
   - Small enough to finish in 2-4 hours.
   - Complex enough to touch the core concepts.

3. Build it (2-4 hours)
   - Start writing code immediately.
   - When you get stuck, search for the specific problem.
   - Use the API reference, not tutorials, as your primary resource.
   - Accept that the code will be ugly. Ship it anyway.

4. Review what you learned (30 minutes)
   - What was harder than expected?
   - What concepts are still fuzzy?
   - Read the relevant docs section now that you have context.

Total time: 4-6 hours. Compare that to a 12-hour tutorial series that leaves you less capable of independent work.

Why Official Docs First

Third-party tutorials have three problems: they go out of date, they reflect one person's understanding (which may be incomplete), and they make choices for you without explaining why.

Official documentation is maintained by the people who built the technology. It is the canonical source of truth. When a tutorial tells you to do something and it does not work, you end up in the docs anyway. Skip the middleman.

What to read in the official docs:

1. Overview / Introduction
   - What is this? What problem does it solve?
   - What are the core concepts? (Learn the vocabulary)

2. Getting Started / Quick Start
   - Installation
   - Hello world example
   - Basic project structure

3. Core Concepts (skim, don't memorize)
   - How does the thing work at a high level?
   - What are the main building blocks?
   - What is the typical workflow?

What to skip (for now):
- Advanced guides
- Performance tuning
- Migration guides
- Plugin/extension docs
- Anything labeled "deep dive"

You are not trying to learn everything. You are trying to learn enough to start building. The rest you will learn as you need it.

Choosing the Right First Project

The first project matters. Too simple and you do not learn anything beyond the tutorial. Too complex and you get stuck for hours on edge cases that teach you nothing about the core technology.

Good first projects:
- A tool you will actually use (a CLI for a task you do manually)
- A simplified version of something you've built before in another
  language or framework (you already know the domain, just not the tech)
- An integration with a system you already understand
- A small API or service that does one thing

Bad first projects:
- The canonical tutorial project (todo app, blog, calculator)
- A rewrite of your company's main application
- Something that requires 5 other technologies you also don't know
- A portfolio project meant to impress (pressure kills learning)

The best first project is one where the technology is the only unknown. If you are learning Go, build something whose logic you already understand in Python. That way, every obstacle you hit is about Go, not about the problem domain.

Learning by Getting Stuck

Getting stuck is not a failure of the learning process. It is the learning process. When you follow a tutorial, you never get stuck because every next step is given to you. When you build independently, you get stuck constantly, and each time you unstick yourself, you learn something that actually stays.

The stuck cycle:
1. Try to do something
2. It does not work
3. Read the error message (actually read it, do not just scan)
4. Search for the specific error or concept
5. Find the answer in docs, Stack Overflow, or source code
6. Understand why it works, not just that it works
7. Continue

What you learn at step 6 is 10x more durable than what you learn
by watching someone else do it in a tutorial.

The key is step 6. Copying a Stack Overflow answer without understanding it is the same failure mode as following a tutorial. When you find a solution, take 2 minutes to understand the underlying concept. Why did that error happen? What is the language or framework trying to tell you?

Using the API Reference

Most developers underuse API references and overuse tutorials. An API reference is the most efficient learning resource once you have the basic mental model. It tells you exactly what is available, what each function does, and what parameters it takes.

How to use an API reference:

1. You want to do something ("I need to read a file")
2. Search the API reference for the relevant module or function
3. Read the function signature and description
4. Look at the example (most good docs include one)
5. Try it in your code
6. If it doesn't work, re-read the parameter descriptions

This is faster than:
1. Search "how to read a file in [language]"
2. Find a blog post from 2019
3. Try the code from the blog post
4. It doesn't work (outdated API)
5. Search again
6. Find another blog post
7. It works but uses a deprecated function

For languages with strong documentation (Rust, Go, Python, Elixir), the standard library reference is your best friend. For frameworks (React, Django, Rails), the official guides plus API reference cover 95% of what you need.

Time-Boxing Learning

Learning has diminishing returns within a single session. After 2-3 hours of struggling with a new technology, your brain needs time to consolidate. Push past that and you are fighting fatigue, not learning.

Effective learning schedule:
- Day 1: Read Getting Started, start building (2-3 hours)
- Day 2: Continue building, hit harder problems (2-3 hours)
- Day 3: Finish the first project, review (2-3 hours)
- Day 4: Start something slightly more complex (2-3 hours)

Total: 8-12 hours over 4 days

Less effective:
- Saturday: 10-hour learning marathon
  (Diminishing returns after hour 3, exhausted by hour 6,
   mindlessly copying code by hour 8)

Sleep is a critical part of learning. Your brain consolidates new information during sleep. Two 3-hour sessions with a night of sleep between them produce better retention than one 6-hour session.

Reading Source Code

When the documentation is unclear or incomplete (which happens), read the source code. This feels intimidating but is often faster than searching for blog posts about the behavior you are trying to understand.

When to read source code:
- Documentation says "this function does X" but it does not seem
  to work that way
- You want to understand how a feature works internally
- The behavior is undocumented
- You want to learn idiomatic patterns in the language

How to read source code effectively:
- Start from the entry point (the function you are calling)
- Follow the code path for your specific use case
- Do not try to understand the entire codebase
- Read tests to see how the authors expected it to be used

Tests are particularly valuable. A project's test suite shows you exactly how the library or framework is supposed to be used. The test for a function is often more informative than its documentation.

When to Use Tutorials

Tutorials are not useless. They have a specific role, and the mistake is using them as the primary learning method instead of a supplement.

Good uses of tutorials:
- Understanding a complex concept that the docs explain poorly
  (e.g., a specific design pattern, concurrency model)
- Seeing how pieces fit together in a real project
- Learning domain-specific patterns (e.g., how to structure a
  production GraphQL API, not just how GraphQL syntax works)
- Video walkthroughs of debugging sessions (learning the thought
  process, not the code)

Bad uses of tutorials:
- As a substitute for official documentation
- Following along step by step without understanding why
- Watching passively (video tutorials are entertainment unless
  you pause and try things yourself)
- Using tutorials to avoid the discomfort of getting stuck

If you do watch a tutorial, watch it at 2x speed to get the overview, then build the thing yourself without referring to the tutorial. Only look back when you are genuinely stuck on something you cannot figure out from the docs.

Common Pitfalls

  • Starting with tutorials instead of docs. Tutorials are someone else's interpretation of the technology. Start with the source of truth.
  • Choosing a project that is too ambitious. Your first project should take hours, not weeks. You need a quick win to build confidence and momentum.
  • Not actually building anything. Reading docs without writing code is not learning. It is reading. You have to make something.
  • Copying without understanding. When you paste a Stack Overflow answer, take 2 minutes to understand it. Otherwise, you will hit the same problem again and have to search again.
  • Learning too many things at once. If you are learning a new language, a new framework, and a new database simultaneously, you cannot tell which one is causing your problems. Learn one thing at a time.
  • Giving up too quickly. The first 2 hours of any new technology feel terrible. You do not know the syntax, the error messages are opaque, and everything takes 10x longer than it should. This is normal. Push through the initial hump.

Key Takeaways

  • Start with official Getting Started docs, not tutorials. Build the mental model from the source of truth.
  • Define a small project you actually care about and build it in 2-4 hours. The project should be complex enough to touch core concepts but small enough to finish quickly.
  • Getting stuck is the learning process. Each time you debug a problem independently, you learn something durable.
  • Use API references as your primary resource once you have the basic mental model. They are more accurate and more efficient than blog posts.
  • Time-box learning sessions to 2-3 hours. Sleep between sessions for better retention.
  • Tutorials are supplements, not substitutes. Use them for complex concepts, not as a replacement for building things yourself.