You’ve got a new Windows 11 machine. Before you install anything, there are three things you need to do — and most setup guides skip the first one entirely. Here’s the sequence that actually works: clear the junk first, get your package manager in place, then layer everything else on top. Follow this order and you’ll have a production-ready dev environment in under an hour.
TL;DR — Windows 11 Developer Setup at a Glance
- Clear the Decks — Remove bloatware and configure privacy settings before touching dev tools
- winget — Your package manager; everything else gets installed through it
- WSL2 — A real Linux kernel inside Windows; where your code actually runs
- Windows Terminal — Replace the old console; one config to rule all your shells
- Git + VS Code — Configured properly, connected to WSL2, ready to work
| Tool | Purpose | Install command | Notes |
|---|---|---|---|
| winget | Package manager | winget -v (confirm) | May need App Installer update |
| WSL2 | Linux kernel | wsl --install | Requires restart |
| Windows Terminal | Modern console | winget install Microsoft.WindowsTerminal | Set as default in Settings |
| Git | Version control | winget install Git.Git | Configure name/email/SSH after |
| VS Code | Editor | winget install Microsoft.VisualStudioCode | Install Remote WSL extension |
New to Windows dev setup? Start with First 30 Minutes: Clear the Decks — skipping it means installing tools on top of a system that will fight you later.
First 30 Minutes: Clear the Decks
Run Windows Update fully before anything else. Driver and security updates can trigger restarts that interrupt installs — get them out of the way now. Once that’s done, remove the pre-installed apps you will never use. The Xbox app, Candy Crush, the weather widget, and the news feed all slow down your first boot experience and add background noise to your system.
Next, sort out privacy settings before they phone home. Go to Settings → Privacy & Security and turn off: Advertising ID, Activity History, and the diagnostic data setting (set to Basic). Then go to Settings → System → For Developers and enable Developer Mode — this is required for symlinks, which WSL2 and some tools depend on. Finally, confirm your region and timezone are correct; WSL2 inherits the Windows clock and a wrong timezone causes subtle issues with timestamps and SSL certificates.
winget: Your Package Manager
winget is the Windows Package Manager, built into Windows 11. It does what brew does on macOS or apt does on Ubuntu — you tell it what you want and it installs it. Check it’s present by running winget -v in PowerShell. If you get a version number, you’re good. If not, open the Microsoft Store, search for “App Installer”, and update it.
You can also create a one-shot setup script. Save this as setup.ps1 and run it on any new machine to install everything in sequence:
WSL2: Linux Inside Windows
WSL2 (Windows Subsystem for Linux 2) runs a real Linux kernel in a lightweight virtual machine alongside Windows. This is not emulation or a compatibility layer — it is a genuine Linux kernel. When you run Node, Python, or Docker inside WSL2, you are running them on Linux. This matters because it eliminates an entire class of path, permission, and toolchain compatibility problems that plagued Windows development before WSL2 existed.
After the restart, Ubuntu will open and ask you to create a Linux username and password (separate from your Windows account). Once that’s done, the most important thing to understand is the file system split: your Linux home directory at ~/ is fast — use it for all your projects. The Windows filesystem at /mnt/c/ is accessible from WSL2 but slow for I/O. Keep your code in Linux and you will notice the difference immediately.
Windows Terminal: Ditch the Old Console
Windows Terminal is the modern replacement for cmd.exe and the old PowerShell window. It supports multiple profiles (WSL2, PowerShell, cmd), tabs, split panes, and proper font rendering. Install it via winget if it’s not already there, then set it as your default terminal: Settings → System → For Developers → Terminal → Windows Terminal.
Once installed, open Settings (Ctrl+,) and set Ubuntu (WSL2) as your default profile. Change the starting directory for the WSL2 profile to //wsl$/Ubuntu/home/YOUR_USERNAME so Terminal opens directly in your Linux home rather than the Windows filesystem. For fonts, Cascadia Code ships with Windows Terminal and renders cleanly; if you use powerline prompts in your shell, install a Nerd Font variant instead.
Git: Install and Configure Properly
Install Git for Windows via winget, then do all your Git configuration inside the WSL2 terminal — that’s where your projects will live. The global config and SSH setup below should take about five minutes and will save you from authentication headaches for the lifetime of this machine.
The core.autocrlf input setting is important: it prevents Git from converting Linux line endings (LF) to Windows line endings (CRLF) when you check out files. If you skip this and later push code to a Linux server, you will get mysterious shell script failures caused by invisible carriage return characters.
VS Code: Install and Connect to WSL2
Install VS Code via winget, then install the Remote WSL extension. This single extension is what makes VS Code on Windows feel exactly like VS Code on Linux — it runs the editor UI on Windows while connecting the language servers, linters, and terminal to your WSL2 environment.
When you run code . from inside your WSL2 terminal, VS Code opens with its server running in Linux. The integrated terminal is your WSL2 bash or zsh session. Extensions run in Linux context. There are no path translation issues. Add GitLens (eamodio.gitlens) and Prettier (esbenp.prettier-vscode) as your first two extensions, then use Settings Sync (sign in with GitHub) to back up your configuration.
You’re Done — What’s Next
At this point you have a clean Windows 11 base, a package manager, a Linux kernel, a proper terminal, Git with SSH authentication, and VS Code connected to all of it. That is a production-grade developer environment. The next step is tuning it for your specific stack — install your language runtime (Node via nvm, Python via pyenv, Rust via rustup) inside WSL2 exactly as you would on Ubuntu.
Related: Is Your Windows Dev Environment a Mess? Here’s How to Fix It — if you already have a Windows setup that needs sorting rather than starting from scratch.
Related: Switching to Windows as a Developer: Make It Feel Like Home — if you’re coming from Mac or Linux and want a translation guide.
Frequently Asked Questions
Do I need WSL2 to develop on Windows?
Not strictly, but WSL2 removes almost every compatibility headache that makes Windows development frustrating. Path issues, line endings, missing Unix tools, Docker performance — WSL2 eliminates all of them. If you are building software that runs on Linux servers (which is most software), developing inside WSL2 means your local environment matches production.
Should I use winget or Chocolatey?
winget for a new setup in 2026. It is built into Windows 11, maintained by Microsoft, and covers everything in this guide. Chocolatey has a larger package library and has been around longer, but winget is sufficient for most developers and removes the need for a third-party tool. If you hit a package that winget does not have, install Chocolatey alongside it — they coexist without issues.
Can I use this setup for any programming language?
Yes. WSL2 gives you a full Ubuntu environment. Python, Node, Rust, Go, Ruby, Java — install them inside WSL2 using apt or a version manager (nvm, pyenv, rustup) exactly as you would on Linux. The only exception is .NET development, which works better with the Windows-native toolchain, though it also runs inside WSL2 if you prefer consistency.