What do the technology names on a resume actually mean?

What do the technology names on a resume actually mean?

Every technology name on a resume is one of five kinds of thing: a programming language, a framework, a tool, a platform, or a practice. The kind matters more than the name. Once you know which kind a word is, you know what question it answers about the person, what it can be compared to, and how much weight it carries.

The last module walked through how software gets built: the layers of an application, the path from a laptop to a customer, and the rhythm of a working team. This module puts that picture to work on the words themselves. A resume line reading "Python, React, AWS, Kubernetes, Docker, CI/CD" looks like six parallel skills. It is one name from five different categories plus a repeat, and reading it that way is the difference between a list you can evaluate and a list you have to take on faith.

The three lessons in this module are the sorting machine. The shelves sorts the big names one by one. What is a stack shows how one pick per shelf becomes a product. What transfers covers the question underneath every close-but-different resume: which skills carry across names. This guide is the map of all three.

What kinds of thing are there?

There are five shelves, and every technology word you will meet goes on one of them.

Languages. A programming language is what code is written in. Python, Java, JavaScript, Go, and Rust are languages. The previous module covered why nobody writes it all from scratch: a language is the raw material, and most of what gets built on top comes ready-made.

Frameworks and libraries. A framework is a body of prewritten code, built in a specific language, that handles the repetitive parts of an application. React is a framework for building what users see, written in JavaScript. Django plays a similar role for Python. A framework always implies its language, which is why "React developer" tells you the person writes JavaScript.

Tools. A tool is software a developer works in while building. An editor such as VS Code is a tool, and so is Docker. Tools shape how someone works day to day, and they stay behind when the product ships.

Platforms. A platform is a place other software runs, together with the services it provides. AWS and the other clouds from the cloud lesson are platforms. So is Kubernetes, which runs and manages many copies of an application across many machines.

Practices. A practice is a way of working rather than a product. CI/CD and agile are practices. Two teams can share a practice while using entirely different products to carry it out, so a practice on a resume describes habits rather than a specific technology.

The sorting rule follows directly: two names can only be compared when they sit on the same shelf at the same layer. Python and Java can be weighed against each other. Python and AWS answer different questions, so a req that treats them as interchangeable line items is comparing a material to a location. The shelves works through a real fifteen-item list this way, name by name.

What is a stack?

A tech stack is the set of technologies a product is built from, with one main choice at each layer: a language, a framework, a database, and a place to run it. The word "stack" is literal. The layers from frontend, backend, and the API sit on top of one another, and a stack names the pick at each level.

This turns a stack sentence into something you can read word by word. When a hiring manager says the stack is "React, Node, Postgres on AWS", they have told you four things in four words: what the frontend is built with, what runs the backend, where the data lives in Postgres, and which cloud the whole thing runs on. Nothing in the sentence is mysterious once each word is on its shelf.

Reading stacks this way also reveals what a req actually calls for. A posting that lists two frontend frameworks, three databases, and two clouds is describing several layers of one product, and very few individual developers own every layer at depth. What is a stack covers how teams divide those layers, what full-stack means in practice, and why the same stack sentence describes a different job at a five-person company than at a five-hundred-person one.

Which skills transfer between technologies?

Skill transfers along layers far more than along names. A backend developer who has spent five years in Java learns Go in weeks, because the durable skills were never the Java syntax. They were designing services, debugging systems under load, and judging tradeoffs, and all of that carries. The same holds one shelf over: someone strong in AWS learns Google Cloud quickly, because the concepts of regions, scaling, and managed services are shared and only the product names change.

Transfers across layers take longer. A frontend developer moving into infrastructure work is changing what they think about all day, from interfaces and user behavior to machines, networks, and reliability. The move is common and it succeeds regularly, and it is measured in months of ramp rather than weeks.

This is the single highest-leverage fact in the module, because transferable skills are where close-but-different candidates live. A skills list is a record of where someone has been. The layer they worked at is the better predictor of where they can go. What transfers maps the short moves and the long ones in detail, language by language and layer by layer.

What is the difference between a tool and a framework?

A tool is software a developer works in, and a framework is software that ships inside the product. This one distinction sorts more resume confusion than any other, so it gets its own section.

When a company ships a product built with React, React's code goes with it. Every customer who opens the app is running React, which is why a framework choice is a long-term commitment: it becomes part of the product and stays there for years. An editor works the other way. A developer writes code in VS Code or Cursor all day, and no trace of the editor reaches the customer. Docker sits on the tool shelf for the same reason: it packages software during building and shipping, and the product would be the same product built with different tooling.

The distinction tells you what each name means as evidence. A framework on a resume speaks to what the person has built and how deep that layer of experience runs. A tool speaks to how they work. Both are real information with different weight, which is why "React, five years" and "VS Code, five years" are very different lines even though both are software the person used daily. The shelves applies this test to every ambiguous name in the sort.

Where do the AI words fit?

The AI names sort onto the same five shelves, and sorting them is the fastest way to make the next station of this path easy. GPT, Claude, and Gemini are models: the AI systems themselves, the things that read and write text. OpenAI, Anthropic, and Google are the companies that make them, the way Oracle is a company and Java is the thing it stewards. Cursor and GitHub Copilot are tools: software a developer works in, which is why Cursor sits on the tool shelf next to the editor rather than next to React.

The sorting rule does the same work here that it does everywhere else. "Uses Claude in Cursor" describes a developer's tooling. "Built a product on the GPT API" describes what shipped inside a product, which is framework-shelf territory. Those are different claims about different shelves, and a resume that lists "AI" as one word is compressing them together. What the AI words mean opens the next station by giving each of these names its full treatment.

That is the whole machine. Five shelves, one pick per shelf makes a stack, and skill moves along the shelves rather than along the names. Every wall of nouns you meet from here on is a sorting exercise, and the three lessons in this module are the practice.