Building Blocks

Draft v0. A living catalog, not a locked list — expected to grow throughout writing.

This is the vocabulary catalog for non-developer readers, organized by job rather than alphabetically. The organizing insight: most of the scary words a beginner meets are not 40 unrelated things to memorize — they’re a handful of families, where the members do the same job and are mostly interchangeable. Knowing that npm, pip, and brew are all “the install command for their world” kills more overwhelm than 40 separate definitions ever could.

Each family lives in two homes:

• The Map — a very concise front-matter section. A figure plus a few sentences. The whole map should be skimmable in a few minutes. Its only goals: create a visual association, and teach the reader to recognize the family and the shared verb/job.
• The Glossary — an in-depth reference section. What you flip to when you hit a specific term and want the full story. Likely alphabetical by term in the final book; grouped by family here while drafting.

(Where these two sections land in the book — which chapter, which appendix — is unsettled; this file commits only to the concise-vs-deep split, not to any placement.)

The recurring move throughout: recognize the pattern, don’t memorize the list. A non-dev almost never chooses which family member to use — their operating system, their project, or Claude picks. Their job is to recognize what kind of thing they’re looking at, and what tends to go wrong.

THE FAMILY MAP — front-matter

(concise; the figures do the work)

1. Where you type commands

(terminal · console · CLI · shell · command line · command prompt)

[FIGURE] A plain black window with a blinking cursor and a single typed line: git status. A label points at the window: “this is the terminal.” A second label points at the typed word: “this is a command.”

It’s the typing-instead-of-clicking way to use a computer: a window where you type a command, press Enter, and the computer does the thing. Terminal, console, CLI, shell, command line, command prompt all point at roughly the same picture — a place to type commands. This is where you and Claude do most of your work together.

→ Glossary: the subtle differences between these words.

2. The big three operating systems

(macOS · Windows · Linux)

[FIGURE] Three labeled doors side by side — an Apple (macOS), a window (Windows), a penguin (Linux) — each opening onto the same room of files and apps, arranged a little differently.

The operating system is the ground floor everything else stands on. Almost every “this command doesn’t work” moment traces back to which of these three you’re on, because they keep their files in different places and speak slightly different command dialects. macOS and Linux are close cousins (both Unix-family); Windows is the odd one out. Claude needs to know which you’re on — tell it once.

→ Glossary: why Mac and Linux commands often work on each other but not on Windows.

3. Languages for bossing the computer around

(shells: Bash · Zsh · PowerShell · cmd / .bat)

[FIGURE] The same black window from Family 1, but now four name-tags hang off it: Bash, Zsh, PowerShell, cmd. A caption: “same window, different dialects.”

A “shell” is the language you type into the terminal window. They mostly do the same things (list files, move files, run programs) in slightly different words. Bash and Zsh are the Mac/Linux dialects (Zsh is the modern Mac default); PowerShell and the older cmd / .bat are the Windows dialects. The usual trap: a command written for one dialect quietly failing in another.

→ Glossary: which shell you’re probably using, and why a copied command sometimes just doesn’t run.

4. Ways to store and pass around data

(JSON · XML · YAML · TOML)

[FIGURE] The same shopping list — milk, eggs, bread — written four times in four slightly different notations, each labeled JSON / XML / YAML / TOML. A caption: “same information, different punctuation.”

These are formats for writing structured information down as plain text, so programs (and people) can read it. They are interchangeable in purpose — the same data, different punctuation. JSON is what programs use to talk to each other; YAML and TOML are the friendlier ones used for settings files; XML is the older, wordier ancestor you still meet in established systems.

→ Glossary: which one you’ll see where, and why a single misplaced comma breaks them.

5. Ways to write documents and web pages

(Markdown · HTML · CSS)

[FIGURE] Three stacked layers of a single web page: a wireframe skeleton (HTML), a coat of paint and fonts (CSS), and a sticky note with plain-text shorthand (Markdown) feeding into the skeleton.

These build the documents and pages you read on screens. HTML is the skeleton (what’s a heading, what’s a paragraph, what’s a button). CSS is the paint (colors, fonts, spacing — how it looks). Markdown is shorthand: a simple way to write formatted text using plain characters like # and *, which then turns into HTML. (This very file is Markdown.)

→ Glossary: how the three stack together to make a web page.

6. How programs talk over the internet

(URL · HTTP(S) · REST API · GraphQL)

[FIGURE] A waiter (your app) carrying an order ticket to a kitchen (a server) and bringing a plate back. The ticket is labeled “request,” the plate “response,” the kitchen’s address is the URL, and the language on the ticket is HTTP.

This family is how one program asks another program for something across the internet — the restaurant model: you order, the kitchen cooks, you get a plate. A URL is the address. HTTP(S) is the rules of the conversation (the S just means encrypted/safe). An API is the menu of things you’re allowed to order; REST and GraphQL are two popular menu styles.

→ Glossary: what “calling an API” actually means, and what those number codes (404, 500) are.

7. Languages for writing programs

(JavaScript/TypeScript · Python · Go · Ruby · Rust · C / C++ · Zig)

[FIGURE] A row of toolboxes, each stamped with a language name, all containing the same basic tools (a hammer, a wrench) but sized for different jobs — a tiny one for “quick scripts,” a heavy one for “high-performance.”)

These are the languages programs are written in. They overlap enormously — most can build most things — but each has a comfort zone: JavaScript/TypeScript runs the web, Python rules data/AI and quick scripts, Go is favored for fast backend services and command-line tools, Ruby for web apps, and Rust / C / C++ / Zig for the demanding low-level stuff where speed and control matter most.

→ Glossary: how to tell them apart on sight, and why Claude picks one over another.

8. What runs JavaScript outside the browser

(Node.js · Bun · Deno)

[FIGURE] A web browser with a JavaScript gear inside it, and next to it a standalone engine box — also with a JavaScript gear — labeled “Node / Bun / Deno: the same fuel, no browser required.”

JavaScript was born inside web browsers. These three are engines that let it run anywhere else — on servers, on your laptop, as command-line tools. They do the same job and are largely interchangeable: Node.js is the long-established default; Bun is the newer, faster all-in-one; Deno is the security-minded alternative from Node’s own creator.

→ Glossary: how this family relates to the package managers in Family 9.

9. Tools that install other tools

(package managers: Homebrew · APT · Chocolatey · npm · pip · uv · …)

[FIGURE — “Two shelves”] Top shelf “YOUR WHOLE COMPUTER”: a Mac (Homebrew), a Windows PC (Chocolatey/WinGet), a Linux penguin (APT/DNF). Bottom shelf “ONE PROJECT FOLDER”: a JavaScript box (npm), a Python box (pip/uv). One arrow across both: ______ install <name>

brew install, npm install, apt install are the same verb — “go fetch this and set it up” — for different worlds. There are two layers: managers that install apps onto your whole computer, and managers that install spare parts into one project. You don’t pick one; your operating system and your project’s language pick for you. A failure here usually means the wrong world’s tool was assumed (a brew command on Windows).

→ Glossary: the full two-layer breakdown and the complete name list.

10. Picture file formats

(JPG/JPEG · PNG · GIF · SVG · WebP)

[FIGURE] The same logo saved as five files. A photo-ish version (JPG), a crisp version on a transparent checkerboard (PNG), a tiny looping animation (GIF), a version being stretched huge with no blur (SVG), and a “modern/smaller” tag (WebP).

All hold images; each is best at something. JPG/JPEG is for photographs (small files, slight quality loss). PNG is for graphics and anything needing a transparent background (crisp, larger). GIF is the short looping animation. SVG is special: it’s a recipe for a picture rather than a grid of dots, so it scales to any size without going blurry. WebP is a newer all-rounder that makes smaller files.

→ Glossary: “lossy vs. lossless,” and why SVG can scale forever but JPG can’t.

11. Video file formats

(MP4 · MOV · WebM)

[FIGURE] A film reel inside a labeled box, with a caption distinguishing “the box” (MP4 / MOV / WebM) from “what’s inside” (the actual video, squeezed by a codec).

The video cousins of Family 10. MP4 is the safe universal choice that plays nearly everywhere. MOV is Apple’s format (what your iPhone records). WebM is the open, web-friendly one. The subtlety worth a sentence: the file format is just the box; a separate thing called a codec does the actual squeezing inside — which is why a video file sometimes won’t play even though the format looks familiar.

→ Glossary: container vs. codec, in plain terms.

12. Where data is stored permanently

(databases: SQLite · MySQL · PostgreSQL)

[FIGURE] Three filing cabinets. A small one that lives inside the app’s own folder (SQLite), and two larger ones that sit in their own separate room with a clerk at the door (MySQL, Postgres).

A database is where an app keeps information so it survives after you close it — accounts, orders, messages. SQLite is the small one that lives as a single file inside your app, with nothing to set up — great for getting started. MySQL and PostgreSQL are the bigger ones that run as their own separate service for serious, multi-user apps; Postgres is the more powerful/feature-rich, MySQL the long-time web classic.

→ Glossary: why “it works on my laptop with SQLite” can break when you switch to Postgres.

13. Toolkits for building app screens

(frontend frameworks: React · Vue · Svelte)

[FIGURE] Three different brands of Lego-style kits, each building the same interactive web page (a button, a form, a live counter), with a caption: “same page, different kit.”

These are toolkits for building the interactive part of a website or app — the buttons, forms, and live-updating screens — without reinventing the wheels each time. They are interchangeable for the job; teams pick one and stick with it. React is the dominant one (by Meta), Vue is known as the approachable one, and Svelte is the newer one that does more of the work ahead of time so the result is leaner.

→ Glossary: what a “framework” buys you, and why the choice is mostly a team preference.

THE GLOSSARY — in-depth reference

(what you flip to; likely alphabetical by term in the final book)

Family 1 — Where you type commands

Terminal. The window itself — the app that gives you a place to type commands. On a Mac it’s literally called “Terminal”; on Windows the modern one is “Windows Terminal.”

Console. Used almost interchangeably with “terminal.” Historically a console was the physical screen-and-keyboard attached directly to a computer; today people say it loosely to mean the same text window.

Command line / command prompt. The line where you actually type, marked by a prompt symbol (often $, %, or >). “On the command line” just means “by typing commands.”

CLI (Command-Line Interface). The opposite of a GUI (the click-and-point Graphical User Interface). A tool described as “a CLI” or “available via CLI” is one you drive by typing rather than clicking. When Claude says “run this in your CLI,” it means “type this in your terminal.”

Shell (preview — see Family 3). Technically the program that reads what you type and carries it out. The terminal is the window; the shell is the thing listening inside it.

What you actually need to know: for a beginner these are close enough to treat as one idea — “the place I type commands.” The distinctions only start to matter once you’re customizing your setup.

Family 2 — The big three operating systems

Operating system (OS). The base software that runs your whole computer and everything on it — manages files, runs apps, talks to the hardware.

macOS. Apple’s operating system, on Macs. Belongs to the Unix family, so its terminal commands closely resemble Linux’s.

Windows. Microsoft’s operating system, on most PCs. Not in the Unix family — it organizes files differently (e.g. C:\Users\you with backslashes) and uses different shells, which is the source of most cross-platform command failures.

Linux. A free, open Unix-family operating system that comes in many “flavors” (distributions / “distros” — Ubuntu, Debian, Fedora, Arch…). It powers the majority of the world’s servers, so even Mac and Windows users meet it the moment they deploy something to the internet.

Why it matters with Claude: a command Claude gives you is often OS-specific. If you tell Claude up front “I’m on Windows” (or Mac, or Linux), you avoid a whole category of “that didn’t work” loops. What trips people up: copying a command from a tutorial written for a different OS — paths with / vs \, and tools that simply don’t exist on the other system.

Family 3 — Languages for bossing the computer around (shells)

Shell. The program that interprets the commands you type and runs them. Different shells are different dialects of command language.

Bash. The long-standing default shell across Linux and older Macs. The most common dialect in tutorials and scripts (“shell scripts” usually means Bash scripts).

Zsh (Z shell). The modern default shell on Macs (since macOS Catalina). Very close to Bash — most Bash commands work unchanged — with niceties added.

PowerShell. Microsoft’s modern, powerful shell for Windows (also runs on Mac/Linux). A genuinely different language from Bash/Zsh — commands look different (e.g. Get-ChildItem rather than ls).

cmd.exe / Batch / .bat. The old Windows command prompt and its script files (ending in .bat). Still around, largely superseded by PowerShell.

Shell script. A file full of shell commands run in sequence — automation written in one of the dialects above. A .sh file is typically Bash/Zsh; a .bat/.ps1 file is Windows.

What trips people up: assuming a command is universal. A snippet written for Bash may fail in PowerShell and vice-versa. What you actually need to know: tell Claude your shell (most Mac users: Zsh; most Linux: Bash; most Windows: PowerShell), and it will hand you commands in the right dialect.

Family 4 — Ways to store and pass around data

These are text formats for structured information. All store the same kinds of data; they differ in punctuation and intended use.

JSON (JavaScript Object Notation). The lingua franca of programs talking to each other, especially over APIs (Family 6). Compact, uses { } and [ ]. If an app sends or receives data online, it’s very often JSON.

XML (eXtensible Markup Language). The older, wordier ancestor, using <tags> like HTML. Still common in established enterprise systems and certain document formats.

YAML. Designed to be easy for humans to read and write, using indentation instead of brackets. Dominant for configuration/settings files (build pipelines, app config).

TOML (Tom’s Obvious Minimal Language). Another human-friendly config format, favored where YAML’s indentation feels error-prone. Used by tools like Rust’s Cargo and Python’s pyproject.toml.

What trips people up: these formats are strict. One misplaced comma, bracket, or wrong indentation makes the whole file unreadable to the program — and the error message is often cryptic. What you actually need to know: if Claude says “your JSON is invalid” or “YAML parse error,” it’s almost always a punctuation/indentation slip, not a deep problem.

Family 5 — Ways to write documents and web pages

HTML (HyperText Markup Language). The structure of a web page: it labels what’s a heading, a paragraph, a list, a link, a button. It’s the skeleton — present on every web page in existence.

CSS (Cascading Style Sheets). The appearance layer: colors, fonts, spacing, layout, animations. Same HTML skeleton + different CSS = a completely different-looking page.

Markdown. A lightweight shorthand for formatted text using plain characters — # Heading, *italic*, - list item. It converts into HTML behind the scenes. Loved because it’s readable as-is and easy to write. (README files, chat apps, and this very document are Markdown.)

How they fit together: Markdown is the easy front door that becomes HTML; HTML structures the page; CSS dresses it up. What you actually need to know: you’ll write Markdown constantly when working with Claude (notes, docs, prompts). You’ll read HTML/CSS far more than you write it by hand — Claude generates those.

Family 6 — How programs talk over the internet

URL (Uniform Resource Locator). A web address — the location of a thing on the internet (https://example.com/users/42). It’s the “where.”

HTTP / HTTPS (HyperText Transfer Protocol). The agreed-upon rules for requesting something at a URL and getting an answer back. The S means the conversation is encrypted (secure) — the difference between shouting in public and speaking in a sealed envelope.

Request / Response. The two halves of every exchange: your app sends a request (“give me user 42”), the server sends back a response (the data, or an error).

Status codes. The short numbers in a response saying how it went: 200 = OK, 404 = not found, 500 = the server broke. When Claude mentions “a 404,” it means “the thing wasn’t there.”

API (Application Programming Interface). The defined set of requests one program is allowed to make of another — the menu of available orders. “Calling an API” = sending it a request.

REST. The most common style of web API, built on plain HTTP verbs (GET to read, POST to create, etc.). When people say “a REST API,” they mean an API that follows this familiar convention.

GraphQL. An alternative API style where the caller asks for exactly the fields it wants in one flexible query, instead of hitting many fixed endpoints. Solves a real problem REST has with over- and under-fetching data.

What you actually need to know: “calling an API over HTTP” is just one program ordering data from another across the internet. REST vs. GraphQL is a how-it’s-organized choice the developer (or Claude) makes; both get you the data.

Family 7 — Languages for writing programs

All are general-purpose — most can build most things — but each has a home turf and a “feel.”

JavaScript (JS). The language of the web browser; also runs servers (via Family 8). Unavoidable for anything interactive on a web page.

TypeScript (TS). JavaScript with a safety layer added (it checks that, say, a number isn’t accidentally used as text before the program runs). Converts to JavaScript to actually run. Increasingly the default for serious web projects.

Python. Famous for readability. Dominant in data science, AI/machine learning, automation, and quick scripts. Often the first language taught.

Go (Golang). Made at Google for fast, simple backend services and command-line tools. Compiles to a single self-contained program. Common in cloud infrastructure.

Ruby. Prized for developer happiness and elegant code; best known for the Ruby on Rails web framework.

Rust. Delivers C-level speed with strong guarantees against a whole class of memory bugs. Beloved (and notoriously strict) — used where safety and performance both matter.

C / C++. The veterans. Close to the hardware, extremely fast, and underneath almost everything (operating systems, browsers, games). More manual and less forgiving.

Zig. A newer language aiming to be a simpler, more modern alternative to C. Niche today, growing.

Compiled vs. interpreted (the one distinction worth knowing): some languages (Go, Rust, C/C++, Zig) are compiled — translated ahead of time into a standalone program. Others (Python, Ruby, JavaScript) are interpreted — run line-by-line by another program. It mostly affects how you start them and how fast they run. What you actually need to know: you rarely choose the language; the project or Claude does. Recognizing one on sight (Python’s indentation, JavaScript’s { } and =>) is enough to follow along.

Family 8 — What runs JavaScript outside the browser

Runtime. The engine that actually executes code. JavaScript’s original runtime was the web browser; these let it run elsewhere.

Node.js. The established standard for running JavaScript outside the browser — on servers, build tools, and command-line apps. The reason npm (Family 9) exists. If a JavaScript tool runs on your machine, it’s usually running on Node.

Bun. A newer, much faster all-in-one runtime that also bundles its own package manager and other tools. A drop-in speed upgrade for many Node projects.

Deno. Built by Node’s original creator to fix early design regrets — notably secure-by-default (code can’t touch your files or network unless you allow it).

How it relates to Family 9: the runtime runs your JavaScript; the package manager fetches the spare parts it needs. Node pairs with npm; Bun and Deno include their own. What you actually need to know: “running on Node” just means “JavaScript executing on your computer rather than in a web page.”

Family 9 — Tools that install other tools (package managers)

Package manager. A catalog you install things from with one command, instead of finding a website, downloading a file, and clicking an installer. Closest everyday analogy: the App Store, but typed.

The wrinkle worth understanding is that there are two layers that look nearly identical:

• Computer-level managers install apps and tools onto your whole machine — a database, a language, a command-line utility.
• Project-level managers pull in the spare parts a single project needs (code written by other people) and keep them inside that project’s folder, touching nothing else.

Computer-level, by operating system:

• macOS: Homebrew (brew, by far the common one); MacPorts (older alternative).
• Windows: Chocolatey, Scoop, WinGet (Microsoft’s own), Ninite (a click-based installer bundle).
• Linux: decided by your distro — APT (Debian/Ubuntu), DNF/YUM (Fedora/Red Hat), Pacman (Arch); plus Flatpak and Snap, which work across distros.

Project-level, by language:

• JavaScript: npm (comes with Node), pnpm and yarn (faster alternatives).
• Python: pip (comes with Python), uv (newer, much faster).
• Other languages bundle their own (Rust’s Cargo, Go’s built-in module tooling).

When you’ll meet it: Claude says to run something like brew install postgresql or npm install — the developer equivalent of “first, go get these ingredients.” What trips people up: assuming the two layers are the same thing, and running a command from the wrong world (most often a Mac brew command on Windows). What you actually need to know: recognize the verb — any ... install ... means “fetch and set up” — and know that a failure usually means a mismatch between the tool and the world you’re in.

Family 10 — Picture file formats

JPG / JPEG. Best for photographs. Squeezes files small by throwing away detail your eye won’t miss (“lossy”). Bad at sharp edges, text, and transparency.

PNG. Best for graphics, logos, screenshots, and anything needing a transparent background. Keeps every pixel exact (“lossless”), so files are larger but crisp.

GIF. The short, silently looping animation. Limited to 256 colors, so poor for photos — but ubiquitous for reaction clips.

SVG (Scalable Vector Graphics). Different in kind: instead of a grid of colored dots, it stores a recipe (lines, shapes, math). Because it’s drawn fresh at any size, it scales infinitely without blurring — ideal for logos and icons. It’s actually text/code under the hood.

WebP. A modern format that does JPG’s and PNG’s jobs in smaller files. Increasingly common on the web; less universally supported in older tools.

Lossy vs. lossless (the key idea): lossy (JPG, WebP) trades a little quality for much smaller files; lossless (PNG) keeps everything. What you actually need to know: photo → JPG; logo/transparency → PNG; needs to scale → SVG. That covers most decisions.

Family 11 — Video file formats

Container vs. codec (the one distinction worth knowing). A video file is a container (the box) holding video and audio that a codec has compressed (the squeezing method). The file extension names the box; the codec inside can vary. This is why a .mp4 sometimes won’t play: the box is fine, but your player doesn’t understand the codec inside.

MP4. The safe, near-universal container. When in doubt, this is the one that plays everywhere.

MOV. Apple’s QuickTime container — what an iPhone records. Plays best in the Apple world; usually convertible to MP4.

WebM. An open, royalty-free container built for the web. Common in browsers; less so on consumer devices.

What you actually need to know: if Claude (or a tool) produces a video that won’t play, the fix is usually “convert it to MP4” — which re-boxes it with a widely-understood codec.

Family 12 — Where data is stored permanently (databases)

Database. Organized, lasting storage for an app’s information (accounts, orders, posts) so it survives restarts. SQL is the standard language used to ask databases questions (“give me all orders from May”).

SQLite. A whole database that lives as a single file inside your app, with nothing to install or run separately. Perfect for getting started, small apps, and prototypes. Its trade-off: it isn’t built for many users writing at the same moment.

MySQL. A long-established database that runs as its own separate service. The classic choice behind a huge share of the web (WordPress, etc.).

PostgreSQL (“Postgres”). Also a separate-service database, generally considered the more powerful and feature-rich. A common default for serious new projects.

What trips people up: “it works on my laptop” with SQLite, then behaves differently after switching to Postgres/MySQL for launch — because the simple file-based one and the full-service ones differ in subtle rules. What you actually need to know: SQLite = zero-setup, lives in a file, great to start; MySQL/Postgres = real services for real traffic. Moving from one to the other later is a known, plan-able step.

Family 13 — Toolkits for building app screens (frontend frameworks)

Frontend. The part of an app you see and click (as opposed to the backend, the server-side logic and database behind it). “Frontend framework” = a toolkit for building that visible, interactive part.

Framework. A pre-built structure and set of conventions that saves you from reinventing common machinery. You build within its patterns.

React. The dominant frontend framework (from Meta). The most jobs, the most tutorials, the biggest ecosystem. Often paired with add-ons like Next.js.

Vue. Widely seen as the most approachable to learn, with a gentle on-ramp. Popular for projects that want productivity without React’s sprawl.

Svelte. The newer challenger. It does much of its work ahead of time (compiling away the framework), so the shipped result is leaner and fast. Less boilerplate to write.

What you actually need to know: all three build the same kinds of interactive screens; the choice is mostly team preference and what they already know, not a right-vs-wrong call. If Claude is generating a frontend and you have no preference, React is the safe, well-documented default.

Cross-cutting — judgment & scope vocabulary

Not a building-block family. These are the push-back words a reader says to Claude to rein in additive bias; full treatment (why each one has leverage, how to phrase it, the shared caveat) is in words-that-push-back.md , sectioned into Chapter 3. Stubs only here, alphabetical, for glossary lookup.

Gold-plating. Adding polish or features beyond what was asked — making the deliverable “nicer” than the spec at a cost in complexity nobody agreed to. Say it to reject unrequested extras. → full entry.

Minimal diff. The positive instruction of the set: “make the smallest change that satisfies the requirement, touch as few lines/files as possible, leave unrelated code alone.” Prevents scope creep by setting a target rather than issuing a veto. → full entry.

Over-engineering. The plain-English umbrella — a solution more complex or clever than the problem warrants. Use when you can feel a change is too much but can’t name which specific smell it is. (Cousins: over-built, over-complicated.) → full entry.

Premature abstraction. Building a general, reusable structure before you have enough real cases to know the right generalization. Siblings Claude also knows: premature optimization (fast before correct) and speculative generality (Fowler’s code smell). → full entry.

Scope creep. The requirement quietly drifting bigger across a conversation — each “while I’m in here” addition reasonable alone, the sum well past the ask. Names the drift rather than any single addition. → full entry.

YAGNI (“You Aren’t Gonna Need It”). The anchor term: don’t build something until you actually need it. The most direct counter to additive bias, and a term Claude knows cold from training. → full entry.

Cross-cutting — correctness vocabulary

Also not a building-block family. Two entries, really one idea: a word that carries a whole engineering habit of mind — Claude reaches for it constantly to explain why a design has no knob — and the word it is always contrasted against. The decode-Claude treatment — including how the word can make a judgement call sound like a law of nature — is the Invariant entry in terms-claude-likes.md , sectioned into Chapter 3. Stubs only here, for glossary lookup.

Invariant. Something a system guarantees is always true because of how it was built, not because someone remembered to check. “Every order has a customer” is an invariant if the database physically refuses to store an order without one; it is only a hope if the rule lives in a note somewhere and everyone is trusted to follow it. Engineers prize invariants because each one removes a whole category of thing you would otherwise have to keep verifying forever. → full entry.

Parameter (the word invariant is usually contrasted against). A choice with more than one valid answer — the kind of thing that deserves a setting, a flag, or a question put to you. The pairing is the useful part: when Claude says “this is an invariant, not a parameter,” it is telling you there is nothing here for you to decide. Sometimes that is genuinely true of the design; sometimes it is a decision Claude made on your behalf and phrased as a law. The full entry has the one question that tells them apart. → full entry.

Running family list (for future additions)

1. Where you type commands — terminal/console/CLI/shell
2. Operating systems — macOS/Windows/Linux
3. Shells — Bash/Zsh/PowerShell/cmd
4. Data formats — JSON/XML/YAML/TOML
5. Document & page formats — Markdown/HTML/CSS
6. Talking over the internet — URL/HTTP(S)/REST/GraphQL
7. Programming languages — JS/TS/Python/Go/Ruby/Rust/C/C++/Zig
8. JavaScript runtimes — Node/Bun/Deno
9. Package managers — Homebrew/APT/Chocolatey/npm/pip/uv/…
10. Picture formats — JPG/PNG/GIF/SVG/WebP
11. Video formats — MP4/MOV/WebM
12. Databases — SQLite/MySQL/Postgres
13. Frontend frameworks — React/Vue/Svelte

Candidates to consider as the book grows: version control (Git/GitHub), editors/IDEs (VS Code/JetBrains), containers (Docker), cloud/hosting (AWS/Vercel/Netlify), environment & config (env vars, .env), regular expressions, tools like jq/grep/curl, and “what’s an SDK / library / dependency.”

Strongest current candidate — what a program is on disk (source · binary · executable · artifact · build · compile). Not Claude jargon; ordinary industry vocabulary where several words name the same file and the differences are invisible to a non-developer. Source is the text a human wrote; compiling turns it into a binary (so called because its contents are machine code, not readable text), which is the same thing as an executable (a file the operating system can run); artifact and build are what people call that output when talking about producing it. A reader who doesn’t hold this distinction can’t tell whether a thing already exists on disk or has yet to be produced — the exact confusion documented in the Route / Routing entry of terms-claude-likes.md , where “code routing” should have been “executable routing” and the mismatch helped manufacture a phantom constraint (Case 6). Surfaced by that entry; worth promoting to a numbered family.

Cross-cutting vocabulary (NOT building-block families — these live in terms-claude-likes.md, with the judgment/scope push-back words stubbed above under “Cross-cutting — judgment & scope vocabulary”): the -bearing suffix is the first of these worth tracking — load-bearing (“does important work”) vs. X-bearing (“field X is non-empty,” the interest-bearing / fruit-bearing idiom, e.g. plan-bearing). It’s a jargon pattern that cuts across families rather than a family of its own, so it’s parked here as a pointer, not catalogued above. Expect more such suffixes/coinages to accumulate.

Found something wrong, unclear, or plainly disagreeable? Open an issue