Developer Glossary: Top 10 Phrases You Should Know

Ever had a conversation with developers and didn’t get them? Our developer glossary will demystify 10 common tech phrases for your better understanding.

Technology has tremendously evolved over the years. People working with it have naturally created their very own interpretation of the environment. In an attempt to model their problems, they develop abstractions and tools to help them tackle complexity, so talking with software people aka developers often involves learning a new language full of esotericism. To better understand what developers mean when talking to you, we’ve compiled a short developer glossary of the most common terms they mention that will save you the effort of doing it yourself. Here is an all-in-one technical dictionary of common phrases that developers use suited for managers.

“I need to refactor X”

When a developer mentions refactoring or restructuring, he usually wants to say he is unhappy with the way some pieces of code are written, which means he would need more time to adjust them. In that case, you have to inform him to put his work hours on a ticket with those specific cases that he refactored.

“I’ve created a pull request”

A pull request is a request for a change in a change management system. The developer has finished with the ticket that he had been working on, so he creates a request to merge his changes with the central code base. In that event, you need to advise him to make sure that the code needs to be thoroughly reviewed before merging.

“I need to rebase my commits to master”

A rebase is a process that transfers all the changes in a commit history of a branch after a particular point. For example, let’s say we have a task to implement a service. We do 10 commits in our local development environment. While we’re doing that, the master branch—the central branch that all developers contribute to—is also updated and contains some commits that are not present in our local environment. To prevent conflicts when we try to merge the two branches, we do a rebase on top of the master, so eventually, I replay all the changes on top of the master.

“I have stashed my changes”

A developer has written some code but saved it locally without committing to the codebase. This is usually because the code is very experimental and not working yet.

“I need to SSH into the container”

SSH is a way that developers can log in to remote servers in a secure way. Once they are in, they can issue remote commands and configure the servers.
A container on the other hand is a way we can package a server into a logical namespace that we can move around easier. We can even allow multiple containers in a server.
In that case, the developer meant that he needs to open a secure terminal in a container to perform some work.

“We need to KISS”

Not literally kissing, but “we need to keep it simple, stupid.” This is a common expression between developers who want to have the simplest solution to a problem – they don’t want to make tricky things even trickier.

“We need to use JSON”

JSON is a way to describe information that is human-readable and machine-portable. It’s typically a text string with some keys and values. For example, the following text describes a person: “JSON is the most popular format for transferring data and a really safe one.”

“Let’s fork it”

No, we don’t mean we need to pierce something with a fork. Forking is the process of cloning a code repository into our own namespace. This is typically done on a platform like GitHub. There, a developer can fork a different repository into his own list of projects to make contributions to projects easier.

“We have a planning poker session”

Planning poker does include cards but not the real ones! The cards played in this session are with numbers indicating how much estimated time we need to use to complete a task. Everyone contributes with a number, and the average is noted down. Planning pokers are useful in the project planning phase as they give some good insights into the amount of engineering effort needed to satisfy the requirements of a feature.

“We need a new CI/CD pipeline”

CI is different from CD. A CI stands for Continuous Integration, a process where every time a developer creates a pull request or updates a branch, there is a service in the development server that tries to deploy the new application and verify that it works. This way, we can detect problems earlier. CD, on the other hand, stands for Continuous Deployment, which goes one step further. There is a phase in which every commit that passes a specific set of tests the changes are deployed automatically to the production environment. A pipeline is a different word for describing a set of steps to do a complete CI and CD to production. Those terms are used to add automation in the process of delivering software, which is always good to have.

A few last words

Learning some of the developer’s regularly used expressions could be of great help when communicating with tech people. Most of their jargon originates from the tooling they use. For example, Git, Linux, and Agile Methodologies. What you read here is under no circumstances a complete list as new technologies arise, and new keywords are invented. As a manager, you can attend tech conferences and meetups to better understand the terminology by conversing with developers and other fellow associates to be on top of new trends.
We hope this brief developer glossary offered you a strong insight into what you can expect in communicating with developers and what they instigate when they remark on something. After all, you can leverage this knowledge to make better strategic decisions about the risks and costs involved in the future.

Keep exploring

Photo-realistic sheet music featuring developer-style translation code in place of musical notes. The staff lines show snippets like t('auth.signin.button') and JSON structures, combining the aesthetics of musical notation with programming syntax to illustrate the idea of “composable localization.”

Blog post

Localization as code: a composable approach to localization

Why is localization still a manual, disconnected process in a world where everything else is already “as code”? Learn how a composable, developer-friendly approach brings localization into your CI/CD pipeline, with automation, observability, and Git-based workflows built in.

A woman in a light sweater sits in a home office, focused on her laptop, representing a developer or content manager working on WordPress localization tasks in a calm, professional environment.

Blog post

How to build a scalable WordPress i18n workflow

WordPress powers the web, but translating it well takes more than plugins. Discover how to build a scalable localization workflow using gettext, best practices, and the Phrase plugin.

Blog post

Localizing Unity games with the official Phrase plugin

Want to localize your Unity game without the CSV chaos? Discover how the official Phrase Strings Unity plugin simplifies your game’s localization workflow—from string table setup to pulling translations directly into your project. Whether you’re building for German, Serbian, or beyond, this guide shows how to get started fast and localize like a pro.

Blog post

Internationalization beyond code: A developer’s guide to real-world language challenges

Discover how language affects your UI. From text expansion to pluralization, this guide explores key i18n pitfalls and best practices for modern web developers.

A digital artwork featuring the Astro.js logo in bold yellow and purple tones, floating above Earth's horizon with a stunning cosmic nebula in the background. The vibrant space setting symbolizes the global and scalable nature of Astro’s localization capabilities, reinforcing the article’s focus on internationalization in web development.

Blog post

Astro.js localization part 2: dynamic content localization

Learn how to localize your Astro.js website with static and dynamic content translation. Explore Astro’s built-in i18n features and Paraglide for handling UI elements, navigation, and dynamic text seamlessly.