3 min read
Setting Up a Windows Machine for Development
Every new machine starts the same way: a fresh install, a browser you didn't ask for, and three hours of clicking through installers. It doesn't have to. The point of a good setup isn't a clean machine — it's a machine you can rebuild without thinking. A winget manifest, a dotfiles repo, and a short script get you from bare install to working environment in one sitting. Set it up once. Script it. Then never think about it again.
Every new machine starts the same way: a fresh install, a browser you didn't ask for, and three hours of clicking through installers. It doesn't have to. Here's a setup that gets a Windows box from out-of-the-box to working environment in about an hour, most of it unattended.
1. Strip the defaults first
Do this before you install anything, so you're not fighting reinstalls later.
Settings → System → Notifications: kill suggestions and tips.
Settings → Privacy & security → General: disable the advertising ID and personalised ads.
Taskbar: turn off Widgets, Chat, and Search highlights.
Uninstall the bundled apps you'll never open. Right-click → Uninstall is fine; PowerShell with
Get-AppxPackageif you want it scripted.
Optional but worth it: Settings → System → For developers → Developer Mode. This enables symlinks without elevation, which matters more than you'd think once you start managing dotfiles.
2. Package management with winget
winget ships with Windows 11 and turns setup into a script you can re-run on the next machine.
winget install --id Git.Git -e
winget install --id Microsoft.PowerShell -e
winget install --id Microsoft.VisualStudioCode -e
winget install --id Microsoft.WindowsTerminal -e
Better: export a manifest once, import it forever.
winget export -o packages.json
winget import -i packages.json
Commit that JSON to a dotfiles repo. New machine setup becomes one command.
3. WSL2
If any part of your stack assumes Linux — and most of it does — install WSL2 rather than fighting Windows-native ports.
wsl --install -d Ubuntu
A few things worth knowing up front:
Keep project files inside the Linux filesystem (
~/projects, not/mnt/c/...). Cross-filesystem I/O over the 9P protocol is slow enough to be noticeable on anynode_modules-sized directory.Cap resource usage with a
.wslconfigfile in your Windows user directory. WSL2 will happily balloon its VM memory otherwise:
[wsl2]
memory=8GB
processors=4
Docker Desktop hooks into the WSL2 backend directly. Install it on the Windows side, not inside the distro.
4. Terminal and shell
Windows Terminal is the only terminal worth using here. Set your WSL distro as the default profile, then spend ten minutes on the parts you'll look at every day:
A monospace font with programming ligatures and Nerd Font glyphs (JetBrains Mono, Cascadia Code).
A prompt that shows git state — Starship works identically in PowerShell and bash, so you configure it once.
Sensible PowerShell defaults in your
$PROFILE:PSReadLinewith history-based prediction turned on gets you most of the way to a modern shell.
5. Git and SSH
Set identity and line endings before your first clone. The line-ending config saves a whole class of confusing diffs:
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
git config --global init.defaultBranch main
git config --global core.autocrlf input # on WSL/Linux side
Generate an Ed25519 key, add it to your Git host, and add it to the agent:
ssh-keygen -t ed25519 -C "[email protected]"
If you're working across both Windows and WSL, decide early which side owns your keys and credentials rather than duplicating them. Sharing the Windows credential manager with WSL via credential.helper is usually the cleaner option.
6. The stuff people forget
Storage Sense on, so the machine cleans up temp files without you.
Power plan set to High Performance on a desktop. Windows will throttle in ways that are hard to diagnose later.
Backups: OneDrive or similar for documents, a dotfiles repo for config. If your setup isn't reproducible, it isn't finished.
Windows Defender exclusions for your project directories. Real-time scanning on a build tree costs real seconds.
Make it reproducible
The point of all this isn't a clean machine — it's a machine you can rebuild without thinking. A packages.json, a dotfiles repo, and a short setup script get you from bare install to working environment in one sitting.
Set it up once. Script it. Then never think about it again.