What you'll learn
Quick Answer
Learn six shortcuts: command palette, quick file open, go to definition, rename symbol, multi-cursor and find in files. Then learn the debugger. Setting a breakpoint and inspecting variables is faster than adding print statements and re-running.
Six shortcuts worth the muscle memory
Learn these one at a time over a week rather than all at once. On macOS substitute Cmd for Ctrl.
- Ctrl+Shift+P — Command Palette. The most important one. Every command in the editor is searchable here, so you never need to hunt through menus or remember another shortcut.
- Ctrl+P — Go to file. Type part of a filename and press Enter. Faster than the sidebar, and dramatically faster in a large project.
- F12 — Go to definition. Jump to where a function or variable is defined. Alt+Left goes back. This is how you read an unfamiliar codebase.
- F2 — Rename symbol. Renames a variable or function everywhere it is used, correctly. This is not find-and-replace — it understands scope, so it will not rename an unrelated variable with the same name.
- Ctrl+D — Select next occurrence. Press repeatedly to place a cursor on each occurrence, then edit them all at once.
- Ctrl+Shift+F — Find in all files. Search the whole project. Essential when you inherit code you did not write.
Ctrl+` opens the integrated terminal, which saves constantly switching windows. Those seven cover most of what you do all day.
The debugger, which almost nobody uses
The standard student workflow is to add a print statement, run, read the output, add another print, run again. It works, but each cycle costs a re-run, and the prints get left behind in the code.
A breakpoint replaces all of that. Click to the left of a line number to place one, then start debugging with F5. Execution pauses there and you can see every variable in scope at that moment, without having decided in advance which ones to print.
Four controls do most of the work:
- Continue (F5) — run until the next breakpoint.
- Step Over (F10) — run the current line, do not go inside function calls.
- Step Into (F11) — go inside the function on the current line.
- Watch panel — pin an expression and see its value update as you step.
The moment this pays off is a loop that produces the wrong answer on some iteration. Print debugging means printing every iteration and reading a wall of output. A conditional breakpoint — right-click the breakpoint and add a condition like i == 47 — stops exactly when you want and nowhere else.
Learning this once is worth more than any other item in this article.
Settings worth changing on day one
Open settings with Ctrl+comma and search for each:
- Format On Save — reformats consistently every time you save. Stops all arguments about indentation and makes diffs readable.
- Auto Save — set to
afterDelay. Removes an entire category of "why isn't my change working" confusion. - Word Wrap — on, unless you enjoy horizontal scrolling.
- Bracket Pair Colorization — on by default in recent versions, and worth confirming. Matching brackets get matching colours.
Extensions: install the official language extension for whatever you write — Python, or the relevant one for your stack — because that is what gives you go-to-definition, error squiggles and autocomplete that understands your code. A formatter for your language, and GitLens if you work in teams, cover most of the rest.
Resist installing thirty extensions. Each one adds startup time, and most students end up with several that do the same job while using none of them.
Git without leaving the editor
The Source Control panel (Ctrl+Shift+G) shows every changed file. Clicking one opens a side-by-side diff of what you changed.
Reviewing that diff before every commit is a genuinely valuable habit. It is where you notice the debug print you left in, the commented-out block you meant to delete, and the file you did not intend to stage. It takes seconds and prevents the commits that make a history unreadable — which matters, because recruiters do read commit histories.
You can stage, commit and push from the panel. Learning the git commands underneath still matters — see the git commands cheatsheet — because servers and CI systems have no editor. But for day-to-day review, the visual diff is genuinely better than reading terminal output.
Two habits that compound
Use the palette instead of learning shortcuts. When you want to do something, press Ctrl+Shift+P and type it in plain language. It shows the shortcut next to the command, so you learn shortcuts for the things you actually do, in the order you actually need them.
Open the folder, not the file. Using File → Open Folder on your project root gives the editor the context to offer go-to-definition, project-wide search and correct imports. Opening a single loose file disables most of what makes the editor useful, and a lot of beginners work this way for months without realising what they are missing.