The Developer Environment

SAP Implementation Consulting & ERP - Startupistan Germany · Block I · study notes for revision.

---

Before I write a single line of real code, my machine needs a workbench: a place to type commands, and four tools that do the actual work. This chapter is that setup, from zero. Nothing here assumes I’ve ever opened a terminal before.

Two ways to talk to a computer

There are exactly two ways to give a computer instructions:

• GUI - Graphical User Interface. Clicking icons, dragging windows, picking from menus. This is how nearly everyone uses a computer.
• CLI - Command-Line Interface. Typing a written instruction, pressing Enter, and reading a written answer. Older, and still everywhere in the developer world.

The terminal is the window where the CLI happens.

The terminal, in one picture

It’s a chat window with my computer. I type a short message (a command), press Enter to send it, and the computer replies in text. Nothing happens while I’m still typing - only Enter sends. The catch: this chat partner is extremely literal. It does exactly what I typed, not what I meant, which is why a small typo matters.

The vocabulary that gets used loosely

Four words float around, related but not identical. Worth pinning down once:

Word	What it actually means
Terminal	The window - the app I open (Windows Terminal, macOS Terminal, GNOME Terminal, Hyper)
Shell	The program inside that reads and runs my commands (PowerShell, Bash, Zsh)
Command line	The line I type on - and loosely, this whole way of working
Console	An older, catch-all synonym for any of the above

In everyday speech developers mix these freely. “Open a console,” “open a shell,” “open a terminal” all mean the same thing: get to the place where I can type commands.

Why developers bother typing

If clicking works, why type?

• The tools live there. Git, Node.js, and npm are command-line tools first. Their native home is the terminal, and every tutorial online assumes it.
• It’s precise and repeatable. A command is one exact thing - copyable, shareable, re-runnable identically. “Click the third icon, then the second tab” is none of those.
• It scales. Renaming one file is easier with a mouse. Renaming five hundred is one command.
• Servers have no desktop. The machines that run real software usually have no GUI at all. The command line is how professionals reach them.

One job, both ways

Make a folder called projects inside Documents. GUI: open the file explorer, go to Documents, right-click, New → Folder, type the name, Enter - six steps. CLI: mkdir projects - one line. Neither is wrong; now I see why folder-makers-all-day prefer the short version.

Opening a terminal

Same idea on every system: a mostly empty window with a short line of text waiting for me. How I open it differs.

Windows

The built-in app is called Terminal (also Windows Terminal), and it runs the PowerShell shell.

1. Press the Windows key (or click Start).
2. Type terminal.
3. Press Enter (or click Terminal).

A window opens with a line like PS C:\Users\ravi>. On older Windows 10 machines Terminal may be missing - search powershell instead and open Windows PowerShell; same place.

Ignore Command Prompt (cmd): it’s an older shell this program doesn’t use. If a window shows C:\Users\ravi> without the PS, close it and open Terminal/PowerShell.

macOS

This program sets up Hyper (hyper.is) as the terminal, running the Zsh shell.

1. Press Cmd + Space to open Spotlight.
2. Type hyper.
3. Press Enter.

Hyper’s prompt is themed (colored blocks and arrows instead of plain text), but the shell underneath is ordinary Zsh - every command works the same. The always-there fallback is the built-in Terminal app (Cmd + Space → terminal).

Linux

This program sets up Hyper (hyper.is) as the terminal, running Bash.

Search my applications for hyper and open it. Themed prompt, ordinary shell underneath.

The always-there fallback is my distribution’s own terminal - GNOME Terminal on Ubuntu, Konsole on KDE - usually one Ctrl + Alt + T away. A plain prompt looks like ravi@laptop:~$.

Reading the prompt

That waiting line is the prompt - the shell saying “ready, your turn.” It usually shows where I am (~ is shorthand for my home folder) and which shell I’m in, by its ending symbol: PowerShell ends with >, Zsh (macOS) ends with %, Bash (Linux) ends with $.

When a tutorial shows a command after a $ or >, that symbol is the prompt - I never type it, only what comes after.

Opening a terminal changes nothing by itself

A black window full of text is what ready looks like, not an error. I can open it, type, delete, close it again, and my computer is exactly as it was. Nothing runs until Enter. So there’s nothing to be scared of - open it as often as I like.

Essential commands - the reference table

Everything is the same loop: type, Enter, read the answer. Here’s the working vocabulary. Most of these aliases work in PowerShell too, but where Windows differs I’ve noted its native command.

Command	What it does	macOS / Linux	Windows PowerShell
pwd	Print working directory - “where am I?”	pwd	pwd
ls / dir	List what’s in this folder	ls	ls or dir
cd	Change directory - step into a folder	cd Documents	cd Documents
cd ..	Step up one folder (.. = the folder above)	cd ..	cd ..
mkdir	Make a new folder here	mkdir projects	mkdir projects
touch / New-Item	Create an empty file	touch notes.txt	New-Item notes.txt
cat	Show a file’s contents in the terminal	cat notes.txt	cat notes.txt
echo	Print text back (or into a file)	echo "hi"	echo "hi"
clear / cls	Wipe the screen clean (history stays)	clear	clear or cls
mv	Move or rename a file/folder	mv a.txt b.txt	mv a.txt b.txt
cp	Copy a file	cp a.txt copy.txt	cp a.txt copy.txt
rm	Delete a file (add -r for a folder)	rm old.txt	rm old.txt

Two things that trip up beginners

• touch doesn’t exist in PowerShell - use New-Item filename there. Everything else in the table has a working PowerShell alias.
• rm deletes for real - there’s no Recycle Bin stop. Double-check the name before pressing Enter, and never rm -r a folder unless I’m certain.

Here’s what the loop actually feels like - a short walk that uses the first five. The $ is the prompt, so I type only what follows it; lines without a $ are the computer answering:

$ pwd
/Users/ravi
$ ls
Desktop    Documents    Downloads
$ cd Documents
$ pwd
/Users/ravi/Documents
$ mkdir startupistan
$ ls
startupistan
$ cd ..
$ pwd
/Users/ravi

Read it like a story: check where I am, look around, step in, confirm, make a folder, step back out, confirm. That check-move-confirm rhythm is exactly how experienced developers move around too.

Three habits that prevent most frustration

• “Run a command” = type it, then press Enter. Nothing runs mid-typing.
• Spelling and case matter. On macOS/Linux, Documents and documents can be different folders. Type names exactly as ls shows them.
• Success is usually silent. cd and mkdir say nothing when they work - silence means success. I confirm with pwd and ls, not by re-running the command five times.

Absolute vs relative paths

Every location is a path. An absolute path starts from the very top (/Users/ravi/Documents, or C:\Users\ravi\Documents) and means the same thing wherever I stand. A relative path (Documents, .., notes/drafts) is measured from my current folder, so its meaning shifts as I move. cd takes both - and knowing the difference explains most “why didn’t that work?” moments before they happen.

Reading and fixing command-line errors

Sooner or later the terminal answers with a complaint instead of what I wanted. That’s good - the error is the shell being helpful, and it always stops before doing anything. An error never means I broke the computer. The three I’ll meet first:

Error message	What it really means	The fix
command not found / not recognized	The first word isn’t a command it knows - a typo, or the program isn’t installed	Check spelling first; if spelt right, it’s an install/PATH issue (see troubleshooting)
no such file or directory	It knows the command, but can’t see that folder/file from where I’m standing	pwd to see where I am, ls to see what’s here, then cd to what actually shows
too many arguments	A space in a name split it into two pieces	Wrap the name in quotes: cd "My Projects" - or avoid spaces entirely

Read the first line, slowly

The answer is almost always right there in plain words - “not found,” “does not exist,” “too many arguments.” Beginners who read the message calmly fix things faster than experts who don’t.

And name folders my-projects or my_projects - no spaces means no quoting and no surprises. I’ll do that with everything I create.

No error doesn't always mean I got what I wanted

mkdir client work doesn’t fail - it quietly makes two folders (client and work), because the space split it. So I confirm with ls even when there’s no error.

Three shortcuts that prevent errors before they happen

• Tab completion - type the first letters of a name, press Tab, and the shell finishes it with the exact spelling (quoting included). Developers press Tab constantly.
• Up arrow - brings back a previous command, so a long line with one typo is recalled and fixed, not retyped.
• Built-in help - mkdir --help on macOS/Linux, or Get-Help mkdir in PowerShell, explains any command.

The four core tools

My machine runs on four tools, one per job. Together they form a loop I’ll repeat thousands of times: write → run → check → save → repeat.

Tool	What it is	Its one job
VS Code	A code editor	Write and organize code
Git	A version-control system	Remember - record the history of my work so nothing is ever lost
Node.js	A JavaScript runtime (brings npm)	Run JavaScript outside the browser, and install building blocks
The browser (Chrome)	A browser + inspection lab	Show and inspect - where web code runs, previews, and gets debugged

WriteVS Code

→

Runbrowser · Node.js

→

Checkbrowser DevTools

→

SaveGit

→

…repeat

The everyday loop the four tools form together.

These aren't beginner tools I'll outgrow

This is the professional toolchain. The same four (or their direct equivalents) sit on the machines of developers with twenty years of experience. I’ll use a small slice of each and grow into the rest - nobody knows all of VS Code or all of Git, including the people who built them.

Git = version control

The problem Git solves is the folder full of website-final.html, website-final2.html, website-FINAL-REALLY.html. Which one did I send? What changed between two of them? What broke it today? A version-control system (VCS) answers all of that properly:

• Save points - at any moment I choose, it snapshots the whole project with a timestamp, my name, and a message.
• A readable history - the full list of those save points, so “what changed, when, why” is always answerable.
• Time travel - any earlier save point can be restored. Broke something today? Back to yesterday’s working state in seconds.
• Safe teamwork - several people work on the same project; the VCS merges their work and shows exactly where it collides.

Git is the standard VCS - so dominant that “version control” and “Git” are near-synonyms.

Git vs GitHub - the confusion to clear up once

Git is the tool on my machine; GitHub is an online service where Git projects live. Git works fully offline, recording history on my own computer. GitHub (a website owned by Microsoft) hosts a copy of that history online so I can back it up, share it, and collaborate. Related, used together constantly - not the same thing.

Node.js = run JavaScript outside the browser

JavaScript is the language of the web, and for years it could only run inside a browser. Node.js is a runtime - a program whose job is to run programs - that removed that cage. Install it, and JavaScript runs directly on my machine, no browser needed. That turned JavaScript into a language that also powers servers, command-line tools, and nearly all modern web-development tooling.

npm - the part that quietly matters most

Installing Node.js also installs npm (the Node package manager). Its job is to fetch and install packages - ready-made blocks of code other developers have published - from the world’s largest code registry. Modern web development is assembly as much as writing: real projects stand on dozens of packages, and npm is how they arrive and stay updated. When a tutorial says “npm install something,” now I know exactly which tool is doing what.

The browser = inspect and debug

To most people a browser just shows websites. To a developer it’s the machine their work runs on - HTML, CSS, and JavaScript run inside the browser of whoever opens the page. That makes it my test bench, plus a full inspection lab one right-click away.

1. Right-click anything on a page (a headline works well) and choose Inspect.

2. A panel opens - the DevTools (Developer Tools). The Elements tab shows the page’s actual HTML; hovering a line highlights the matching part of the page.

3. Double-click a headline’s text, type something else, press Enter - the page changes. Now refresh: it’s back.

Why that vanishing matters

DevTools edits my browser’s local copy of the page, never the real website. That’s exactly what makes it a safe laboratory - I can poke at any page on the internet, including my own, and a refresh undoes everything. It’s a sandbox, not a control panel.

Editor vs IDE

Someone will eventually ask which IDE I use. The honest answer needs a definition first, because the distinction returns when this program reaches SAP.

	Code editor	IDE (Integrated Development Environment)
Starts as	Light and general - edits any language out of the box	A complete workshop for one ecosystem, everything preinstalled
Grows via	Extensions I choose, per project	Already wired together: build system, debugger, templates, refactoring
Examples	VS Code, Sublime Text, Vim	IntelliJ (Java), PyCharm (Python), Visual Studio (.NET), Eclipse
Best when	One tool must cover many languages	Deep, single-ecosystem work

The one question that settles it

Built for everything, or built for one thing? Extensions I add myself = editor thinking. A complete preinstalled workshop for one ecosystem = IDE thinking.

The line is blurry - VS Code with the right extensions behaves like a lightweight IDE. The classical answer to keep: VS Code is an editor that extensions can push toward IDE territory. This block fits an editor (one light tool for HTML, CSS, JavaScript). The SAP / ABAP world later comes with its own deeply integrated IDE - and now I’ll know why it feels so different: I’m stepping out of the general toolbox into a specialist’s workshop.

The golden rule of setup

Before any install steps, the one habit that prevents half of all “it didn’t work” moments:

After every single install: close the terminal, open a fresh one

A terminal reads its setup - which programs exist and where they live - once, the moment it opens. A terminal that was already open before an install never saw the new program, and will insist it doesn’t exist. So after installing anything: close the terminal completely, open a new one, then verify.

Two more facts before installing anything:

• Know my machine. Every download page asks what I’m running. Windows: type about → About your PC (or run winver). macOS: Apple menu → About This Mac. Linux: cat /etc/os-release.
• Administrator rights. Installing changes the machine for every user, so the OS asks permission - the “allow this app to make changes?” pop-up on Windows, a password prompt on macOS/Linux (where the terminal word is sudo). On my own laptop I click Yes / type my password. On a company or family device, installs may be locked to someone else’s account - that’s policy, not an error; the fix is asking the owner or IT, not fighting the dialog.

Verify, then install

Everything was set up at program start, so the first move for each tool is verify - check it already works. Install steps are the reference for a new machine or a reinstall.

The terminal (macOS & Linux only)

Windows uses Windows Terminal - nothing to do. macOS/Linux run Hyper, and it’s verified first because everything else gets checked inside a terminal.

1. Open Hyper (Cmd + Space → hyper on macOS; app search on Linux).

2. Run a command to prove the shell behind the theme:

   $ pwd
   /Users/ravi

3. Opens and answers - verified. Install reference: download from hyper.is; on macOS drag it into Applications, on Linux install the .deb (sudo apt install ./hyper_*.deb). Built-in terminals (macOS Terminal, GNOME Terminal) are the permanent fallback.

Git

1. In a terminal, run the check:

   $ git --version
   git version 2.45.1

2. Any version number = done. My number will differ - that’s fine. Only command not found needs fixing: try a fresh terminal first, then install.

3. Install reference:

Windows

Download the installer from git-scm.com/downloads, run it, and accept the defaults on every screen - the wall of option pages intimidates everyone once, but none of them need changing here. It also installs Git Bash, a bonus terminal that speaks the macOS/Linux command language. Open a new terminal and run git --version.

macOS

Installed via Homebrew (brew.sh), the Mac’s popular package manager. One-time prep first:

$ touch ~/.zshrc

touch creates the file if it’s missing (harmless if it exists). ~/.zshrc is my Zsh config, read every time a terminal opens - it’s where Homebrew and nvm write their setup lines. On a fresh Mac it doesn’t exist yet, and without it those lines have nowhere to go, causing mysterious command not found errors later. Then:

$ brew --version     # confirm Homebrew is present
$ brew install git   # install Git

Verify with git --version in a fresh terminal.

Linux

My package manager already has it:

$ sudo apt install git

(Fedora and others use dnf; the package is called git everywhere.) Verify afterwards in a fresh terminal.

Node.js (and npm)

Node brings npm along, so this is two checks in one:

$ node --version
v22.14.0
$ npm --version
10.9.0

Two version numbers = done. Different numbers are expected.

LTS - the one decision that matters

Node ships in two lines. LTS (Long Term Support) is the stable version, patched for years - always choose this one. Current is the newest features, changing fast, for people on the leading edge. Professional teams run LTS almost universally. Remember the acronym and the choice: LTS, stability over novelty.

Windows

Download the LTS installer from nodejs.org, run it with defaults. npm rides along automatically - no separate install. Open a new terminal and run both verify commands.

macOS

Installed via nvm (Node Version Manager). ~/.zshrc must exist first (the touch ~/.zshrc from the Git step covers it). Then:

$ nvm --version        # confirm nvm is present
$ nvm install --lts    # install the stable line by name

The --lts flag asks for the stable line explicitly. Verify with node --version and npm --version in a fresh terminal.

Linux

Installed via nvm (Node Version Manager):

$ nvm --version        # confirm nvm is present
$ nvm install --lts    # install the stable line by name

If nvm says command not found, install it from github.com/nvm-sh/nvm, then open a fresh terminal. Verify with node --version and npm --version.

Why nvm instead of a plain installer (macOS/Linux)

Different projects genuinely need different Node versions, and nvm switches between them with one command. Updates become trivial (nvm install --lts again, whenever). And it installs everything inside my home folder - no sudo, no admin password, none of the permission tangles of a system-wide install. Rare tool that’s both the beginner-friendly and the professional route.

VS Code

No command - three moves I already know:

1. Open VS Code (Start menu on Windows; Spotlight code or Applications on macOS).

2. File → Open Folder, and pick a folder I made earlier (e.g. startupistan-practice).

3. Press Ctrl + backtick (the ` key, top-left) to open the integrated terminal, and run pwd - it should answer with the folder’s path.

All three work → editor ready. Install reference: download from code.visualstudio.com, defaults throughout (Windows installer; drag to Applications on macOS; .deb on Linux).

The trust prompt, explained once

The first time I open a folder, VS Code asks: “Do you trust the authors of the files in this folder?” - a real security feature, since some extensions run code automatically. Rule of thumb: folders I made myself and course projects → Yes, I trust the authors. Random code from unknown corners of the internet → restricted mode is exactly what it’s for. And it’s free with no sign-in - the optional account only syncs settings between machines.

VS Code extensions - the curated twelve

Extensions are where a plain editor gains its abilities. Installing all twelve takes ~10 minutes. The procedure, repeated twelve times:

1. Open the Extensions view - the four-squares icon, or Ctrl + Shift + X.

2. Type the extension’s name in the search box.

3. Check the publisher matches the one listed below - imitations of popular extensions exist, and the publisher line is my guarantee.

4. Click Install. Active in seconds, no restart.

Group	Extensions	Why
Formatting & quality	Prettier, ESLint, HTMLHint, Code Spell Checker	Keep code clean; flag problems before I run anything
Web workflow	Live Server, Auto Rename Tag, JS (ES6) snippets	Speed up building pages - Live Server auto-refreshes the browser on save
Git support	GitLens, Git History	Who changed each line, and a browsable project history
Comfort & readability	Andromeda (theme), Material Icon Theme, Better Comments	The shared look, meaningful file icons, highlighted TODO/warning comments

Quiet isn't broken

Some extensions work immediately; others wake up in later courses. Live Server lights up in Web Foundations, ESLint from JavaScript onward, and GitLens shows nothing until a folder is a Git project - so its silence now is expected, not a fault. Also: more extensions is not better - each costs a little speed and attention. Twelve curated beats fifty accumulated.

VS Code settings - the course five

Extensions give abilities; settings decide behavior. Open Settings with Ctrl + , (comma), use the search box, and set five things:

Search for	Set it to	What it does
format on save	tick Format On Save	Code tidies itself every time I save
format on paste	tick Format On Paste	Pasted code adopts my formatting instantly
default formatter	Prettier - Code formatter	Tells the two above which tool tidies
minimap	untick Minimap: Enabled	Removes the tiny code-overview strip - more room, less noise
telemetry	Telemetry Level → off	No usage data leaves my machine (Datenschutz hygiene)

Prove the whole chain in ten seconds

In my practice folder, make a file test.js, type const x=1; (spacing mess included), and save with Ctrl + S. It snaps to const x = 1;. That one snap proves three things at once: Format On Save is on, Prettier is the default formatter, and the extension is alive.

The browser (Chrome as default)

Two checks: installed and current (three-dots menu → Help → About Google Chrome - it updates itself right there), and set as default (the honest test: click a link from outside a browser - an email, a PDF - and see if it opens in Chrome).

Setting the default: Windows - Settings → Apps → Default apps → Google Chrome → Set default. macOS - System Settings → Desktop & Dock → Default web browser. Linux - Settings → Default Applications. It only changes which app opens links; every other browser stays installed.

The GitHub account

Not software - an identity on the web, and in Course 05 it becomes the online home of everything I build. Verify: log in at github.com; seeing my dashboard is the whole check. Lost password? Use “Forgot password?” now, not mid-course.

If creating a new account

• Username: choose like it’s permanent and public - because it’s both. My GitHub profile becomes part of my professional identity; employers look at it, and it sits on my CV. Something built on my name ages well; jokes and gamer tags don’t. Renaming later breaks every existing link.
• Email: one I’ll keep long-term, not tied to a current job or school.
• Password + 2FA: a strong unique password, and turn on two-factor authentication - GitHub increasingly requires it, and an account holding months of work deserves the second lock.

What I don’t do yet: connect Git on my machine to this account. That handshake opens Course 05. It’s free, and it’s the only account this module needs.

The environment-readiness checklist

One sitting, run from the VS Code integrated terminal. A machine that passes all eight is ready for the whole block.

#	Check	Pass looks like
1	git --version	Any version number
2	node --version	Any version number
3	npm --version	Any version number
4	Extensions (Ctrl + Shift + X)	The twelve are listed under Installed
5	Settings chain	const x=1; snaps to const x = 1; on save
6	Chrome	A link clicked outside a browser opens in Chrome
7	Hyper (macOS & Linux)	Opens and answers pwd
8	GitHub	I can log in at github.com

A failing line now is a success story

Version numbers differing from any example is a pass, not a fail - they differ on every machine. And if a line genuinely fails, that’s exactly what this checklist is for: it costs nothing to fix now, versus mid-course.

Troubleshooting - the three patterns

Pattern	What’s really happening	The fix
command not found right after installing	My terminal read its list of program folders when it opened, before the install added the new one	Fresh terminal first - close completely, reopen, retry. Reinstall only if a genuinely fresh terminal still fails
The installer won’t run / admin prompt rejects me	I’m on a machine where install rights belong to someone else (company/family device)	Human, not technical: the owner or IT enters credentials or installs it. Nothing should bypass that
An old version was already there	An install from years ago	Almost never matters here. If a tool misbehaves and my version is far behind, installing the current version fresh simply replaces the old one - that’s the whole upgrade

The PATH, one level deeper

That “list of folders” has a name: the PATH - an environment variable holding the directories the shell searches, in order, for any command I type. Installers append their folder to it; a running terminal keeps the copy of PATH it started with. That’s the entire mystery of pattern #1 - and the entire reason for the golden rule. See mine with echo $PATH (macOS/Linux) or $env:Path (PowerShell).

Revision summary

Must-know	One-line recall
GUI vs CLI	Clicking vs typing; the terminal is the window where the CLI lives
Terminal vs shell	Terminal = the window; shell (PowerShell / Zsh / Bash) = the program inside that runs commands
Never type the prompt	The $, %, or > is the prompt - I type only what comes after it
The five-command rhythm	pwd (where) · ls (what’s here) · cd (move, .. = up) · mkdir (make) - check-move-confirm
Windows vs Unix commands	touch → New-Item in PowerShell; most others (ls, cat, cp, rm) alias fine
Silence = success	cd / mkdir say nothing when they work; confirm with pwd / ls
Reading errors	not found = typo/missing program · no such file = wrong folder · too many arguments = quote the space
The four tools	VS Code writes · Git remembers · Node.js runs JS (+ npm) · browser shows & inspects
Git vs GitHub	Git = the tool on my machine (offline); GitHub = the online home for Git projects
Node.js = runtime	Runs JavaScript anywhere, not just in a browser; brings npm (package installer)
DevTools is a sandbox	Inspect edits my local copy only; a refresh undoes it - safe to poke anything
Editor vs IDE	Editor = light + general, extend per need (VS Code); IDE = complete workshop for one ecosystem (ABAP later)
The golden rule	After every install: close the terminal, open a fresh one, then verify
Verify = any version	--version answering with any number is the pass - numbers differ on every machine
Node: choose LTS	Long Term Support = stability over novelty; what professional teams run
command not found after install	Almost always a stale terminal - fresh terminal first (the PATH was read at open)