Set up a real dev environment

A broken environment is one of the most common reasons beginners quit in their first week — not because the code was too hard, but because nothing would run. Setting up your tools properly is infrastructure, not busywork: you do it once, carefully, and then use it every day. This lesson walks through the pieces and how they fit together.

The four pieces of a dev environment

Almost every developer setup, whatever the language, has the same parts:

• A code editor where you write and navigate code.
• A terminal where you run commands: start programs, install packages, run tests.
• A language runtime that actually runs your code, such as Node.js for JavaScript or Python.
• Version control, almost always Git, which records the history of your project.

These pieces talk to each other. Your editor usually has a terminal built in, the terminal runs the runtime, and Git tracks the files your editor changes. When something "doesn't work," the first skill is figuring out which piece is involved. Is the code wrong, is the tool not installed, or are you running it in the wrong place?

Choosing and learning your editor

VS Code is a very common choice: it's free, runs on every operating system, and most tutorials assume it. Other good options exist, such as JetBrains editors or Zed; what matters is picking one and learning it well.

Learn these basics early:

• Open a folder, not a single file. Your project is a folder, and the editor's search, file tree, and terminal all work relative to it.
• Jump between files quickly with the file finder (Ctrl+P, or Cmd+P on macOS) instead of clicking through folders.
• Use the integrated terminal, which opens in your project folder.
• Add extensions slowly. Start with a formatter and support for your language. Dozens of extensions at once make the editor slow and can fight each other, for example two formatters rewriting the same file.

The terminal and your operating system

On macOS and Linux, the built-in terminal is ready to use, and most tutorials are written for this kind of shell.

On Windows, you have two reasonable paths. PowerShell works for many tools, but commands in tutorials often won't match exactly. The route most web developers take is WSL (Windows Subsystem for Linux), which runs a real Linux environment inside Windows so tutorials work as written. If you use WSL, install your tools inside Linux, and keep your projects in the Linux file system (for example ~/projects) rather than under /mnt/c/. Working across that boundary is noticeably slower and causes odd file-watching problems.

VS Code can open WSL folders directly, so you get a Windows editor with Linux tools underneath.

Installing a language runtime

For JavaScript, you need Node.js, which also includes npm for installing packages. Rather than a one-off installer, use a version manager such as nvm or fnm. Different projects often need different Node versions, and a version manager lets you switch per project. It also installs everything in your home folder, so you never need sudo for global packages. Permission errors that tempt you to use sudo npm install -g are a sign the setup is wrong.

Your terminal finds programs through a list of folders called PATH. Installers add to it, but terminals that were already open don't notice. If a fresh install says "command not found," open a new terminal (or restart your editor) before anything else.

Version control from day one

Install Git and tell it who you are. Git refuses to make your first commit without this:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Then use it from the start, even on tiny practice projects:

git init
git add .
git commit -m "Add working greeting script"

A commit is a saved snapshot you can return to. The habit that matters: commit every time something works. If you break your code an hour later, you can see exactly what changed or go back. Without commits, "it worked earlier" is just a memory. Later you'll push to GitHub too, but local commits are useful on their own.

Try it: build and verify your setup

Set up your real environment now, then prove it works end to end:

1. Install your editor, Git, and Node.js through a version manager (on Windows, inside WSL).
2. In a new terminal, check each tool responds:

node -v
npm -v
git --version

3. Create a folder hello-dev, open that folder in your editor, and add index.js containing console.log("it works").
4. In the integrated terminal, run node index.js and see the output.
5. Run git init and make your first commit.

If any step fails, read the error, identify which piece it belongs to, and fix that before moving on.