Phase 2: Dev Environments & Dependency Management · ~30 minutes · VS Code · dev containers · LSP

Editors, Environments, and Real Workflow

Jump-to-definition isn't a text search. It's your editor asking a real program — a language server — "where is this actually defined," and getting a real, code-aware answer.

Hiring signal: Diagnoses a slow or broken workflow by the correct layer (editor, environment, or container), not by guessing

What you will learn

Explain what an IDE/LSP setup actually provides beyond syntax highlighting
Explain a dev container as 'my editor, running inside my reproducible environment'
Configure a working dev-container setup for a real small project
Diagnose which layer — editor, environment, or container — is the actual source of a workflow complaint

Introduction

Type: Learn Languages: VS Code, JSON Prerequisites: Lesson 03 (Containers: What They Actually Are) Time: ~30 minutes

Objective

Learning objectives

Explain what an IDE/LSP setup actually provides beyond syntax highlighting
Explain a dev container as "my editor, running inside my reproducible environment"
Configure a working dev-container setup for a real small project
Diagnose which layer — editor, environment, or container — is the actual source of a workflow complaint

What you're building

Set up a real dev container configuration (.devcontainer/devcontainer.json plus a Dockerfile, building on Lesson 03's work) for a small project with at least one real dependency
Open the project inside the dev container in your editor, and confirm a real language feature (autocomplete for a method on your installed dependency, or jump-to-definition into that dependency's own source) reflects the container's environment, not any local installation
Deliberately create a mismatch to see it for real: temporarily install a different version of the same dependency locally (outside the container) and confirm the editor's dev-container-mode behavior stays correct, unaffected by the local mismatch
Write workflow_notes.txt describing one real complaint ("autocomplete is wrong," "code behaves differently here than there") and correctly diagnosing which layer — editor, environment, or container — it actually belongs to, using this lesson's table

A developer complains: "My editor says this function doesn't exist, but I can run the script and it works completely fine." What's the most likely diagnosis?

This is exactly the pandas 1.5/2.2 predict block pattern, generalized. The code genuinely running successfully proves the function DOES exist in whatever environment actually executes it. The editor reporting otherwise means its language server is checking against a different environment — almost certainly a local installation that doesn't match the real one (a missing or misconfigured dev container, most likely). This is a diagnosable, fixable mismatch between layers, not a code bug and not a broken editor — exactly the kind of complaint this lesson's table exists to correctly route.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.