How to use VS Code like a software engineer (not a student)

VS Code is what 80% of software engineers actually use day-to-day, including the people who paired with you in screensharing and seemed to be moving twice as fast as you. The difference is rarely talent. It's about ten muscle-memory shortcuts and a few config choices. Spend two hours on this guide and you'll feel like a different programmer by the end of the week.

The mindset

Beginners use VS Code as a fancier Notepad: open file, type, save. Engineers use it as a navigation and refactoring tool that happens to also let you type. The shift is from "where in the file is the thing" to "the editor finds the thing for me."

The two biggest unlocks: the Command Palette and Go to Definition. If you only learn two things from this guide, learn those two.

The 12 shortcuts that pay back hours per week

Memorize these. Use a Post-it on your monitor for the first week if you have to. After two weeks they become reflex.

Conventions: Mac uses Cmd, Windows/Linux uses Ctrl. I'll write Mac shortcuts; substitute Ctrl for Cmd on Windows/Linux.

The Command Palette is the answer to almost everything

If you only remember Cmd+Shift+P, you can do everything else. Hit it, then start typing what you want:

• "format" → "Format Document" formats your current file
• "git" → see all git commands
• "toggle word" → toggle word wrap
• "reload" → "Reload Window" if VS Code is acting weird
• "close" → various close commands
• "theme" → "Color Theme" switcher

The palette also has a fuzzy match, so "fmt doc" finds "Format Document." When you don't know how to do something, palette first, Google second.

Multi-cursor: the trick that looks like magic

Three ways to put cursors in multiple places at once:

Cmd+D for the same word

Place your cursor on a word, hit Cmd+D. The same word is selected. Hit it again, the next occurrence is selected too. Now you have N cursors, one at each occurrence. Type, and all of them update.

Option+Click for arbitrary positions

Hold Option (Alt on Windows), click anywhere. A cursor appears there too. Click another spot, another cursor. Useful for editing five different lines at once.

Column selection

Cmd+Shift+L selects all occurrences of the current word at once. Bigger hammer; use carefully.

Practical example. You have:

const userId = req.body.userId;
const userName = req.body.userName;
const userEmail = req.body.userEmail;

You want to switch all req.body to req.params. Click on "body," Cmd+D twice to select all three, type "params," done. Three seconds.

Go to Definition: the navigation unlock

The single biggest difference between a junior who scrolls and a senior who navigates: F12 on any symbol jumps to where it's defined. Across files, across packages, into node_modules if you want.

You'll use it 50+ times a day in an unfamiliar codebase. Pair it with Cmd+- (Mac) / Alt+- (Win) to navigate back where you came from.

The pattern that emerges: read a function, see it calls something unfamiliar, F12 to jump in, read that, navigate back, continue. This is what code-reading looks like for a senior.

Find All References: the safety net before you change something

Shift+F12. Right-click a function name, "Find All References." Now you see every place that function is called. Before you change its signature, you know who you might break.

Without this, you change a function and three other things in the codebase silently break. With this, you check first and update them all in the same PR.

Settings worth changing on day one

Open settings with Cmd+,. The defaults are fine for casual use; these are the changes I'd make for serious work.

Format on save

"editor.formatOnSave": true

Your file is auto-formatted every time you save. No more "fix formatting" PR review comments. Pair with a project-level Prettier or ESLint config.

Auto save

"files.autoSave": "onFocusChange"

Files save when you switch tabs. Stops you from running stale code.

Tab size

"editor.tabSize": 2,
"editor.insertSpaces": true,
"editor.detectIndentation": true

Most JS/TS/JSON projects use 2 spaces. Most Python projects use 4. detectIndentation auto-detects per file based on what's already there.

Word wrap (or not)

"editor.wordWrap": "on"

Personal preference. Turning on word wrap means long lines fold instead of scroll horizontally. Some teams disable it because they enforce a 100-char limit anyway.

Bracket pair colorization

"editor.bracketPairColorization.enabled": true,
"editor.guides.bracketPairs": "active"

Matching brackets get matching colors. Lifesaver in deeply nested code.

Extensions that pay off (and the ones that don't)

Worth installing on day one

• Language extension for your stack. Python (Microsoft), Go, Rust Analyzer, Java Extension Pack. Get type hints, autocomplete, and inline errors. Non-negotiable.
• ESLint + Prettier for JS/TS projects. Lints and formats on save.
• GitLens. Inline git blame on every line. Hover for the commit message. Best way to find out "who wrote this and why."
• EditorConfig. Respects your project's .editorconfig file (indent style, line endings, charset). Required if your team has one.
• Error Lens. Shows linter and type errors inline next to the code, instead of waiting for the underline. Speeds up the debug loop dramatically.

Skip these unless you have a specific reason

• Theme bonanzas. One theme is plenty. Don't chase the perfect dracula variant.
• Icon packs. Material Icon Theme is the only one worth installing. Stop there.
• "Productivity" extensions with vague names. Most slow VS Code down for marginal benefit.
• AI completion you don't trust yet. Copilot/Cursor/Continue are powerful, but use them after you can do the work yourself. Skipping the learning step makes you worse.
• VS Code variants. Cursor, Windsurf, etc. They're forks of VS Code with AI baked in. Useful, but learn vanilla VS Code first; the muscle memory transfers.

The integrated terminal

Ctrl+` opens a terminal in your project root. Things to know:

• You can have multiple terminals (+ button in the panel) and split them side by side.
• Right-click a file in the explorer, "Open in Integrated Terminal" opens a terminal in that subdirectory.
• Drag a file into the terminal pane to paste its full path. Saves typing.
• Cmd+click a file path or URL printed by a process to open it.

The git panel

The Source Control icon in the sidebar is a full Git GUI. You can:

• See your changed files (modified, untracked, staged).
• Stage files with one click (the + icon).
• Diff each file before committing (click the file name).
• Write a commit message and commit.
• Push, pull, and switch branches without leaving the editor.

You don't have to use it. Plenty of senior engineers stay in the terminal. But for staging tricky multi-file changes, the GUI's diff-by-diff view is genuinely better than git add -p for visual learners.

Workspaces and multi-folder setups

If your work spans two repos that you edit together (e.g., a frontend and backend), use a multi-folder workspace:

1. File → Add Folder to Workspace
2. File → Save Workspace As → save the .code-workspace file somewhere
3. Open the .code-workspace file next time

Now both folders share one VS Code window with searches, terminals, and git scoped per folder.

Live Share for pairing

VS Code Live Share lets you share your editor with a teammate in real time. Both people see the same cursor, edits, and terminal. Way better than screensharing for actual pairing.

Useful for: a senior helping you debug, a peer reviewing your in-progress work, an interview coding round.

Things that look smart but mostly aren't

• Vim mode. If you already know Vim, fine. Don't learn Vim mode just to look hardcore; the learning curve isn't justified for most internship work, and it makes pairing weird.
• Custom keybinding everywhere. Tweak 1-2 things if a default annoys you. Don't rebuild the entire keymap; you'll regret it the first time you sit at someone else's machine.
• Snippets you wrote three months ago. Most language extensions provide good defaults. Custom snippets for things you write twice a year aren't worth maintaining.

The 5-minute drill

Open a real codebase right now and do these five things in order:

1. Cmd+Shift+P, type "git", look at all the git commands available.
2. Cmd+P, type 3 letters of any file, hit Enter.
3. Find any function, hit F12 on its name to jump to the definition.
4. Same function, Shift+F12 to see all callers.
5. Pick a variable name, Cmd+D twice to select 3 occurrences, type a new name.

If those five things feel awkward, repeat them tomorrow. By Friday they're automatic. By month two, you wonder how you ever scrolled to find anything.

The mindset shift, restated

You're not editing files; you're navigating a graph of code. The editor's job is to take you to the right node fast and let you change it without breaking edges (references). The shortcuts above are how you operate that graph.

The senior engineers who seem to be moving "twice as fast" aren't typing twice as fast. They're navigating the graph instead of scrolling files.