Developer Glossary: 10 Phrases Product Managers Need to Understand

Ever had a conversation with developers about technology and didn't understand what they were saying? Or did you manage to understand the initial keyword barrier but found yourself lost in translation? So many awkward terms they have, don't they? We'll try to demystify some terms and expressions that developers use in their everyday work, so that you can get a better understanding of their mindset (and hopefully argue better with them).

Technology has tremendously evolved down 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 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 I have a task to implement a service. I do 10 commits in my local development environment. While I’m 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 my local environment. To prevent conflicts when we try to merge the two branches, I do a rebase on top of master, so eventually, I replay all the changes on top of 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 login into remote servers in a secure way. Once they are in the 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.

Product Development at PhraseApp

“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 in 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.

I hope this brief developer glossary offered you better insights into what you can expect in communicating with developers and what they instigate when they remark something. After all, you can leverage this knowledge to make better strategic decisions about the risks and costs involved in the future.

4.8 (95%) 20 votes

Best Practices for Successful Localization

Download your FREE EBOOK copy to get:

  • Insider insights from product managers
  • Tips and tricks from localization specialists
  • Concise chapter summaries for easy review
  • Our ultimate checklist to track your progress