How code becomes a running program

30 minBeginner

How code becomes a running program

Every tool a developer uses does one job in a single chain: you write text files, a program runs them, Git records them, GitHub shares them, and GitHub Actions checks them. This lesson draws that chain once, installs the tools on Windows or macOS, and ends with your first script printing a store's sales total.

By the end you can

Explain what a runtime is, and why the same JavaScript file behaves differently in a browser and in Node.js
Say what "install", "build" and "run" each mean in a real project
Place VS Code, the terminal, Git, GitHub and Actions on one map, and know which Kolom course covers each
Install VS Code, Git and Node.js LTS on Windows or macOS, and prove they work with four commands
Write, run, break and fix a small Node script, and run it again through an npm script

New here? How Kolom lessons work

Welcome. This is the first lesson of Your Developer Setup, and for many people the first lesson on Kolom. You need no programming experience, only a laptop with Windows or macOS (Linux works too) and about half an hour. By the end of this four-lesson course you will have a working setup and the habits professional teams use every day.

Every lesson follows the same pattern. It opens with an everyday picture, then teaches a few ideas. After most ideas comes a quick check: choose an answer before you open the explanation, because trying to remember is what makes ideas stick. Diagrams show how things move. An "At Mangrove Market" box puts the idea to work at Mangrove Market, a fictional grocery chain with about 320 stores, a delivery app and a small software team you have just joined. Then come Build it, which you do on your own computer, questions to bring to your team, Practice tasks (some are checked right here in your browser), a three-question quiz, flashcards for later review and the key takeaways. Each lesson also has a podcast episode with Nadia, a senior engineer, and Imran, a product manager, for when you are away from the screen. A final exam and a small project at the end of the course prove what you learned.

The everyday picture

Think of a busy restaurant kitchen. The recipe is written on paper. It does nothing by itself. A cook reads it line by line and does the work: cut, fry, plate. The cook works inside a kitchen that supplies gas, water, knives and a fridge. The cook never builds a stove; he asks the kitchen for one.

Before opening, the owner sends the menu to a printer. The printer turns rough notes into a clean card that customers can read quickly. Nobody cooks from the menu card, but nobody orders without it.

Software has the same four roles. Your source code is the recipe. The runtime (Node.js, or the browser) is the cook. The operating system (Windows, macOS, Android on a store's handheld scanner) is the kitchen. A compiler or bundler is the printer: it turns code into a form that is faster or easier to run. Keep these four in mind and most confusing error messages start to make sense, because each one comes from one of the four.

A project is a folder of files

Open any repository your team owns, say partner-api (the service behind Mangrove's Partner app), and you find a folder. Inside are more folders and files. That is the whole truth of the project. The code, the settings, the list of libraries it needs, the test cases and the build instructions are all files. If something is not in a file, the computer does not know it.

Most of these are text files: .js, .ts, .json, .md, .yml. You can open them in any editor, and Git can show exactly which line changed. The rest are binary files: images, fonts, an Android .apk. Git stores them too, but it cannot show a useful line-by-line difference.

An editor changes text files. An IDE is an editor with running, debugging and testing built in. VS Code starts as a fast editor and becomes IDE-like through extensions. That is why two developers' VS Code windows can look very different. VS Code essentials and VS Code for teams, the last two lessons of this course, show how a team makes them look the same where it matters.

Quick check

For which file can Git show you exactly which line changed?

package.json is a text file, so Git can compare it line by line. An .apk and a .png are binary files. Git still stores every version of them, but a diff can only tell you that they changed, not what changed.

Engines, runtimes and compilers

Your CPU only understands machine code, numbers that mean "add these", "jump there". JavaScript is text. Something must stand between them. That something is a JavaScript engine. V8 is the engine inside Chrome and Node.js. Safari uses JavaScriptCore. React Native apps, such as Mangrove's Store app in the store-app repo, use Hermes by default.

An engine alone can only do maths and logic. It cannot read a file, open a network connection or draw a button. A runtime adds those abilities. The browser adds the page (the DOM), fetch, clicks and timers. Node.js adds files, network servers, the process and its environment variables. Same engine, different kitchen. So document exists in a browser and is undefined in Node, and require('fs') works in Node and fails in a browser.

How the engine turns text into machine code varies. An interpreter runs code statement by statement. A compiler translates code ahead of time. Modern engines do both. V8 turns your file into bytecode and runs it, then compiles the functions that run often into machine code while the program is running. This is called JIT compilation. Hermes moves part of the work earlier: it compiles JavaScript to bytecode during the app build, so the app starts faster on a cheap phone or scanner.

Quick check

Your script reads a CSV file from disk. Which part makes reading the file possible?

The same file, two kitchens. Both runtimes contain a JavaScript engine (V8 in Chrome and Node, JavaScriptCore in Safari). What differs is what the code can ask for: the browser offers the page and fetch, Node offers files, the network and environment variables.

Install, build, run

Engineers use these three words all day. Each one is a concrete step.

Install means downloading the libraries the project depends on. A Node project lists them in package.json. When you type npm install, npm reads that list, downloads each dependency from the npm registry, and puts them in a folder called node_modules. That folder can hold hundreds of megabytes, and you can delete it at any time, because npm install recreates it from the list. This is why it never goes into Git (Everyday Git shows how to keep it out).

Build means turning source files into the files you actually ship. For partner-api that may be TypeScript compiled to plain JavaScript (TypeScript for a JavaScript team). For mangrove-dashboard, the back-office web app, it is a bundler joining hundreds of files into a few small ones. For store-app it is a JavaScript bundle compiled to Hermes bytecode and packed into an Android app. Some projects, like a small Node script, need no build at all.

Run means starting a runtime and pointing it at an entry point: node hello.js, or npm start, which runs whatever command the project stored under the name start. A running program is called a process. When it ends, it returns an exit code: 0 for success, anything else for failure. The next lesson, The terminal without fear, uses that number a lot.

Quick check

A teammate types npm start and the API begins answering requests. Which of the three steps is that?

Starting a process from an entry point is run. npm start looks up the command stored under start in package.json and starts it. Install would have downloaded libraries, and build would have produced files to ship, without starting anything.

Think first: you delete node_modules by accident. What did you lose?

Nothing that matters. package.json lists the libraries and the lockfile (package-lock.json) records their exact versions. Running npm install downloads the same files again. Work you lose is work that lives only in a file nobody committed, or only on one laptop. That is the problem Git solves.

Where each tool fits

People mix up these names, so here is the whole Developer track on one map. VS Code is where you edit files. The terminal is where you type commands, such as running Node or Git. Git is a program on your laptop that takes snapshots of the project folder, so you can see every change and go back to any point. It works with no internet at all. GitHub is a website that keeps a shared copy of the repository, where teammates review each other's changes. GitHub Actions is a GitHub service that runs your tests on a fresh machine every time someone pushes.

Git and GitHub are often confused. Git is the tool, like a shop's ledger book. GitHub is one place to keep a shared copy of the ledger, like head office. GitLab and Bitbucket do the same job as GitHub, and Git is identical with all three.

Quick check

You are on a long flight with no internet. Which of these can you still do?

The Developer track on one map. You edit and save in VS Code, Node runs the files, and Git commits snapshots on your laptop. git push sends them to GitHub, where the team reviews a pull request (PR). Actions tests every push and reports pass or fail on the PR. A passing build can be deployed to the stores.

Tool	What it is	Where it runs	Where to learn it
VS Code	Editor that extensions turn into a full workbench	Your laptop	VS Code essentials, VS Code for teams
Terminal and shell	A text window (terminal) running a program that reads your commands (shell)	Your laptop, also inside VS Code	The terminal without fear
Git	Version control: snapshots, branches, undo	Your laptop, offline	The Git from the Inside course, from What Git really is
GitHub	Hosting for shared repositories, pull requests, issues	The cloud (github.com)	The GitHub for Teams course, from Remotes, clone, push and pull
GitHub Actions	Runs your checks and deployments automatically	Fresh cloud machines	Continuous integration, Deploying and securing
Node.js and npm	JavaScript runtime, and its package manager	Your laptop and servers	JavaScript Deep Dive, from JavaScript in one sitting, then Node.js and npm

Build it

Install the four tools, prove they work, then write, break, fix and run your first script. This course uses Node.js 24, the current LTS (long-term support) line; Node 22 also works for everything here. If you want to practise reading and fixing an error before you install anything, the first Practice task below runs in your browser.

Install VS Code

Download it from code.visualstudio.com. On Windows, use the User installer (no admin rights needed) and keep Add to PATH ticked, which it is by default. On macOS, drag Visual Studio Code.app into Applications, open it, press Cmd+Shift+P and run Shell Command: Install 'code' command in PATH. On both, close and reopen any terminal afterwards so it sees the new PATH.
Install Git

On Windows, install Git for Windows from git-scm.com. It also installs Git Bash, a bash shell for Windows. Keep the defaults, except on two screens: choose Use Visual Studio Code as Git's default editor, and on the initial branch screen choose Override the default branch name and type main. On macOS, typing git --version offers to install Apple's Command Line Tools, which include Git. Homebrew gives you a newer Git.
PowerShell
```
# Optional: install from the terminal instead of clicking installers
winget install --id Microsoft.VisualStudioCode -e
winget install --id Git.Git -e --source winget
```
Terminal
```
# Optional: Homebrew (from brew.sh) installs and updates both
brew install --cask visual-studio-code
brew install git
```

Install Node.js LTS

The simplest way is the LTS installer from nodejs.org. It installs node, npm and npx together. Many teams use a version manager instead, because different repos need different Node versions. Here is fnm, one of the common ones. Node.js and npm, in the JavaScript in the Real World course, covers .nvmrc and pinning versions per repo.

PowerShell

winget install --id OpenJS.NodeJS.LTS -e      # option A: plain installer

winget install Schniz.fnm                     # option B: version manager
# then add the fnm line to your PowerShell profile, creating the file if needed
if (-not (Test-Path $PROFILE)) { New-Item $PROFILE -Force }
Add-Content $PROFILE 'fnm env --use-on-cd --shell powershell | Out-String | Invoke-Expression'
# open a new PowerShell window, then:
fnm install 24

Terminal

brew install fnm
# add the next line to ~/.zshrc so every new terminal can find fnm's Node
echo 'eval "$(fnm env --use-on-cd --shell zsh)"' >> ~/.zshrc
source ~/.zshrc
fnm install 24      # the first version you install becomes the default

Prove all four work

Open a new terminal: PowerShell or Git Bash on Windows, Terminal on macOS. These commands are the same in every shell. Your numbers will be the same or newer.
Terminal
```
code --version
git --version
node -v
npm -v
```
Output
```
1.140.0
07f806f999227108933c2e30515b26eecc1fda74
arm64
git version 2.55.0
v24.21.0
11.19.0
```
code --version prints three lines: the VS Code version, the exact source commit it was built from, and your CPU type (x64 on most Windows laptops, arm64 on Apple Silicon Macs). On Windows, Git's version ends in something like .windows.1. If a command prints "not recognized" or "command not found", the install did not reach your PATH. Close every terminal, open a new one and try again. The next lesson explains why this works.

Write hello.js

Create a folder called hello-sales, then open it in VS Code with File: Open Folder... from the Command Palette (Ctrl+Shift+P on Windows, Cmd+Shift+P on macOS). Add a file named hello.js with this code. Prices are stored in cents, as whole numbers, because computers store decimals like 0.1 inexactly: in Node, 0.1 + 0.2 prints 0.30000000000000004. Working with data: arrays, Maps, JSON, dates and money explains why.

JavaScript

// hello.js: add up today's sales for one store.
// Prices are whole cents (100 cents = 1 dollar), so the maths stays exact.
const sales = [
  { articleCode: 'A-1001', name: 'Basmati rice 5 kg', qty: 2, unitPriceCents: 850 },
  { articleCode: 'A-2040', name: 'Sunflower oil 1 L', qty: 3, unitPriceCents: 379 },
  { articleCode: 'A-0007', name: 'Eggs, 12 pcs', qty: 1, unitPriceCents: 300 },
];

let totalCents = 0;
for (const line of sales) {
  totalCents += line.qty * line.unitPriceCents; // quantity times unit price
}

console.log(`Store S-014, ${new Date().toDateString()}`);
console.log(`Lines sold: ${sales.length}`);
console.log(`Total: $${(totalCents / 100).toFixed(2)}`);

An articleCode is a product code: Mangrove's systems call each product an article. S-014 is one of its stores.

Run it in VS Code's terminal

Open the integrated terminal with Ctrl+` (the backtick key, left of 1; the same keys on macOS). It opens in your project folder. Run the file with Node:
Terminal
```
node hello.js
```
Output
```
Store S-014, Wed Oct 07 2026
Lines sold: 3
Total: $31.37
```

Break it on purpose, and read the error

Change sales to sale in the for line, save, and run it again. Read errors from the top. The first line gives the file, the line number (10) and the code, with a caret under the problem. The error name and message say what went wrong. The lines starting with at are the stack trace; the top one points to your file at line 10, column 20, and the rest are Node's own code. Fix the typo and run it again.

Output

/Users/you/work/hello-sales/hello.js:10
for (const line of sale) {
                   ^

ReferenceError: sale is not defined
    at Object.<anonymous> (/Users/you/work/hello-sales/hello.js:10:20)
    at Module._compile (node:internal/modules/cjs/loader:1929:14)
    at Object..js (node:internal/modules/cjs/loader:2060:10)
    at Module.load (node:internal/modules/cjs/loader:1651:32)
    at Module._load (node:internal/modules/cjs/loader:1443:12)
    at wrapModuleLoad (node:internal/modules/cjs/loader:261:19)
    at Module.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:154:5)
    at node:internal/main/run_main_module:33:47

Node.js v24.21.0

Make it a project with an npm script

npm init -y writes a package.json with default values. npm pkg set adds a script named start. Now anyone who clones the folder can run it with npm start, without knowing the file name. Real projects use the same idea for npm test, npm run build and npm run lint.

Terminal

npm init -y
npm pkg set scripts.start="node hello.js"
npm start

Output

Wrote to /Users/you/work/hello-sales/package.json:

{
  "name": "hello-sales",
  "version": "1.0.0",
  "description": "",
  "main": "hello.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "type": "commonjs"
}

> hello-sales@1.0.0 start
> node hello.js

Store S-014, Wed Oct 07 2026
Lines sold: 3
Total: $31.37

The two lines starting with > are npm telling you which script it runs. That is how you find out what npm start really does in a repo you have never seen.

Bring it to your team

These questions show whether a project can be built by anyone, or only by the person who wrote it.

"If I clone this repo on a new laptop today, which commands do I run to see it working, and are they in the README?"
"Which Node.js version does this repo need, and where is that written down?"
"What exactly happens between merge and the app on users' phones or our stores' scanners: which build step, which machine, and how long does each take?"
"Which npm scripts do we use every day, and what does each one really run?"
"Is this change in code, in configuration, or in data? Who can change each one without a release?"

Red flags

Only one person's laptop can build a release.
node_modules or build output committed to the repository.
Nobody knows which Node version production runs.
"It works on my machine" said twice in the same week about the same project.

Practice

Read the error, then fix the till total

This function should return the total of a list of sale lines, in cents. Each line looks like { qty: 2, unitPriceCents: 850 }. Press Run first and read the message: it is the same kind of error as in step 7 of Build it. Fix that, run again, and fix the second bug the tests reveal.

JavaScript exerciseRuns in your browser with tests

function saleTotalCents(lines) {
  let total = 0;
  for (const line of sale) {
    total += line.qty * line.unitPrice;
  }
  return total;
}

Ctrl + Enter runs

test('adds quantity times unit price for every line', () => {
  const lines = [
    { qty: 2, unitPriceCents: 850 },
    { qty: 3, unitPriceCents: 379 },
    { qty: 1, unitPriceCents: 300 },
  ];
  expect(saleTotalCents(lines)).toBe(3137);
});
test('a single line is quantity times unit price', () => {
  expect(saleTotalCents([{ qty: 4, unitPriceCents: 250 }])).toBe(1000);
});
test('an empty list of lines totals 0 cents', () => {
  expect(saleTotalCents([])).toBe(0);
});

Show a solution

JavaScript

function saleTotalCents(lines) {
  let total = 0;
  for (const line of lines) {               // the parameter is called lines, not sale
    total += line.qty * line.unitPriceCents; // the field is unitPriceCents
  }
  return total;
}

Pass the exercise to finish this task.

Write the "Getting started" part of a README

Using your hello-sales project from Build it, write a short README.md section that a new teammate could follow on a fresh laptop and see the script working. Imagine they have never seen the project and you are not there to help.

It names the tools needed and the Node.js version (for example "Node.js 24 LTS").
The commands appear in order, each one copyable, with no $ prompt in front.
It uses npm start, so the reader does not need to know the file name.
It shows what success looks like: the output the reader should expect.
It says what to do if a command is "not found" (open a new terminal).

Show a model answer

Markdown

## Getting started

You need Git, VS Code and Node.js 24 LTS (Node 22 also works).
Check them in a new terminal: `git --version`, `node -v`, `npm -v`.

1. Get the code and open the folder:
   `git clone <repo link> hello-sales`, then `cd hello-sales`
2. Run it:
   `npm start`

You should see three lines, ending with a total such as `Total: $31.37`.

If a command says "not found", close the terminal, open a new one and try again.

Seven short lines are enough. The point is that a stranger can go from nothing to a working script without asking anyone.

Check yourself

A script uses document.querySelector and works in Chrome, but in Node it fails with "document is not defined". Why?

Which sentence about Git and GitHub is correct?

A teammate says "I ran the build". In a NestJS project like partner-api, what most likely happened?

Flashcards

Add these 7 cards to my review when I finish the lessonOpen my review

Key takeaways

A project is a folder of files. Code, settings and the list of dependencies are all text files, and that is what Git tracks.
An engine (V8, Hermes) executes JavaScript. A runtime (browser, Node) adds what the code can ask for: the page, or files and the network.
Install downloads dependencies, build turns source into what you ship, run starts a process from an entry point.
VS Code edits, Git snapshots on your laptop, GitHub shares and reviews, Actions tests every push.
Four commands prove your setup: code --version, git --version, node -v, npm -v.

Sources

Node.js Learn, the OpenJS Foundation: guides to Node, npm and the runtime
Visual Studio Code documentation, Microsoft
Pro Git, Scott Chacon and Ben Straub, free online

Episode transcriptFrom a line of code to the store · about 14 minutes · tap any line to play from there

NadiaHello, and welcome to Kolom. I'm Nadia, a senior engineer at Mangrove Market, a grocery chain with about three hundred and twenty stores and a delivery app. This is the first episode of the course Your Developer Setup.
ImranAnd I'm Imran, a product manager at Mangrove, for the Store app and the Partner app. Mangrove is made up, but its problems are very real. This course is close to the keyboard: VS Code, the terminal, and the habits every developer team relies on.
NadiaEvery lesson has an episode like this one, about ten minutes, for the bus or the car. The lesson page has the diagrams, the commands, quick checks, practice tasks and a quiz for when you're at your desk. You don't need any experience to start.
ImranLet me start with a real one. Last month a developer told me the fix for the stock count screen was done. Two days later Ama, one of our store managers, called. Still broken.
NadiaSo who was wrong?
ImranNobody, it turned out. The fix was done on his laptop. It wasn't reviewed yet, and the store scanners still had the old app.
NadiaThat's the gap this lesson closes. Between one line of code and a scanner in a store there's a chain of steps. Once you can see the chain, done becomes a precise word.
NadiaThe lesson starts in a restaurant kitchen. A recipe on paper does nothing by itself. A cook reads it and does the work. And the cook works inside a kitchen that supplies gas, water and knives.
ImranYou also mentioned a menu card printer.
NadiaBefore opening, the owner sends rough notes to a printer, who makes a clean card customers can read fast.
ImranSo the recipe is the source code. And the cook is...
NadiaThe runtime. Node, or the browser. The kitchen is the operating system: Windows, macOS, or Android on a store scanner. The printer is a compiler or a bundler, which turns code into a form that's faster to run or easier to ship.
ImranWhy bother with four roles?
NadiaBecause most confusing errors come from one of the four. A typo is the recipe. A missing function is the cook. A file permission problem is the kitchen. A broken build is the printer. Knowing which one is talking saves a lot of time.
ImranStart with the recipe, then. What is a project, really?
NadiaA folder of files. Open a repo like partner API and you find the code, the settings, the list of libraries, the tests and the build instructions, all as files. If something isn't in a file, the computer doesn't know it.
ImranNow the cook. I've always heard engine and runtime used as if they mean the same thing.
NadiaThey don't, and the difference explains a classic error. The engine executes JavaScript. V8 is the engine in Chrome and in Node. Safari uses one called JavaScript Core. React Native apps use Hermes.
NadiaAn engine alone can only do maths and logic. It can't read a file or draw a button. The runtime adds those abilities around the engine.
ImranSo Chrome and Node share an engine, and they don't share a kitchen.
NadiaThat's the first diagram. If you can see your screen, one file at the top splits into two dashed boxes, the browser on the left and Node on the right. If not, picture one recipe going to two different kitchens.
NadiaIn the browser, the code can ask for the page, for fetch, for clicks and timers. In Node, it can ask for files, the network, and environment variables.
ImranSo if I run a browser script in Node, and it uses the document object...
NadiaNode says document is not defined. Same engine, so same language. Different kitchen, so different tools on the shelf.
ImranMy guess would have been that Node has an older engine.
NadiaA very common guess, Imran, and it's wrong. It's the same V8. The missing piece is the browser's page, and no upgrade adds it. That's the first quiz question, so you've already met the trap.
ImranWhat about compilers? I thought JavaScript isn't compiled at all.
NadiaModern engines do both. V8 turns your file into bytecode, a compact list of simple instructions, and runs that. Then the functions that run often get compiled to real machine code while the program is running. That's called just in time compilation.
NadiaHermes moves part of that work earlier. It compiles the app's JavaScript to bytecode during the build, so the app starts faster on a cheap phone.
ImranThat matters for us. Store scanners are not fast devices.
NadiaRight. Now three words engineers use all day: install, build and run.
ImranInstall is downloading things.
NadiaDownloading the libraries the project depends on. They're listed in a file called package dot json. N P M reads that list and puts everything in a folder called node modules.
NadiaThat folder can be hundreds of megabytes, and you can delete it any time. Running install again brings it back. That's why it never goes into Git.
ImranAnd build?
NadiaTurning source into what you ship. For a NestJS API, mostly compiling TypeScript into JavaScript. For a web dashboard, a bundler joins hundreds of files into a few. For the React Native app, the bundle is compiled to Hermes bytecode and packed into an Android app.
ImranAnd run is starting it.
NadiaStarting a runtime and pointing it at an entry point, the first file. A running program is called a process. When it ends, it returns an exit code. Zero means success. Anything else means failure. The next lesson uses that number a lot.
ImranSo when a developer says, I ran the build, the server is up?
NadiaNot yet. Starting the server is run. Build is the step before it, the one that makes what you will run or ship.
ImranNow the map you promised. Where does each tool sit?
NadiaThat's the second diagram. If you're looking, there are two dashed areas: your laptop on top, GitHub in the cloud below. If not, imagine two floors of one building.
NadiaUpstairs, on your laptop: VS Code, where you edit and save. Node, which runs the files. And Git, which takes snapshots of the folder. Git works with no internet at all.
NadiaDownstairs, in the cloud: GitHub, which keeps a shared copy where teammates review changes. And GitHub Actions, which runs your tests on a fresh machine every time someone pushes.
ImranPeople mix up Git and GitHub in my meetings all the time.
NadiaGit is the tool, like a ledger book. GitHub is one place to keep a shared copy of the ledger, like head office. GitLab and Bitbucket do the same job, and the Git commands are identical with all three.
ImranAnd the arrow between the floors is push.
NadiaPush sends your commits up to GitHub, and pull brings other people's changes down. A pull request asks the team to review. Actions reports pass or fail on that request, and a passing build can be deployed to the stores.
ImranBack to my stock count fix, then. Saved in VS Code, seconds. Committed, seconds. Reviewed on GitHub, hours. Tested by Actions, minutes. Built, minutes. On the scanners in every store, days.
NadiaThat's the lesson's Mangrove example almost exactly. So when someone says the fix is done, ask which step is done. The answer changes what you tell Ama.
ImranWhat goes wrong most often on the first day with these tools?
NadiaTwo Node installs on one laptop. An old installer from years ago, and a new one. The terminal finds one, VS Code finds the other, and code that works in one place fails in the other.
ImranHow do I avoid it?
NadiaBefore installing, run node, dash v. If a version comes back, find out where it came from. Remove it, or use one version manager for everything. The next lesson explains how the shell decides which program to run.
ImranSpeaking of installing. Walk me through the Build-it section.
NadiaIt starts with four tools, with Windows and macOS steps side by side. VS Code, Git, Node, and N P M, which comes with Node.
NadiaOn Windows, take the VS Code user installer and keep add to path ticked. On a Mac, drag it into Applications, then run one command from the Command Palette that installs the code command for the terminal.
ImranAnd Git?
NadiaOn Windows, Git for Windows, which also gives you Git Bash. Two screens in its installer matter: choose VS Code as Git's editor, and set the first branch name to main. On a Mac, Apple's command line tools include Git, or you use Homebrew.
ImranNode from the website?
NadiaThe LTS installer from the Node website is the simplest. LTS means long term support, and this course uses Node twenty-four. Many teams prefer a version manager like F N M, because different repos need different versions.
ImranThen I prove it all works.
NadiaFour commands in a new terminal: code, git, node and npm, each asked for its version. If one says command not found, open a fresh terminal. A terminal reads its list of program folders only when it opens.
ImranAnd then I finally write some code.
NadiaA small file called hello dot J S. It holds three sale lines for one store: rice, oil and eggs. It multiplies quantity by unit price, adds them up and prints the total. Thirty-one dollars and thirty-seven cents.
ImranWhy are the prices in cents inside the file?
NadiaBecause computers store decimals like zero point one inexactly. In Node, zero point one plus zero point two prints zero point three, then a long row of zeros, then a four. Whole cents keep the maths exact. A lesson in JavaScript Deep Dive explains why.
ImranThen you have me break it on purpose.
NadiaYou change sales to sale, run it again, and read the error from the top. The first line names the file and line ten, with a small caret under the problem. Then the error itself: reference error, sale is not defined.
ImranCan I practise that before I install anything?
NadiaYes. The first practice task on the page runs in your browser. A small function has the same kind of typo, plus one more bug. You press run, read the message, and fix them one at a time.
ImranAnd the last step of the Build-it?
NadiaMake it a project. N P M init writes a package dot json, and you add a script called start. Now anyone can type npm start without knowing the file name. N P M also prints the command it runs, which is how you find out what a script does in a repo you've never seen.
ImranWhat do I take to my team from this one?
NadiaAsk this: if I clone the repo on a new laptop today, which commands do I run to see it working, and are they in the README?
ImranI'd add: which Node version does this repo need, and where is that written down?
NadiaAnd one more. Between merge and the app on a store scanner, which build step runs, on which machine, and how long does each step take?
ImranAnd the red flags?
NadiaOnly one person's laptop can build a release. The node modules folder committed to the repo. Or "it works on my machine", twice in one week, about the same project.
NadiaHere's one to think about. You delete the node modules folder by accident. What did you lose? Take a second.
ImranMy first feeling is panic. All the libraries are gone.
NadiaYou lost nothing that matters. Package dot json lists the libraries, and the lockfile records their exact versions. N P M install downloads the same files again. What you can really lose is work that lives only in a file nobody committed. That's the job of Git.
ImranLet me sum up. One: a project is a folder of files, and if it isn't in a file, the computer doesn't know it.
ImranTwo: the engine runs JavaScript, and the runtime decides what the code can ask for. Same engine in Chrome and Node, different kitchen.
ImranThree: VS Code edits, Git takes snapshots on my laptop, GitHub shares and reviews, Actions tests every push. And whenever someone says done, I ask which step.
NadiaOne nuance on the third. Git needs no account and no network. You can commit for months offline. GitHub only enters the picture when you want to share. And the flashcards at the end of the lesson will bring all three back in a few days.
NadiaNext time, the terminal. We talk to the computer directly, find out why command not found happens, and count a day's sales in a file without opening it.
ImranSee you then.

Finished reading?Mark it complete to fill in its stop on your course line.

Use it at work

Utility script

A small script with its options at the top, input checks, a summary line and tests.

Open in the Code Lab

Next stopThe terminal without fear

Was this lesson helpful?

Questions and discussion

Loading the discussion…