The 7 VS Code Settings I Change on Every New Machine (and Why the Defaults Slow You Down)

I set up a new machine last month and counted how long it took before VS Code felt like mine. Answer: about 15 minutes, most of it spent changing the same seven settings I change every single time.

The defaults are not bad. They are designed for a first-time user opening the editor for the first time. But I am not a first-time user, and neither are you if you are reading this. These seven changes are the difference between an editor that gets in my way and one that disappears while I work.

1. editor.fontLigatures: true

The default is false, which means code like != and => renders as two separate characters. Turn ligatures on and they merge into single symbols. It sounds cosmetic. It is not, quite.

The real benefit is reading speed on dense lines. !== as one glyph is easier to scan than three characters that your eyes have to assemble. I use the Cascadia Code font, which ships with ligature support built in, so this setting costs me nothing and pays off every time I read a comparison.

2. editor.formatOnSave: true

This one setting has saved me more arguments than any other. Every time I save, the file formats itself. Indentation, spacing, trailing commas, all handled. I never think about formatting, and I never commit a file with messy spacing because I was in a hurry.

The catch, and it is a real one: the formatter only works if your project has one configured. A Python project needs Black or Ruff wired up. A JavaScript project needs Prettier. Without that, format on save does nothing, and you will wonder why this setting was recommended.

"editor.formatOnSave": true

One more thing: turn on editor.formatOnSaveMode set to file if you work in big files, so the whole file formats instead of just the changed lines.

3. files.autoSave: afterDelay, with files.autoSaveDelay: 1000

I used to lose work to crashes and closed tabs. Not big chunks, just the last few minutes, which is somehow more annoying than losing a lot. Auto-save fixed it.

The delay matters. The default afterDelay value is 1000 milliseconds, one second after you stop typing, which is about right. Shorter and the editor saves mid-thought, which can trigger linters and formatters while you are still writing a line.

"files.autoSave": "afterDelay",
"files.autoSaveDelay": 1000

The honest downside: auto-save plus format on save means your file reshuffles itself a second after you stop typing. If that bothers you, set auto-save to onFocusChange instead, so it saves when you click away.

4. editor.tabSize: 2, with editor.detectIndentation: false

VS Code guesses your indentation from the file, and it guesses wrong often enough to matter. I have opened files where half the lines used two spaces and half used four, because the editor detected one style on line 10 and another on line 200.

Turning detection off and setting tab size to 2 gives me one consistent behaviour everywhere. Two spaces is the standard for JavaScript, TypeScript, HTML, CSS, and most config files. If I open a Python file, the Python extension overrides this to 4 anyway, which is correct.

"editor.tabSize": 2,
"editor.detectIndentation": false

5. editor.minimap.enabled: false

The minimap is the tiny code preview on the right edge. It looks impressive in screenshots and I have never once used it to navigate. On a small laptop screen it eats about 10 percent of my horizontal space, and it shows me a version of my code too small to read.

"editor.minimap.enabled": false

6. workbench.startupEditor: none

By default, VS Code opens a welcome tab every time you start it. I have read the welcome tab. I do not need to read it again. Setting the startup editor to none means the editor opens straight to my last files, and I start working in seconds instead of closing a tab first.

"workbench.startupEditor": "none"

This is the smallest change on the list and the one I notice most, because it happens every single time I open the editor. Small friction, repeated daily, is still friction.

7. editor.cursorBlinking: solid, with editor.cursorSmoothCaretAnimation: on

Two settings, one idea: make the cursor calm down. The default blinking cursor is fine, but a solid cursor is easier to find when you look back at the screen after reading documentation. And smooth caret animation, the cursor gliding instead of jumping, sounds like a gimmick until you try it for a day. Then the jumpy cursor feels broken.

"editor.cursorBlinking": "solid",
"editor.cursorSmoothCaretAnimation": "on"

I will admit this pair is pure preference. It does not make me faster. It makes the editor feel less jittery, and I spend eight hours a day looking at it, so feeling matters.

The honest downside

Seven settings will not fix a slow workflow. If your real problem is that you spend 20 minutes a day hunting for files, these changes will not help, and you should learn the quick-open shortcut, Ctrl+P, instead. Settings are the last 10 percent of editor speed. Shortcuts and extensions are the other 90.

One more warning: changing settings feels productive, and it is not. I have wasted whole evenings tuning my editor instead of writing code. Set these seven, stop, and go build something.