Ever been in a (SCRUM) meeting or standup and you didn’t understand a word the developer was saying? Wouldn’t it be nice if you understood some words without learning to code? What if I could teach you some basics within 5 minutes? Let’s do just that.

Let’s face it, it’s hard to keep up with a developer in a meeting when you’re non-technical. Especially in tech companies meetings can become very technical very fast.

This is where technical product managers have the advantage from a non-technical one. A tech product manager is usually someone with a technical background (= can code and/or has a computer science degree). The main difference is that these type of PM”s can basically talk like a developer and understand everything. Making it easier for them to work in high-tech environment and manage technical decision making.

Why it’s important to understand some of the tech

• Tech is a big part of product. Which means it’s also a big part of decision making and can have a big effect when you get it wrong.
• Better communication, faster delivery. If you understand developers better and vice-versa, it makes decision making easier. It takes less time and delegating technical ownership smoother. Resulting in faster deliveries as the total communication overhead comes down.
• It acts as a fail-safe. You can have the smartest developers but they don’t have the entire picture (like what’s happening on the business side). You need to be able to translate between different worlds to know if all adds up and be able to intercept solutions that don’t translate into any customer value.
• It gains respect. Let’s be honest: developers can be quite stubborn f*cks. They open up more easily to people who have gained their respect by mastering the art of tech.

So here is the bottom line:

I didn’t put this article together to suddenly transform you into a full blown tech product manager or a developer. But these are lines you probably hear often in your SCRUM meetings.

If you’re working with developers without having technical background yourself, it can add more context and give you a better understanding of what a developer is trying to tell you.

Just read this list a few times and try to remember when these words pass you in conversation. After a few times, you’ll notice the words will make sense.

The banner is the line followed by the translation in normal human terms. I also put some notes below some of the translations, adding slightly more context from a product manager / product owner perspective.

Let’s dive in:

---

Translation Repository (aka. Repo). A digital bucket where all the code will be stored by all developers. No rocket science here, just like a file directory on a computer.

---

---

Translation That bucket with code (= repo) needs to be hosted somewhere so we’ve put it on Github. The most popular platform for developer code management. Based on Git, which is a version control system for code or file management. Almost every developer uses it.

---

Note: You should only get access as a PM to any repo when absolutely needed. There is no need to wonder around the code just for a sense of control. It will only annoy your developers.

---

Translation I’ve put my code in the main part of the repository called master. The master is where all the finished/approved code ends up. It’s the actual code that your users will touch and technically can be defined as your product. Simply put: the master is where your money is.

---

Note: Putting code straight in the master is ONLY OK when it’s a small project. For any larger projects, you should never hear this line. A developer should never touch the master directly.

If you do hear this in a large project, I’m guessing your developer doesn’t clearly understand how branching works and strategies behind it. That should be an alarm bell.

---

Translation Current code of this feature/function/library isn’t meeting requirements or quality anymore and it’s on the path of being trouble. I need to rewrite parts of the code.

---

Note: Nobody likes this but it’s an essential part of development. There is a positive side to this: your team has some awareness of something called technical debt.

And here we’ve got the real money maker: deploy!

---

Translation I’ve put new code from the repository on the server(s). Usually it first goes to acceptance/testing servers for approval of the PM. When approved, it’s shipped to the production servers where your customers can finally use it.

---

Note: This is the line you want to hear (a lot). Deploying means progress!

---

Translation I’m separating my code from the main code to work on a specific story, feature or task. This way the other developers aren’t bothered with my work until it’s ready.

---

Note: This is normal practice. If a developer starts working on code, he needs to separate it from the others and only put it together when finished.

---

Translation The separated code (branch) I worked on can now be put together with the rest of the code.

---

Note: Merging is normal practice. The process basically looks like a car factory: Someone (developer) will be assigned to make the wheel. He will make the wheel in a separate part of the factory (branch). Once he’s done, he’ll take the wheel to the assembly line where puts it on the car (main code). Assembling parts together is what we call merging.

---

Translation Rebasing is a different form of merging. It does the same job: putting code together. The method is very different though and more complex. It’s only used in specific circumstances.

---

Note: Rebasing should almost never happen if it’s a project within a company. Should only be done by experienced developers because you can damage the operation when you get it wrong.

---

Translation I passed the code I worked on to one of the other developers. He or she needs to check my code to make sure I didn’t miss anything, intercept mistakes and check if it meets a certain degree of quality.

---

Note: Code reviews are done by team members who are assigned to do these reviews. Usually done by senior or lead developer(s).

---

Translation  Pull-request (aka. Merge Request). I’ve created some code or made changes to existing code. Before we put my code together with the main code, it needs to be checked. I’ve sent you a request that shows my code and I need you to review it.

---

Note: Great practice for code reviews. The extra upside is that you can review how technical decisions are made and improve them. When things go wrong, you can review the conversation and backtrack where possible mistakes were made (to learn and improve).

If you lead a team with mostly developers, this also can be a great source for your Retrospective. To learn from those discussions in operation and focus on improving technical decision making. 

Example of what a pull-request looks like with some details explained (click for full view):

---

Translation I want to sit next to another developer of my team and tackle this code challenge together with the primary goal of learning from each others problem solving skills and coding techniques.

---

Note: This should be encouraged once in a while. It’s good training for developers to see how others tackle a problem and develop these skills. I recommend this practice if you haven’t tried it in your development team. Only assign stories to pair programming that are actually complex.

---

Translation The percentage of code that has a testing method applied to it that will run before deployment.  In most cases developers are referring to a specific form of testing:

1. Backend developers will mostly be referring to unit-testing (ex. testing system functions by running them).
2. Frontend developers will mostly be referring to end-to-end testing (ex. testing all buttons on a page and checking if all technical actions are correct).

---

Note: If you never heard your developer talk about this, you need to step up your testing game. Testing methods like these are crucial to any product development operation. The percentage is never 100%. Average large project will be between 30% – 60%. Very critical systems will go 80% and up.

---

Translation One of the developers put code in the repository for deployment which can’t be there. The piece(s) of code are not ready and can break the application for customers. It needs to be removed manually before deploying. This process is referred to as cherry picking.

---

Note: You shouldn’t hear this too often, not normal practice. This mostly happens when a developer expects to deploy his code but something critical came in that needs immediate deployment (like a critical bug fix).

---

Translation I deployed code for a feature which shouldn’t be active for users (yet). Flagging means it’s disabled on code level but actually is deployed. This way you don’t have to delay a deployment and prevent users touching features they shouldn’t be seeing.

---

Note: You only do this when that feature is actually completed. This should not happen too often. It means you’re delivering ahead of schedule and are only waiting for the agreed rollout date. If you’re that speedy, you might wanna upgrade your operation to something more like Continuous Deployment.

Let’s go for some bonus points:

---

Translation I’ve put everything that is needed to run our application in a virtual box and put it on a server for testing or production use.

---

Note: You’ll hear this a lot when you’re in a project with bigger scale.  The name Docker will probably also be heard, which is a platform that enables creating and running such virtual boxes called containers.

The reason why developers use these containers: scaling and flexibility.  If you know that you’re going to need more capacity or different infrastructure resources because of rapid growth longer term,  you’ll need to be able adapt your application and infrastructure in record time without being bothered with a lot of scaling issues. 

So this is how that virtual box aka. container fixes that issue…

They put everything in a virtual box which can run on any infrastructure. The infrastructure doesn’t really matter anymore, the box adapts to it by its technical nature. These virtual boxes can be replicated infinitely and put themselves on any (cloud) server in minutes. Fully automated. Pretty cool, right?

---

Translation I’ve made sure files with sensitive (plain passwords, keys, private data) or useless data are excluded from the repository by putting them in the gitignore file.

---

Note: You will rarely hear this. It’s important detail to be aware of. When a developer puts something in any repository, this .gitignore file will be checked first. The developer needs to put instructions in the file to tell which data should be ignored and can’t go in the repository. This way, things like passwords or customer data doesn’t end up in public code and can save you from public embarrassment.

---

Translation I’ll deploy the new code without users noticing downtime. Every server (one at a time) will be instructed to not accept any more users and only handle current users sessions.

Once all those current users are gone:

1. the server will pull itself out-of-operation.
2. new code will be deployed on it.
3. It will run tests and self-checks.
4. Once they all pass, it will put itself back in operation.

---

Note: Now this one is just to make you look cool and make developers think you transformed in some Kung Fu Panda PM 🙂

---

Translation First the setup of our new application, I’ve setup a quick initial code structure to prevent writing basic code myself and shorten the time/resources needed to deliver an initial version (aka. Minimum Viable Product or MVP) of the application.

---

Note: You will only hear this when you’re building a new application. Scaffolding is a technique used in some popular code frameworks (mostly in one called Ruby on Rails) and it’s to prevent writing code which that is too basic to be bothered with. The code is generated by the framework and not written by the developer.

For example: I need to be able to create/edit/delete a user in my application. These are very basic functionalities. With scaffolding, I generate the code structure to take care of that.

This code structure is only used at the beginning of an application. Once the application continues to develop, developers will replace it with more advanced code. This mostly happens when the application gets features which are not supported by this structure. 

---

Translation I’ve replaced a function or technical element which cannot be used from the time the deprecation is deployed. In most cases, it is replaced with a new function that will handle the previous function’s duty.

---

Note: You’ll mostly hear this when talking about internal or external API’s. Because these have dependencies (= developers or other API’s being dependent on it), it should be announced in advance to give the other parties some time to adjust their code as well to prevent communication breaking between systems.

---

Translation A pipeline in development is actually a set of processes that are tied together. It’s consists of two main components: Continuous Integration aka. CI (= the build and testing stages of a software deployment) and Continuous Deployment aka. CD (= code changes are automatically tested, build and prepared for production delivery).

A visual overview of what a pipeline really looks like:

The goal of a pipeline is to automate your software delivery process and make sure it’s done with a high level of quality and consistency without adding extra development overhead. Usually specific developers within a DevOps team are responsible for the pipeline due to the fact that setting up and maintaining a pipeline requires specific knowledge not all developers with a team will have.

---

Understanding your developer(s) is important

Hopefully some of the list resonated with you and will help you create some more understanding between you and your developers. Trying to improve understanding of the tech can help your product development in so many ways.

I’ll update this list overtime with more terms that could help you out.

Have any suggestions to add to this list? Don’t hesitate to send me a message or put it in the comments below.