How does software get built, start to finish?

How does software get built, start to finish?

Software gets built by a developer writing text in a programming language, saving it into a shared project folder, and sending it down a fixed series of steps until it runs on the computers that serve customers. That one sentence is the whole journey. Everything else in this module is a closer look at one of its stops.

The journey is worth learning because every word an engineering team uses lives at a specific point on it. Repo, API, deploy, staging, production, tech debt, sprint: each of these names a step, a place, or a cost somewhere between a developer's keyboard and a customer's phone. Once the path is clear, the vocabulary attaches itself.

This guide walks the path once, end to end. Eight lessons in this module then go deep on each stop. Read this page first, follow the links wherever a stop matters to your req, and come back when a new word needs a home.

What is code, and where does it live?

Code is plain text that tells a computer what to do. A code file opens and reads like any document. There is no special sealed format, and a curious person can read one today. The full set of code behind one product is called a codebase, and it ranges from a few thousand lines for a small tool to many millions for a product like Salesforce.

The codebase lives in a repository, a shared project folder that also keeps the full history of every change ever made to it. Teams shorten the word to repo. When a developer joins a team, their first act is to copy the repo onto their own machine and start reading. How does code become the app on my phone? covers this first stop in full, including what a developer's screen looks like all day.

The text is written in a programming language, a set of words and rules the computer can follow. Python, Java, and JavaScript are three of the most common. Languages matter less than resumes make them look, because an experienced developer picks up a second one in weeks. What takes years is judgment, and judgment travels.

One more fact reshapes how a codebase should be read: the team wrote a minority of it. Most of an application is frameworks and libraries, large bodies of prewritten code that other people built and gave away. A developer's craft is choosing those parts, connecting them, and writing the code specific to their own product. Do developers write all the code themselves? explains this assembly model, and it is the single best correction to the mental image of a lone genius typing everything from scratch.

What are the two halves of an app?

An app has a frontend and a backend, and the split explains half the job titles you will ever source for. The frontend is the part a person sees and touches. It runs on the user's own device, in their browser or on their phone. The backend runs on the company's computers. It stores the data, enforces the rules, and decides what each user is allowed to do.

The two halves talk through an API, an agreed list of requests one piece of software will answer for another. When an app shows your order history, the frontend asked the backend's API for it. When two companies connect their products, each one is calling the other's API. The word appears in nearly every backend job description because it describes the most common backend work. What are frontend, backend, and an API? is the lesson where nodding along to the word stops.

Behind the backend sits the database, the organized storage that holds everything the company knows. A request to a database is called a query, and SQL is the language most queries are written in. Database work is its own specialty because a badly shaped database limits the speed and cost of the whole product, and reshaping one after launch is slow and risky. What is a database, and why is it its own specialty? covers why SQL shows up in backend, data, and analyst reqs alike.

Where does the code physically run?

The code runs on real computers in real buildings, and most companies rent those computers instead of owning them. The rented version is the cloud. The buildings are data centers, warehouse-scale halls of machines run by a handful of providers. AWS, Google Cloud, and Azure are the three largest sellers, and AWS is the name you will see most often on a resume.

Everything underneath the application has a collective name: infrastructure. The machines, the network, the storage, and the tools that manage them. Whole roles exist to run this layer, which is why "infrastructure engineer" and "DevOps" appear on your req list without ever mentioning the product itself.

Two words from this layer come up constantly in hiring conversations. Scaling means keeping a product fast and working as the number of users grows, and a system that "does not scale" works today and would fail at ten times the load. Latency is the delay between a request and its answer, measured in milliseconds, and it is the number engineers argue about most. What is the cloud, and what do AWS and Google actually sell? places both words and the whole rental market around them.

How does one change reach a customer?

A change reaches a customer through a fixed pipeline: write it, save it, propose it, review it, merge it, test it, deploy it. Every professional team runs some version of these steps, and the vocabulary of the steps is the vocabulary of a standup.

The developer works on a branch, a private copy of the code where their work disturbs nobody. They save progress as commits, each one recording who changed what, when, and why. When the work is ready, they open a pull request, which packages the change for teammates to read, comment on, and approve. This review step is where teams catch mistakes and spread knowledge, and most teams require it before anything moves forward. Approved work gets merged into the shared codebase.

Then the change travels through copies of the app called environments. Development is where it gets built. Staging is a private copy used for testing, with no customers on it. Production is the live app real people use, which is why "in production" is said with weight. Deploying means copying the code onto the production machines, and CI/CD is the automation that tests every change and carries it there without a human copying files by hand.

What happens between writing code and shipping a feature? walks this pipeline step by step. It is the spine of the whole course, and the lesson to read first if you only read one.

Why does the work never end?

The work never ends because live software breaks, and because every shortcut taken earlier charges interest later. A bug is behavior that differs from what the software should do, and every codebase of real size has them. Bugs are the normal cost of changing a system with millions of possible states, so teams treat them as weather to be managed rather than as negligence to be punished.

The management takes several forms, and each one is a line on a resume. Automated tests are code that checks the product on every change, and a strong test suite is what lets a team release often with confidence. On-call is a rotation where one engineer carries the pager and answers alerts when live software breaks, including at 3am. An incident is a failure customers can feel, and the written account of what happened afterward is a postmortem.

Then there is the invisible work. Technical debt is the accumulated cost of earlier shortcuts, and it shows up as code that is slow and risky to change. Refactoring repays it: improving the structure of existing code without changing what it does for users. When developers push for time to refactor, they are buying back speed for every future change. Why do bugs happen, and why is software never finished? covers all of it, and it explains why "maintenance" describes most engineering hours at most companies.

How does the team decide what to build next?

Teams decide what to build next through a set of rituals that go by the name Agile: short cycles, frequent releases, and plans that change as the team learns. This is the layer of the job an intake meeting opens with, and its vocabulary is small enough to learn in an afternoon.

Work gets broken into tickets, each one a unit of tracked work with a description and an owner. Tickets that matter but have not started wait in the backlog, an ordered list the team pulls from. The pulling happens in sprints, fixed cycles of one or two weeks that start with a plan and end with a review of what got finished. Each day, the team holds a standup, a short meeting where everyone says what they are working on and what is blocking them.

What is a sprint, and what does Agile mean? covers the rituals, plus a piece of culture worth knowing: many developers roll their eyes at the word Agile, because the same word covers both a light way of working and heavy processes that add meetings without helping. Fluency in this vocabulary signals experience on collaborative product teams. Depth of technical skill comes from their actual work, and later stations of this course, starting with what technology names on a resume mean, teach how to read it.

That is the whole journey. Text in a repository, two halves talking through an API, rented machines underneath, a pipeline carrying each change to production, permanent care keeping it alive, and sprints scheduling all of it. Every lesson in this module deepens one stop, and every word a hiring manager drops now has a place to land.