If you have installed Visual Studio Code, opened it, and seen a

screen full of icons, panels, tabs, menus, and buttons, you may have wondered:

What am I actually supposed to do with all of this?

That is a reasonable question.

VS Code is deliberately designed to be flexible. It can be a lightweight code editor, a complete web-development workspace, a Git client, a debugging environment, a terminal, a remote-development interface, an AI-assisted development environment, and much more.

That flexibility is powerful—but it also means that a beginner can easily confuse having many features with knowing how to use the environment.

The goal of this chapter is different.

You are going to learn how to think about VS Code as a development workbench.

By the end, you should understand:

what the main areas of VS Code are;
how files and folders become projects;
how the Explorer works;
how to navigate quickly;
how the Command Palette changes the way you work;
how tabs and editors work;
how to search an entire project;
how settings work;
what workspace settings mean;
what extensions actually do;
how the integrated terminal fits into development;
how terminal profiles work;
how Git fits into the editor;
what VS Code profiles are;
how to avoid extension and configuration clutter;
how to create a clean project workspace;
and how to turn VS Code into a repeatable development system.

The important mental model is:

VS Code is not the project. It is the workspace through which you understand, edit, run, test, debug, organize, and manage the project.

1. First Understand What VS Code Actually Is

Visual Studio Code is an editor and development environment.

It gives you a place to work with the files and tools that make up software projects.

Those files might include:

HTML;
CSS;
JavaScript;
TypeScript;
Python;
PHP;
JSON;
Markdown;
configuration files;
source code;
images;
documentation;
scripts;
environment configuration;
package manifests;
tests.

But VS Code does not replace all the technologies you use to build software.

For example, if you are building a JavaScript application, you may still need:

a JavaScript runtime;
a package manager;
Git;
a browser;
databases;
command-line tools;
cloud services;
APIs.

VS Code provides a unified place where many of these tools can be used together.

Think of it like a workshop.

A workshop does not manufacture everything itself.

Instead, it gives you:

a workspace;
tools;
storage;
work surfaces;
organization;
access to specialized equipment.

VS Code plays a similar role for software development.

2. The Core Mental Model

A beginner often thinks about VS Code like this:

"I open VS Code and write code."

A developer eventually thinks about it more like this:

"I open a project in VS Code, inspect its structure, edit files, run tools, inspect results, track changes, debug problems, and repeat."

That difference is important.

Your workflow becomes:

PROJECT

↓

FILES

↓

CODE

↓

TOOLS

↓

RUN

↓

TEST

↓

DEBUG

↓

CHANGE

↓

VERIFY

↓

SAVE HISTORY

The editor is the centre of this loop.

3. Understand the VS Code Workbench

The main VS Code interface is called the workbench.

It contains several major areas.

A simplified model is:

ACTIVITY BAR

→ choose major views

SIDE BAR

→ inspect the selected view

EDITOR AREA

→ open and edit files

PANEL

→ terminal, problems, output, debugging information, etc.

STATUS BAR

→ information about the current workspace/file/environment

VS Code's official documentation describes views such as Explorer, Search, Source Control, Run and Debug, and Extensions as core parts of the interface.

You do not need to memorize every button.

Instead, understand what each area is responsible for.

4. The Activity Bar Is Your Navigation System

The Activity Bar gives you quick access to major VS Code views.

Common views include:

Explorer;
Search;
Source Control;
Run and Debug;
Extensions.

Extensions can also add their own views.

Think of the Activity Bar as:

"Which part of my development environment do I want to inspect?"

For example:

Explorer

→ What files exist?

Search

→ Where does this code appear?

Source Control

→ What changed?

Run and Debug

→ Why is the program behaving this way?

Extensions

→ What capabilities can I add or manage?

This makes the interface much easier to understand.

5. Explorer Is Your Project Map

The Explorer shows the files and folders available in your workspace.

Suppose your project looks like this:

my-website/
├── index.html
├── css/
│   └── style.css
├── js/
│   └── app.js
├── images/
│   └── logo.png
└── README.md

The Explorer gives you a visual representation of that structure.

This matters because software projects are not just collections of individual files.

They are organized systems.

A developer needs to know:

where files live;
what each folder represents;
which files depend on others;
where configuration lives;
where assets live;
where tests live;
where generated files appear.

Good project organization therefore becomes part of good development.

6. Open the Folder, Not Just Individual Files

This is one of the most important habits to develop.

A beginner may double-click:

index.html

and start editing it.

A better workflow is usually to open the project folder.

For example:

my-website/

Once the folder is open, VS Code can understand the broader workspace.

You can then see:

related files;
folders;
project settings;
source control;
configuration;
dependencies;
scripts.

The difference is:

Opening a file

versus

Opening the project that contains the file.

Professional development is generally project-oriented.

7. What Is a Workspace?

A workspace is the environment in which VS Code manages your project.

For a simple project, the workspace may simply be the folder you opened.

For more complex projects, VS Code can also work with multi-root workspaces containing multiple folders.

The important concept is:

The workspace defines the context in which you are working.

That context can influence:

settings;
extensions;
tasks;
source control;
debugging;
file navigation;
project-specific behavior.

VS Code supports both user-level settings and workspace-level settings. Workspace settings can override user settings and are stored within the workspace configuration.

8. User Settings vs Workspace Settings

This distinction is extremely useful.

Imagine you prefer:

Word Wrap = On

You may want that preference everywhere.

That is a user setting.

Now imagine a particular project requires:

Format On Save = Off

because of a special workflow.

You may want that only for that project.

That is a workspace setting.

Think of the difference as:

USER SETTINGS

→ "How I generally work."

WORKSPACE SETTINGS

→ "How this particular project works."

VS Code supports both.

This distinction becomes increasingly important as you work on multiple projects.

9. Settings Are Configuration, Not Magic

VS Code contains a huge number of configurable behaviors.

You can change things such as:

font size;
word wrapping;
formatting;
editor behavior;
files;
terminal behavior;
language-specific settings;
debugging behavior;
extension settings;
interface appearance.

The Settings editor gives you a graphical interface for these options.

Behind the interface, VS Code stores configuration in settings.json.

This gives you two ways to think about configuration:

Visual configuration

Use the Settings interface.

Text-based configuration

Edit settings.json.

Beginners can start with the visual interface.

As you become more comfortable, understanding the JSON configuration becomes increasingly useful.

10. Do Not Change Settings Just Because You Can

VS Code allows enormous customization.

That does not mean you should customize everything.

A common beginner mistake is:

"I found 30 recommended settings online, so I should add all 30."

That can create confusion.

A better rule is:

Change a setting because you understand the problem it solves.

For example:

You find long lines difficult to read.

Enable word wrapping.

You want files to format automatically.

Configure formatting deliberately.

You want a larger editor font.

Increase the font size.

Every configuration should have a reason.

Your workspace should become simpler, not more mysterious.

11. Learn the Command Palette Early

If there is one VS Code feature worth learning early, it is the Command Palette.

Open it with:

Ctrl + Shift + P on Windows/Linux

Command + Shift + P on macOS.

The Command Palette gives you access to VS Code commands without requiring you to remember where every command lives in the menus.

This changes how you interact with the editor.

Instead of asking:

"Where is that command?"

you can ask:

"What is the command called?"

Then search for it.

12. Think of the Command Palette as VS Code's Command Interface

Suppose you want to:

change the color theme;
open settings;
reload the window;
select a terminal profile;
format a document;
configure Git;
open a specific view;
create a profile.

You can often search for the relevant command.

This creates a powerful habit:

NEED SOMETHING

↓

OPEN COMMAND PALETTE

↓

SEARCH FOR THE ACTION

↓

RUN COMMAND

You do not need to memorize the entire VS Code interface.

You need to know how to ask VS Code for an action.

13. Quick Open Is Different

There is another extremely useful navigation tool: Quick Open.

Its purpose is mainly to help you quickly find files and symbols.

Instead of opening folders manually and scrolling through the Explorer, you can search for a file by name.

For a project containing hundreds of files, this can save substantial time.

The principle is:

Do not browse manually when you already know what you are looking for. Search for it.

This principle applies throughout VS Code.

14. Search the Whole Project

The Search view is more powerful than searching inside one file.

Imagine your project contains:

index.html
app.js
dashboard.js
settings.js
api.js

You want to find every occurrence of:

API_URL

Project-wide search lets you locate those references.

This becomes extremely useful when:

changing a variable name;
finding references;
locating configuration;
identifying duplicated code;
investigating bugs;
understanding an unfamiliar project.

The general workflow becomes:

QUESTION

→ SEARCH PROJECT

→ FIND REFERENCES

→ UNDERSTAND CONNECTIONS

→ MAKE CHANGE

→ VERIFY RESULTS

That is much more reliable than opening files randomly.

15. Learn the Difference Between a File and a Tab

When you open a file in VS Code, it appears in the editor area as a tab.

But the tab is not the file.

The tab is simply an interface representation of the file you are working on.

This distinction matters because you may have:

many files;
multiple editor groups;
split views;
temporary previews;
pinned tabs.

Do not confuse:

what you see in the editor

with

what actually exists on disk.

The filesystem remains the underlying project structure.

16. Split the Editor When You Need to Compare Things

Suppose you are editing:

app.js

while also checking:

index.html

You can use split editor groups to see both.

This is useful for:

comparing files;
reading documentation while coding;
comparing old and new implementations;
checking HTML against CSS;
inspecting configuration alongside source code.

But again, do not split everything simply because you can.

The purpose is to reduce context switching.

17. The Integrated Terminal Changes the Workflow

One of VS Code's most useful features is its integrated terminal.

Instead of constantly switching between:

VS Code

and

External Terminal

you can run command-line tools inside the VS Code workbench.

The official documentation describes the integrated terminal as a full shell environment that can run the same command-line tools you would use externally. It can also support multiple terminals and split terminal sessions.

This is important because modern software development relies heavily on command-line tools.

18. What Can You Do in the Terminal?

Depending on your operating system and installed tools, you might run commands such as:

git status

or:

npm install

or:

npm run dev

or:

python app.py

or:

mkdir project

or:

code .

The exact commands depend on your technology stack.

The important concept is:

VS Code does not replace the command line. It brings the command line into your development workspace.

19. Understand Terminal Profiles

Different operating systems can have different shells.

For example, Windows may provide:

PowerShell;
Command Prompt;
Git Bash;
WSL.

Linux and macOS commonly provide Unix-style shells such as:

Bash;
Zsh;
other installed shells.

VS Code detects available shells and allows you to configure terminal profiles.

A terminal profile can specify things such as:

shell executable;
arguments;
environment variables;
profile name;
other configuration.

You do not need to configure advanced profiles immediately.

But you should understand what they are.

20. The Terminal and Editor Work Together

Imagine you are building a website.

Your workflow might look like:

EDIT

→ app.js

↓

RUN

→ npm run dev

↓

OPEN

→ browser

↓

TEST

→ observe behavior

↓

RETURN

→ VS Code

↓

EDIT

→ app.js

↓

RUN

→ test again

This is the development loop.

The editor creates the change.

The terminal runs the tools.

The browser or application reveals the result.

You return to the editor and improve the code.

21. Extensions Add Capabilities

VS Code is extensible.

Extensions can add support for:

programming languages;
frameworks;
debuggers;
formatters;
linters;
source-control systems;
cloud platforms;
databases;
remote development;
specialized workflows.

VS Code's official documentation describes extensions as a way to add languages, debuggers, source-control providers, and connections to external tools and services.

This is one reason VS Code can serve many different types of developers.

22. But Extensions Are Not Automatically Good

A beginner may think:

"More extensions = better VS Code."

Not necessarily.

Every extension adds another piece of software to your environment.

Extensions can:

consume resources;
add configuration;
modify the interface;
introduce conflicts;
create security considerations;
make troubleshooting harder.

So use the principle:

Install an extension because it solves a real problem.

Not:

Install it because someone said every developer needs it.

23. Start With the Language Support You Actually Need

If you are learning web development, your needs may initially be simple.

You may need:

HTML support;
CSS support;
JavaScript/TypeScript support;
Git;
perhaps a formatter or linter when you understand why you need one.

You do not need a giant collection of extensions on day one.

Build your environment as your development needs grow.

That creates a cleaner mental model.

24. Extensions Can Have Their Own Settings

An extension can add configuration options to VS Code.

For example, a formatter extension may provide formatting settings.

A language extension may provide language-analysis settings.

These appear through VS Code's Settings interface.

This means that when something behaves unexpectedly, the problem may not be caused by VS Code itself.

It could be:

the extension;
the extension's configuration;
a workspace setting;
a conflict between extensions.

That is why disciplined configuration matters.

25. Use Profiles to Separate Different Development Environments

As your work grows, you may eventually work on very different kinds of projects.

For example:

Web Development

→ HTML, CSS, JavaScript

Python

→ Python tools, debugging, formatting

Data Science

→ notebooks, Python, data tools

Writing

→ Markdown, publishing tools

You could install everything into one giant configuration.

But VS Code provides Profiles so you can create separate sets of settings, extensions, keyboard shortcuts, UI customizations, and other configuration for different workflows.

This is a powerful concept.

Instead of:

ONE HUGE VS CODE

you can think:

ONE VS CODE

with:

WEB PROFILE

PYTHON PROFILE

DATA PROFILE

WRITING PROFILE

and so on.

26. Why Profiles Matter

Imagine you have 60 extensions installed.

Some are relevant to web development.

Others are relevant to Python.

Others are relevant to another project.

Your environment becomes increasingly difficult to understand.

Profiles let you separate these contexts.

For example:

Web Development Profile

HTML/CSS/JS tools
web debugging
Git
frontend utilities

Python Profile

Python
debugging
formatting
Python-specific tooling

The goal is not to create dozens of profiles.

The goal is to create clear working environments when they provide real value.

27. Your Workspace Can Be Part of the Configuration

A project can have its own configuration.

For example:

my-project/
└── .vscode/
    └── settings.json

Workspace settings can therefore travel with a project when appropriate.

This is useful when a project has requirements that differ from your personal defaults.

For example:

User setting:
wordWrap = on

while:

Project setting:
some-project-specific-behavior = ...

The important principle is:

Personal preferences belong to you. Project requirements belong to the project.

Keeping those concepts separate makes development environments easier to reproduce.

28. Git Is Part of the Development Environment

VS Code includes built-in Git support.

But it is important to understand the distinction:

Git

is the version-control system.

GitHub

is a service that can host Git repositories and provide collaboration features.

You can use Git locally without having a GitHub account.

This distinction is fundamental.

29. What Does Git Actually Do?

Suppose you have:

app.js

You make a change.

Then another change.

Then another.

Without version control, you may eventually wonder:

"What did I change?"

Git creates a history of changes.

Conceptually:

VERSION 1

↓

VERSION 2

↓

VERSION 3

↓

VERSION 4

You can inspect what changed and create commits that represent meaningful points in the project's history.

30. Source Control in VS Code

The Source Control view lets you work with Git without leaving the editor.

You can see:

changed files;
differences;
staged changes;
commits;
branches;
merge conflicts.

VS Code's Git integration supports reviewing changes, staging, committing, branches, worktrees, and merge-conflict resolution.

This is important because software development is not only about writing new code.

It is also about managing change safely.

31. Learn to Read a Diff

A diff shows how a file changed.

Suppose you originally had:

const price = 100;

and changed it to:

const price = 120;

The diff helps you see the difference.

This is useful for:

reviewing your own work;
checking AI-generated changes;
finding accidental edits;
reviewing someone else's contribution;
preparing commits.

A developer should develop the habit:

Before saving important changes into history, inspect what actually changed.

32. Never Treat AI-Generated Code as Automatically Correct

This becomes especially important in modern development.

An AI assistant may generate:

code;
configuration;
commands;
files;
refactoring suggestions.

But generated code still has to be:

READ

→ UNDERSTOOD

→ TESTED

→ REVIEWED

→ ACCEPTED OR REJECTED

VS Code's development environment can help you inspect changes, but it does not remove your responsibility for understanding the software you build.

The same principle applies whether the code was written:

by you;
by another developer;
by an AI;
or generated from a template.

33. Problems View Helps You Find Errors

Modern development tools can detect certain problems while you work.

These can include:

syntax errors;
type errors;
linting problems;
configuration problems;
build errors.

VS Code can surface these through its Problems interface and language tooling.

The important mental model is:

An error message is evidence about the state of the system.

Do not simply copy the error into a search engine without reading it.

Ask:

What file is affected?
What line is affected?
What does the message actually say?
What was I trying to do?
What changed immediately before the error?
Is the error from the editor, compiler, runtime, extension, or application?

This is the beginning of professional debugging.

34. The Editor Can Run and Debug Your Software

VS Code supports running and debugging applications.

The Run and Debug view provides tools for:

starting programs;
setting breakpoints;
inspecting variables;
examining call stacks;
stepping through execution.

VS Code describes its Run and Debug view as providing variables, call stacks, and breakpoints.

The important distinction is:

Running

means:

"Execute the program."

Debugging

means:

"Help me understand what the program is doing while it executes."

That is a major conceptual step in software development.

35. A Breakpoint Is a Question

Suppose your program produces the wrong result.

Instead of adding random console.log() statements everywhere, you can sometimes pause execution at a strategic point.

That pause is a breakpoint.

You can then inspect:

variables;
program state;
call stack;
execution flow.

Think of a breakpoint as asking:

"Stop here so I can see what the program knows at this exact moment."

That mental model makes debugging much easier to understand.

36. The Browser Is Still Part of Web Development

VS Code does not replace the browser.

For web development, you often have at least three important environments:

VS CODE

→ write and inspect the project

TERMINAL / DEVELOPMENT TOOLS

→ run build tools and servers

BROWSER

→ execute and display the web application

Your workflow therefore becomes:

WRITE

↓

RUN

↓

OPEN IN BROWSER

↓

OBSERVE

↓

DEBUG

↓

EDIT

↓

REPEAT

This loop is the heart of practical web development.

37. Build Your First Clean VS Code Project

Let's create a simple project.

Create a folder:

my-first-website

Inside it, create:

my-first-website/
├── index.html
├── style.css
└── script.js

Your structure now has three basic responsibilities.

`index.html`

Structure.

`style.css`

Presentation.

`script.js`

Behavior.

This gives you a small but real software system.

38. Open the Project in VS Code

Open VS Code.

Choose the option to open a folder.

Select:

my-first-website

The Explorer should now show:

my-first-website

with your three files.

Do not immediately install ten extensions.

First understand the project.

39. Create a Simple HTML Page

Put this in index.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My First Website</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <h1>Hello, Internet</h1>
    <p>I am learning how a website is built.</p>

    <button id="helloButton">Click Me</button>

    <script src="script.js"></script>
</body>
</html>

Notice what happened.

HTML defines the structure.

The CSS file will control appearance.

The JavaScript file will control behavior.

40. Add Some CSS

Put this in style.css:

body {
    font-family: sans-serif;
    max-width: 700px;
    margin: 60px auto;
    padding: 20px;
}

button {
    padding: 10px 16px;
    cursor: pointer;
}

Now your website has presentation rules.

41. Add Some JavaScript

Put this in script.js:

const button = document.getElementById("helloButton");

button.addEventListener("click", () => {
    alert("Your JavaScript is working.");
});

Now you have behavior.

Your architecture is:

HTML

→ structure

CSS

→ presentation

JavaScript

→ behavior

This is one of the most important foundational models in web development.

42. Use the Browser to Test It

Open index.html in a browser.

You should see:

Hello, Internet

and a button.

Click the button.

The browser should display the alert.

Now you have completed the fundamental development loop:

WRITE

→ OPEN

→ TEST

→ OBSERVE

That is far more important than memorizing VS Code buttons.

43. Now Make a Deliberate Error

Change:

document.getElementById("helloButton");

to:

document.getElementById("missingButton");

Now your JavaScript is looking for an element that does not exist.

Click the button.

It will not work as expected.

This is useful.

You have created a controlled failure.

Now ask:

What changed?

You know the answer because you deliberately changed it.

This is how debugging should be learned.

44. Use Developer Tools and VS Code Together

When developing websites, the browser's Developer Tools complement VS Code.

VS Code helps you inspect and change the project.

Browser Developer Tools help you inspect the running page.

Together:

VS CODE

→ source

BROWSER DEVTOOLS

→ runtime

This distinction is extremely important.

The source code is what you wrote.

The runtime is what the browser actually executed.

They are related—but not identical.

45. Learn to Search Before You Scroll

As projects become larger, manual navigation becomes inefficient.

Instead of:

open folder → open file → scroll → search manually

use:

Quick Open

to find files.

Use:

Project Search

to find text.

Use:

Command Palette

to find commands.

Use:

Symbol navigation

to find functions, classes, or other code structures where supported.

This creates a powerful rule:

Search is a development skill.

The larger your project becomes, the more important it becomes.

46. Use the Terminal to Understand Your Project

Open the integrated terminal.

Run a command appropriate for your operating system to inspect the current directory.

For example, on many Unix-like systems:

pwd

and:

ls

On Windows Command Prompt:

cd

and:

dir

You are learning an important connection:

Explorer

shows your project graphically.

Terminal

shows your project through commands.

Both are interfaces to the same underlying filesystem.

47. Do Not Fear the Terminal

The terminal can look intimidating because it does not provide the visual buttons beginners are accustomed to.

But the terminal has an advantage:

commands are precise.

Instead of:

"Click around until I find the right thing."

you can say:

git status

and ask Git for the state of the repository.

Or:

npm run dev

to run a project's development script.

Or:

python app.py

to run a Python program.

The terminal becomes powerful when you understand what the command actually does.

48. Build the Habit of Reading Before Executing

Never treat commands as magic spells.

If someone tells you:

curl ... | sh

or gives you a script to execute, understand what it does before running it.

Commands can:

create files;
delete files;
install software;
change configuration;
modify environments;
transmit information;
execute code.

The terminal is powerful precisely because it gives you direct control.

That power requires judgment.

49. Keep Your Project Folder Clean

As you build projects, unnecessary files accumulate.

You may encounter:

temporary files;
generated output;
dependency folders;
logs;
cache files;
local configuration;
secrets.

Not every file should necessarily be committed to source control or uploaded to a server.

A professional development environment therefore distinguishes between:

SOURCE

what you intentionally create;

DEPENDENCIES

what your tools install;

GENERATED FILES

what your tools produce;

SECRETS

what must remain protected;

CONFIGURATION

what defines how the system behaves.

This distinction becomes increasingly important as your projects become serious.

50. Never Put Secrets Into Your Source Code Carelessly

Suppose your application needs an API key.

Do not automatically write:

const apiKey = "MY_SECRET_KEY";

and commit it to a public repository.

Secrets require deliberate handling.

Depending on the technology stack, you may use environment variables, secret-management systems, deployment configuration, or other secure mechanisms.

The exact solution depends on the project.

The principle is universal:

Credentials are not ordinary source code.

51. Your VS Code Environment Is Becoming a System

At this point, notice how many components you are working with:

PROJECT

↓

VS CODE

↓

EDITOR

↓

FILES

↓

TERMINAL

↓

LANGUAGE TOOLS

↓

EXTENSIONS

↓

GIT

↓

BROWSER / RUNTIME

↓

DEBUGGING

These pieces work together.

You are no longer merely learning an editor.

You are learning a development environment.

52. Create a Minimal Professional Setup

For a beginner web developer, a sensible starting environment can be surprisingly small.

Core

VS Code
a project folder
a browser
terminal access
Git

Then add what the project requires

language support;
formatter;
linter;
framework tooling;
debugging tools;
database tools;
cloud tools;
AI tools.

The exact list should emerge from your work.

Do not build your environment around a list of fashionable extensions.

Build it around your projects.

53. Create a Repeatable Project Opening Routine

Every time you begin work, follow roughly the same sequence.

Step 1

Open the project folder.

Step 2

Inspect the Explorer.

Step 3

Check Git status if the project uses Git.

Step 4

Read relevant project documentation.

Step 5

Open the terminal.

Step 6

Start the required development tools.

Step 7

Run the application.

Step 8

Test the current state.

Step 9

Only then begin making changes.

This prevents a common mistake:

changing code before understanding the current state of the system.

54. Create a Repeatable Change Routine

When making a change:

1. State the problem

What exactly are you trying to change?

2. Find the relevant code

Search rather than guessing.

3. Understand the surrounding code

Do not modify a line without understanding its context.

4. Make the smallest sensible change

Avoid changing unrelated things.

5. Run the application

See what happened.

6. Test the affected behavior

Do not assume success.

7. Inspect the diff

Check what changed.

8. Commit meaningful changes

If using Git, preserve useful history.

This is a professional habit worth developing early.

55. A Better Way to Think About Extensions

Use this decision framework.

Before installing an extension, ask:

Problem

What problem am I experiencing?

Capability

What capability would solve it?

Extension

Does an extension provide that capability?

Trust

Is the extension trustworthy and appropriate?

Cost

What does it add in terms of complexity, resources, permissions, or maintenance?

Alternatives

Can VS Code already do this without an extension?

This keeps your environment under control.

56. A Better Way to Think About Settings

Use the same discipline.

Before changing a setting:

What behavior do I want?

↓

Which setting controls it?

↓

Should it apply everywhere?

↓

Or only to this project?

↓

Will changing it create side effects?

This leads naturally to the distinction between:

USER SETTINGS

and

WORKSPACE SETTINGS.

57. A Better Way to Think About Projects

Do not think:

"My project is a bunch of files."

Think:

"My project is a system whose files, dependencies, configuration, tools, data and runtime behavior work together."

For example:

Website
│
├── HTML
├── CSS
├── JavaScript
├── Images
├── Configuration
├── Dependencies
├── Tests
└── Deployment

Each part has a role.

VS Code gives you a place to inspect and manipulate that system.

58. Your First VS Code Workspace Exercise

Now create a small development workspace.

Use:

w3notes-vscode-lab/

Create:

w3notes-vscode-lab/
├── index.html
├── style.css
├── script.js
└── README.md

Then:

Exercise 1

Open the folder in VS Code.

Exercise 2

Open all four files.

Exercise 3

Use Quick Open to find script.js.

Exercise 4

Use project search to find:

Hello

Exercise 5

Open the Command Palette.

Search for:

Format Document

Exercise 6

Open the integrated terminal.

Exercise 7

Check which shell is running.

Exercise 8

Open Settings.

Exercise 9

Find the @modified filter and inspect which settings you have changed. VS Code provides this filter specifically for identifying settings that differ from their defaults.

Exercise 10

Open Source Control if Git is installed.

You have now touched the major components of the development environment.

59. Your First VS Code Mental Map

Write this down:

VS CODE
│
├── EXPLORER
│   └── Understand project files
│
├── SEARCH
│   └── Find information across the project
│
├── EDITOR
│   └── Change source files
│
├── COMMAND PALETTE
│   └── Run VS Code commands
│
├── TERMINAL
│   └── Run development tools
│
├── EXTENSIONS
│   └── Add capabilities
│
├── SETTINGS
│   └── Configure behavior
│
├── PROFILES
│   └── Separate development environments
│
├── SOURCE CONTROL
│   └── Manage changes with Git
│
└── RUN & DEBUG
    └── Execute and investigate software

This map is more valuable than memorizing dozens of keyboard shortcuts.

60. The Professional Development Loop

You can now understand a much larger development cycle:

IDEA

↓

PROJECT

↓

FILES

↓

EDIT

↓

RUN

↓

TEST

↓

OBSERVE

↓

DEBUG

↓

CHANGE

↓

RETEST

↓

REVIEW

↓

COMMIT

↓

DEPLOY

↓

MONITOR

↓

IMPROVE

VS Code participates in almost every stage except the parts handled by external systems.

That is why it becomes such a powerful centre for software development.

61. Where AI Fits Into This Environment

Modern development environments increasingly include AI-assisted capabilities.

That can be useful for:

explaining code;
generating drafts;
suggesting changes;
finding possible bugs;
creating tests;
refactoring;
documenting code;
exploring unfamiliar projects.

But AI should fit inside the development process rather than replace it.

A safe mental model is:

PROBLEM

↓

UNDERSTAND

↓

ASK AI IF USEFUL

↓

INSPECT OUTPUT

↓

VERIFY

↓

TEST

↓

REVIEW

↓

ACCEPT OR REJECT

AI can accelerate development.

It does not remove the need for development knowledge.

62. What You Have Learned

You can now see VS Code as more than a text editor.

You understand that:

the workbench is the overall environment;
the Activity Bar provides access to major views;
Explorer shows the project structure;
the editor is where you modify files;
Search helps you understand large projects;
the Command Palette provides command-driven control;
Settings configure the environment;
workspace settings allow project-specific configuration;
extensions add capabilities;
profiles separate different working environments;
the integrated terminal connects your editor to command-line tools;
Git manages the history of your changes;
Run and Debug helps you understand program behavior;
the browser remains essential for web development;
and your project—not VS Code itself—is the thing you are ultimately building.

63. The Most Important Lesson

Do not try to become good at VS Code by memorizing every feature.

Become good at VS Code by learning to answer five questions:

1. Where is the thing I need?

Use Explorer, Quick Open, Search, and navigation.

2. How do I change it?

Use the editor.

3. How do I run it?

Use the terminal or configured run tools.

4. How do I know whether it works?

Test it.

5. What changed?

Inspect the diff and source-control history.

That is the foundation of productive development.

64. From Editor User to Developer

There is a major difference between these two statements:

"I know how to use VS Code."

and:

"I can use VS Code to understand, build, test, debug and manage software."

The first is tool familiarity.

The second is development capability.

Your goal is the second.

VS Code is simply the environment through which you practice that capability.

Your Place in the Web Development Stack

You can now place VS Code inside the larger web-development system:

PROBLEM
   ↓
PRODUCT / WEBSITE IDEA
   ↓
PROJECT STRUCTURE
   ↓
VS CODE
   ↓
HTML + CSS + JAVASCRIPT
   ↓
BROWSER
   ↓
HTTP / HTTPS
   ↓
WEB SERVER
   ↓
DATABASE / APIs
   ↓
CLOUD / INFRASTRUCTURE
   ↓
USERS

And above the entire stack sits something even more important:

THE ABILITY TO UNDERSTAND THE SYSTEM YOU ARE BUILDING.

That is what turns an editor into a professional development environment.

READ. USE. SOLVE.

READ the project before changing it.

USE the editor, terminal, search, extensions, Git, and debugging tools deliberately.

SOLVE problems by understanding the system rather than randomly changing things.

The objective is not to become someone who knows every VS Code feature.

The objective is to become someone who can sit down at a computer, open a project, understand what is there, make a change, test it, debug it, and move the project forward.

That is the real skill.

Image: Visual Studio Code

Pages

Thursday, October 1, 2026

VS CODE | Master the Editor, Terminal, Extensions, Settings, and Projects

1. First Understand What VS Code Actually Is

2. The Core Mental Model

3. Understand the VS Code Workbench

4. The Activity Bar Is Your Navigation System

5. Explorer Is Your Project Map

6. Open the Folder, Not Just Individual Files

7. What Is a Workspace?

8. User Settings vs Workspace Settings

9. Settings Are Configuration, Not Magic

Visual configuration

Text-based configuration

10. Do Not Change Settings Just Because You Can

11. Learn the Command Palette Early

12. Think of the Command Palette as VS Code's Command Interface

13. Quick Open Is Different

14. Search the Whole Project

15. Learn the Difference Between a File and a Tab

16. Split the Editor When You Need to Compare Things

17. The Integrated Terminal Changes the Workflow

18. What Can You Do in the Terminal?

19. Understand Terminal Profiles

20. The Terminal and Editor Work Together

21. Extensions Add Capabilities

22. But Extensions Are Not Automatically Good

23. Start With the Language Support You Actually Need

24. Extensions Can Have Their Own Settings

25. Use Profiles to Separate Different Development Environments

26. Why Profiles Matter

Web Development Profile

Python Profile

27. Your Workspace Can Be Part of the Configuration

28. Git Is Part of the Development Environment

29. What Does Git Actually Do?

30. Source Control in VS Code

31. Learn to Read a Diff

32. Never Treat AI-Generated Code as Automatically Correct

33. Problems View Helps You Find Errors

34. The Editor Can Run and Debug Your Software

35. A Breakpoint Is a Question

36. The Browser Is Still Part of Web Development

37. Build Your First Clean VS Code Project

index.html

style.css

script.js

38. Open the Project in VS Code

39. Create a Simple HTML Page

40. Add Some CSS

41. Add Some JavaScript

42. Use the Browser to Test It

43. Now Make a Deliberate Error

44. Use Developer Tools and VS Code Together

45. Learn to Search Before You Scroll

46. Use the Terminal to Understand Your Project

47. Do Not Fear the Terminal

48. Build the Habit of Reading Before Executing

49. Keep Your Project Folder Clean

50. Never Put Secrets Into Your Source Code Carelessly

51. Your VS Code Environment Is Becoming a System

52. Create a Minimal Professional Setup

Core

Then add what the project requires

53. Create a Repeatable Project Opening Routine

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

54. Create a Repeatable Change Routine

1. State the problem

2. Find the relevant code

3. Understand the surrounding code

4. Make the smallest sensible change

5. Run the application

`index.html`

`style.css`

`script.js`