Your Computer, Explained

A computer is not magic, and you do not need to understand all of it at once. For building software, start with five ideas: files hold information, folders organize files, programs read and change them, processes are programs currently running, and networks let one process ask another process for something.

Most technical instructions become easier once you can answer three questions: Where am I? What is running? Where does the information live? These questions are more useful than memorizing commands because they give every command a place in a larger map.

A path is simply an address. If a project contains app/page.tsx, the project is the neighborhood, app is a building, and page.tsx is a room. An absolute path gives the full address from the computer's root. A relative path gives directions from where you currently are.

A software project is usually a folder containing source code, assets, instructions for installing dependencies, and configuration for running or deploying the result. The folder may also be a repository, meaning a history system is tracking its changes. Those are related ideas, but not identical: the project is the work; the repository is the recorded history of that work.

File extensions such as .png, .md, .ts, and .json tell people and programs what kind of information a file is expected to contain. They are labels, not guarantees. You still need to inspect the contents when the distinction matters.

An app is the experience you open. Behind it, one or more processes do the actual work. Closing a window does not always stop its process, and starting an app twice may create two processes. This matters when an old development server keeps using a network port or a build seems to be running code you already changed.

The terminal is a text-based way to give your computer instructions. It is not a separate technical universe. Opening a folder in Finder and running cd into that folder in a terminal are two ways of navigating the same filesystem. Clicking an app and running a command are two ways of starting a process.

Before executing a command you do not understand, ask what it reads, what it changes, where it runs, and how to reverse it. Treat commands from agents and tutorials as proposed actions, not spells.

Local means the work is happening on the computer in front of you. Cloud means it is happening on a computer operated elsewhere. The same project can exist in both places, but changing the local copy does not automatically change the live website. Building, committing, pushing, and deploying are separate events that create different kinds of proof.

When a local website says it is running on localhost:3000, localhost means this computer and 3000 is the port—a numbered door used by a process. Two processes cannot normally listen through the same door at the same time. If the browser cannot connect, the process may have stopped, may be using another port, or may have failed before opening the door.

A URL combines these ideas into an address: the protocol describes how to communicate, the domain identifies the machine or service, the port identifies a door when needed, and the remaining path identifies a resource or route inside the application.

Software behaves differently in different places because of configuration. An environment variable is a named value supplied to a running process, such as which database to use or whether the app is in development mode. A secret is sensitive configuration such as a password or API key.

Code can be shared; secrets should not be. Do not paste secrets into source files, screenshots, public chats, or Git history. Store them in the environment or a secret manager, give each process only the access it needs, and rotate a secret if it has been exposed.

When an agent says something works, ask where it worked and which configuration it used. A local process with your private key is not proof that a deployment has the same key, network access, permissions, or data.

When you feel lost, do not guess faster. Rebuild the map. Name the project folder, the file you expect to matter, the process that should read it, the address you are using to reach that process, and the place where its data or configuration lives.

This habit scales. A beginner uses it to find a missing file. An experienced engineer uses the same structure to investigate a production incident across many services. The system becomes larger, but the questions remain recognizable.