Skip to main content
BlogCareer

Learning a New Tech Stack Efficiently: My Actual Process

How to go from zero to productive in a new technology stack in 4-6 weeks — the learning sequence, resources, and practice strategies that actually work.

Matthews Wong

Software Engineer

June 202510 min read
Career

I've learned several new technology stacks in the past two years: moving from basic JavaScript to TypeScript + React, picking up NestJS, learning Docker and Kubernetes for my DevOps work, and most recently getting productive with the Anthropic API for AI Gymbro. Each stack I've learned has taught me more about how I learn efficiently.

The Learning Sequence That Works

The tutorial trap: spending weeks on courses before writing any real code. The sequence that works for me: 30 minutes of high-level overview to understand what the technology does and why it exists, then immediately build something small that I actually want, then read the documentation properly when I hit a specific problem I can't solve by intuition.

Choosing Your Learning Project

The learning project is the most important learning decision. Good learning project criteria: small enough to complete in 1-2 weeks, a problem you actually care about (so you're motivated to finish it), forces you to use the core features of the technology, and deployable.

The Documentation Strategy

I read documentation in a specific order: Overview/Introduction (what is this and why does it exist?), Quick Start (the minimal path to a working example), Core Concepts (the mental model I need to understand everything else), and then API Reference only when I need a specific function.

4-Week Tech Stack Learning Framework

  WEEK 1: Orient and Deploy
  ──────────────────────────────────────────────────────
  Day 1-2  → 30-min overview: what + why + who uses it
  Day 3-4  → Build "Hello World" equivalent
  Day 5-7  → Deploy it live (even to a free tier)
  Goal:    → Something running in production

  WEEK 2: Add Core Feature
  ──────────────────────────────────────────────────────
  Day 1-3  → Add the feature your project needs most
             (auth, database, API calls, real-time...)
  Day 4-5  → Read Core Concepts docs section
  Day 6-7  → Fix everything you did wrong in days 1-3
  Goal:    → Understand the happy path deeply

  WEEK 3: Break Things
  ──────────────────────────────────────────────────────
  Day 1-3  → Deliberately hit edge cases:
             What happens with null? With slow network?
             With 1000 concurrent users?
  Day 4-7  → Fix the breaks. Read error handling docs.
  Goal:    → Understand failure modes

  WEEK 4: Build for Someone Else
  ──────────────────────────────────────────────────────
  Day 1-5  → Build something a real person will use
  Day 6-7  → Get 1 person to actually use it
             Watch them get confused. Fix it.
  Goal:    → Production empathy

  Spaced Repetition Rule:
  If you Google the same thing twice → Add to Anki

The fastest way I've found to build genuine understanding of a new technology is to try to break it — deliberately push it to edge cases and failure modes. After you have a basic working example, ask: what happens if I pass null here? What if the network is slow? Technologies reveal their true design through their failure modes.

Leveraging AI for Tech Stack Learning

AI has changed the learning process significantly. Best uses: debugging specific errors with full context, understanding why something works (not just how), and getting the 'common pitfall' summary for a new concept before you encounter it. Worst uses: asking AI to generate the code for your learning project — you won't understand what it wrote.

Spaced Repetition for Technical Concepts

I use Anki (flashcard app with spaced repetition algorithm) for: command-line flags I use infrequently, Docker/Kubernetes YAML syntax patterns, TypeScript advanced type patterns, and any concept where I keep Googling the same thing. The rule for adding a card: if I Google the same thing twice, it goes in Anki.

# Anki card examples for technical learning
# Add these when you've Googled the same thing twice

# Card 1 (Docker)
Front: What does -v flag do in docker run?
Back:  Mounts a volume: -v /host/path:/container/path
       Or named volume: -v myvolume:/container/path

# Card 2 (TypeScript)
Front: How do you make all properties of a type optional?
Back:  Partial<T>  — e.g.: Partial<User>
       Use when some fields might be undefined (patch requests)

# Card 3 (pgvector)
Front: Which operator does cosine similarity search in pgvector?
Back:  <=>   (1 - <=> = similarity score)
       ORDER BY embedding <=> query_embedding LIMIT 10

# Card 4 (NestJS)
Front: Where do you inject a service in NestJS?
Back:  In the constructor with @Inject() or constructor injection:
       constructor(private readonly userService: UserService) {}
       Module must export the service and import it in providers

# Rule: 5-10 minutes of Anki review per day during commute
# Result: After 3 months, "let me look that up" moments drop ~70%

The One-Month Framework for Full Stack Learning

Week 1: Build 'Hello World' equivalent and deploy it. Week 2: Add the most common feature for your use case. Week 3: Encounter a hard problem and solve it properly. Week 4: Build something for others to use. The act of thinking about someone else using your code changes how you approach it.

Tutorial paralysis: starting 5 different YouTube courses on a new technology without finishing any, and after a month still not having built anything. The test is simple: can you build something in the technology without looking at the tutorial? If not, you haven't learned it — you've consumed content about it. For every hour of tutorial you watch, spend 2 hours coding.

When to Give Up vs When to Push Through

Not every technology is worth learning deeply. Signal to stop: after 2 weeks of genuine effort, you still can't explain why you'd use this over existing alternatives you know. Signal to push through: you understand why the technology exists and solves a real problem you have, but you're stuck on a specific concept.

Building Learning Habits That Scale

The developers who stay current have a weekly learning habit: 1-2 hours of focused learning on one technology area, applied to a real project or experiment. I block 'learning time' on my calendar — Tuesday and Thursday evenings, 7-9pm — and I protect it. After 18 months of this habit, my skill growth has been more consistent than any intensive bootcamp-style learning I did before.

Sources & Further Reading

Back to all posts
Share
FAQ

Frequently Asked Questions

Short answers to what readers ask most about this topic.

Why does the post recommend building something small immediately instead of finishing a tutorial first?

The post describes a 'tutorial trap' where spending weeks on courses before writing real code creates the illusion of learning without actual skill. The recommended sequence starts with just 30 minutes of high-level overview and then immediately builds a small project, because the act of coding forces you to confront real problems that tutorials gloss over. The test is simple: if you can't build something in the technology without looking at a tutorial, you haven't learned it — you've only consumed content about it.

What makes a good learning project when picking up a new tech stack?

According to the post, a good learning project must meet four criteria: it should be small enough to complete in 1-2 weeks, address a problem you genuinely care about so you stay motivated, force you to use the technology's core features, and be deployable. The motivation criterion matters because finishing the project — not just starting it — is what cements the learning.

How does the post suggest using AI tools when learning a new technology?

The post identifies the best uses of AI as debugging specific errors with full context, understanding why something works rather than just how, and getting a 'common pitfall' summary for a new concept before you encounter it yourself. The worst use is asking AI to generate the code for your learning project, because you won't understand what it wrote and the learning opportunity is lost.

What role does Anki play in the author's learning process, and when should a concept get a card?

The author uses Anki — a flashcard app with a spaced repetition algorithm — to retain infrequently used but important details such as command-line flags, Docker/Kubernetes YAML syntax patterns, and advanced TypeScript type patterns. The rule for adding a card is straightforward: if you Google the same thing twice, it goes into Anki. This prevents repeatedly rediscovering the same information instead of retaining it.

How does the one-month framework structure learning across four weeks?

The post lays out a week-by-week plan: Week 1 is building and deploying a 'Hello World' equivalent, Week 2 adds the most common feature for your use case, Week 3 involves encountering a hard problem and solving it properly, and Week 4 is building something for others to use. The fourth week is specifically highlighted because thinking about someone else using your code fundamentally changes how you approach it.