Set up a development environment

A development environment is not one thing, it is a small stack of tools sitting between you and running code: something to write it in, something to run it, something to track every change, and a terminal to drive all three. None of it is complicated once it is set up, and it only has to happen once per machine. This walks through the six pieces you actually need, in the order you need them, with the exact commands for macOS, Windows, and Linux.

The toolkit at a glance

1. Install a code editor

Your editor is where most of your time goes, so start here. VS Code is the common default: free, and its own download page describes it as "Free, built on open source, and runs everywhere," with builds for Windows, macOS, and Linux on the same page.¹ Download the build for your OS, run the installer, and open the app once to confirm it launches.

It is not the only option. Sublime Text is a fast, lightweight editor worth trying if VS Code feels heavy on an older machine. Zed is a newer, keyboard-first editor built for speed. Pick one editor, install it, and move on, the rest of this guide works the same regardless of which one you land on.

2. Install a language runtime

Do not install every language "just in case." Install the one your first project actually needs, and add another later only once a real project needs it. Two runtimes cover most beginner projects, and they are not interchangeable, so pick per project.

• Node.js, for anything web or JavaScript: a website, a script that calls an API, a build tool. Download it from nodejs.org and take the LTS (Long-Term Support) build rather than the newest release, LTS is the version meant for real use and it gets support for longer.²
• Python, for scripts, data work, and automation. Download it from python.org, which offers installers for Windows, macOS, and Linux directly from that page.³

Install one, not both, unless you already know a project needs both. Once it is installed, verify it from the terminal itself, not from the installer's success message; the installer can finish cleanly and still leave the command unreachable until you open a fresh terminal window.

node -v
npm -v

python --version

3. Install and configure Git

Git is version control: a running history of every change you make to a project, with the ability to undo a mistake, work on a branch without touching the main copy, and collaborate without overwriting anyone. Install it from git-scm.com, which links out to the right installer for Windows, macOS, or Linux from one page.⁴ On Windows, run the installer directly. On macOS, the first time you run a Git command it can prompt you to install Apple's Command Line Tools, which is enough on its own. On Linux, install it through your distribution's package manager (for example apt or dnf).

git --version

Before your first commit, tell Git who you are. It stamps every single commit with this name and email, there is no default, and skipping this step makes your first commit fail with an error asking you to set it.

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

With Git installed and configured, four commands cover the loop you will run for the life of every project.

• git init, turns the current folder into a Git repository by creating a hidden .git folder that stores the whole history. Run it once, in a new project's root folder.⁶
• git status, shows what changed since your last commit and what is already staged. Run this constantly, it is the command you will type more than any other.
• git add <file> (or git add . for everything at once), stages a change so it will be included in the next commit.
• git commit -m "message", saves the staged changes as a permanent snapshot, with a short message describing what changed.

That loop, edit a file, git status, git add, git commit, is the entire day-to-day workflow. Branches, remotes, and git push sit on top of it and can wait until a project actually needs them.

4. Create a sane project folder layout

A folder with forty files loose at the top level is where a project starts to feel unmanageable. A handful of top-level folders and files, decided once, keeps that from happening.

my-project/
├── src/            # or app/, your code lives here
├── assets/         # images, fonts, static files
├── .gitignore
├── README.md
└── package.json    # or requirements.txt / pyproject.toml for Python

• src (or app): your actual source code, in its own subfolder, not the project root, so config files and the README do not get buried among dozens of code files.
• assets: images, fonts, and other static files that are not code.
• README.md: one file explaining what the project is and how to run it. Write it now, while you remember, not after you have forgotten.
• .gitignore: tells Git which files to never track. Without one, you will eventually commit a folder of installed dependencies, or a file full of secrets, straight into your history.

node_modules/
__pycache__/
.venv/
.env
dist/
build/
.DS_Store

Only the lines that match your stack matter; the rest do nothing and cost nothing sitting there unused.

5. Add an auto-formatter and a linter

Style arguments, tabs versus spaces, where a bracket goes, are a solved problem. Let a tool decide, set it to run automatically, and stop thinking about it. Two different jobs are doing this work, and they are not the same tool wearing two hats.

• A formatter rewrites your code into one consistent style on save, with no judgment involved. For JavaScript and web projects, Prettier is the common default. For Python, Black fills the same role.
• A linter reads your code without running it and flags likely bugs and style problems before they turn into errors. ESLint is the common default for JavaScript; Ruff or Flake8 fill that role for Python.

Install the pair that matches the runtime from step 2, then turn on "format on save" in your editor's settings so it runs without you asking. Once that is on, you stop making style decisions by hand and start seeing the linter flag the mistakes that actually matter.

6. Learn the terminal commands you need

You do not need a full command reference. A handful of commands cover moving around a project and running it, and the exact word differs slightly on Windows.

That last row is the one that actually varies by project rather than by OS: a Node project usually defines its run command inside package.json (often npm run dev or npm start), and a Python script just runs with python followed by the file name. Both commands are identical on every OS, since Node and Python are themselves cross-platform.

1. 1Install an editor (VS Code or an alternative) and confirm it opens and saves a file.
2. 2Install the one runtime your project needs, Node.js or Python, and verify it with node -v or python --version.
3. 3Install Git, set your name and email with git config --global, and learn init, status, add, commit.
4. 4Create a src (or app) folder, an assets folder, a README, and a .gitignore that matches your stack.
5. 5Turn on a formatter and a linter for your language, and enable format-on-save.
6. 6Learn cd, ls/dir, and the command that runs your project, and use them instead of a file explorer.