How does code become the app on my phone?

How does code become the app on my phone?

The app on your phone started as plain text files, written by people, and everything between those files and your home screen is a series of steps a team runs over and over. A developer types instructions into a text file. Those files collect in a shared project folder the whole team works from. The text gets turned into a form a phone or a web browser can run. Then it gets delivered to real users. That last stretch, from a developer's laptop to your phone, has its own lesson later in this module: how code gets from a laptop to a customer.

This lesson covers the first stretch: what the text is, where it lives, and what the person writing it actually looks at for eight hours a day. The module overview ties the full path together if you want the map before the terrain.

One idea carries through the whole path. Software is text, written and rewritten by a team, and every stage of the work leaves a visible record. That record is why you can learn real things about a developer from their work, which is where this course is headed.

What is code, exactly?

Code is plain text that tells a computer what to do. It lives in ordinary files, and anyone can open one and read it the way they would open a document. Here are two real lines of it:

const price = quantity * unitPrice;
sendReceipt(customer.email, price);

You can already follow the shape: multiply two numbers, then send a receipt to an email address. The words are English, the structure is strict, and the strictness is the point. A computer follows instructions exactly, so the instructions have to be exact.

Code is written in a programming language, which is a fixed set of words and rules for phrasing those instructions. There are many languages, the way there are many human languages, and later lessons sort out which ones signal what. For now the useful fact is smaller: a developer reading code is reading text, in a language they know, in a file anyone could open.

That makes code a work product you can inspect. A sales team's calls disappear when they end. A developer's work sits in files, with the author's name on every change, often for years.

Where does the code live?

The code for one product lives in a repository: a shared folder that holds all the project's files plus the full history of every change ever made to them. Developers say "repo" in conversation. The history part matters and is what separates a repository from a folder in Dropbox. Every change records who made it, when, and why, and the team can look back through all of it.

All of a product's code, taken together, is its codebase. The two words are close but point at different things. The codebase is the code itself, the way "the manuscript" means the book's text. The repository is the place it lives and the history it carries. A small product's codebase might be a few thousand lines. A mature one runs to millions, written by hundreds of people over a decade.

The repository lives on a service on the internet, so the whole team shares one source of truth. Each developer then copies it down to their own machine to work on. That copy is called a clone. A developer clones the repository, changes their local copy, and sends the changes back up for the team to review. How the team keeps hundreds of people from trampling each other in one shared folder is its own lesson: how the team moves.

What is a developer looking at all day?

Two windows, mostly. The first is an editor: a program built for reading and writing code. It looks like a document editor with the codebase's file list down one side, and it does things Word never needed to. It colors the text by meaning, so names, numbers, and instructions are visually distinct. It jumps from a name to the place that name is defined, three files away. It flags errors while the developer types, before the code ever runs. The most common editor is VS Code, a free one from Microsoft that a majority of developers use.

You will also hear IDE, which stands for integrated development environment. An IDE is an editor with more machinery attached: tools for running the code, testing it, and stepping through it while it runs. In everyday speech "editor" and "IDE" blur together, and hearing either one on a call carries no signal by itself. Every developer uses one, the way every recruiter uses email.

The second window is a terminal: a plain text window where the developer types commands to the computer and reads its replies. No buttons, no icons, a blinking cursor on a dark background. It looks archaic and it is the opposite. Typed commands are precise, repeatable, and fast, so developers run their code, fetch teammates' changes, and control their tools from the terminal all day. When a film shows a hacker typing into a black window, that is a terminal, doing normal work with dramatic lighting.

What is a feature?

A feature is one useful thing the product does for a user. Password reset is a feature. Export to PDF is a feature. The product is the whole thing a customer uses, and a feature is one unit of usefulness inside it. Most of a developer's work arrives as feature requests: make the product do this new thing, or make an existing thing better.

The verb that goes with feature is ship. Shipping means the feature is live and real customers can use it. The word sets a deliberately high bar. A feature that works on the developer's laptop has not shipped. A feature that is finished but waiting on review has not shipped. Engineering teams measure themselves on shipping because everything short of it delivers nothing to a user, and when a developer says they shipped something, they are claiming they carried it the whole way.

The word itself is a fossil. Software used to leave the building on physical disks, in boxes, on trucks. The trucks are gone and the word stayed, because teams still needed a word for the moment work stops being internal and starts being real.

Why is most of the work reading rather than writing?

Because almost no developer starts from an empty file. They start from a codebase that already exists, written by dozens of people over years, and their task is to change it without breaking it. Before writing anything, they have to find where the relevant code lives, understand what it does, and understand what else depends on it. A developer adding one feature to a mature product may read for hours and then change forty lines.

The empty-file version of the job is rare for another reason too: most of any product is prewritten code the team pulled in rather than wrote, which is the subject of the next lesson. Developers also lean on AI tools that generate code, which shifts even the writing toward reading: someone still has to understand what got generated and judge whether it belongs.

This is why experienced developers describe their skill as reading code as much as writing it. Working fast in a large unfamiliar codebase, finding the right forty lines among a million, is a distinct ability that grows with exposure to real production systems. It is also why "years of experience with a language" understates what a senior developer brings. The language is the alphabet. The skill is navigating what other people built with it, and that only comes from having done it. Software also keeps demanding this because it keeps changing after launch, which is why software is never done.