Software Engineering Jargon Explained: A Beginner’s Guide (Part 1)

This article is written for anyone who works alongside software engineers or applied scientists but does not come from a computer science background — business analysts, product managers, or anyone who has ever sat in a technical meeting and nodded along while understanding very little. This will also help folks taking interview rounds with engineers. It covers fifteen of the most commonly used software engineering terms, organized into three intuitive stages: where code lives, what the building blocks of code actually look like, and how code travels from a developer’s laptop to a live production system. No prior technical knowledge is assumed, and no code is written anywhere in this article. By the end of it, the goal is not to turn anyone into a developer — it is simply to make the next technical conversation a little less intimidating.

Source: Author

Oftentimes, folks like me, with no classroom training on coding, had to have that first work conversation with a software engineer, and for many of us, it seemed like they were talking in Greek and Latin. I still remember the day when I was asked to do a PR review. The naive me, obviously, thought that I was supposed to do a peer review and expected an actual academic paper. I got a link instead, and that’s when I knew about the existence of the word PR or Pull Request. I have long since moved past those days when I struggled with basic concepts like Git repos and Spark clusters.

However, I have met so many people from my circle, especially folks from product analytics or business data science backgrounds, who still face difficulty in having technical conversations with the developers and applied scientists in their company because of the jargon thrown here and there. Since I understand that struggle very well, I thought of writing this article, hoping that it will help at least some of you to understand, at a very high level, what some of the commonly used jargon is actually all about.

The jargon should be first understood in stages. In this article, I will be covering the first three stages. I will write about the rest in subsequent articles.

Where does the code live?

A software engineer will express himself or herself through code. That’s what the application is all about. The primary concepts in this domain are around what code gets written and where the code lives.

1. Application

An application is simply a piece of code that receives an input, applies some logic or rules to it, and generates an output. It can be as simple as a function that adds two numbers, or as complex as the recommendation engine of an e-commerce website — but the core idea is always the same: something goes in, something happens to it, and something comes out.

2. PRD

PRD is short for Product Requirement Document. It is the set of requirements specified by the stakeholders (mainly the product or business teams), and it clearly specifies the business need and the success criteria that are needed for a software solution to be accepted. It’s like the bible for developers when there are meetings with the stakeholder teams.

3. GitHub

Github is the modern equivalent of the Drive folder in iCloud where various versions of the code usually live. It’s a cloud-based solution, and one can literally have snapshots of all versions of the code written by all contributing members of the team in a particular application, which can be tracked and traced using GitHub.

Note: Git and GitHub, often used interchangeably, are not the same thing. Git is the underlying version control system — the technology that tracks every change made to a codebase over time.

4. Repository

A repository, or simply a repo, is essentially a folder that contains the entire codebase of an application, along with a full history of every change ever made to it. GitHub is the most popular cloud-based platform where teams store and share their repos. A developer can download a repo onto their own machine, make changes, and push those changes back — with every change tracked and recorded.

The number of repos involved can vary wildly depending on how complex the application is. Something as simple as an app that adds two numbers might live entirely within a single repo. But a modern software system like a search engine is typically made up of multiple independent functioning units, each often living in its own repo — one for crawling the web, one for ranking results, one for serving the front end, and so on.

The key elements of the code itself

These are some terms usually loosely thrown about in any technical conversation around code writing. Feel free to suggest more terms you have come across and struggled with.

1. Helper Function

A helper function is simply a small, reusable function that handles one specific, repetitive task so that other parts of the code don’t have to repeat themselves. If ten different parts of the codebase all need to convert a date from one format to another, instead of writing that logic ten times, a developer writes it once as a helper function and simply calls it whenever needed.

2. Wrapper

A wrapper function, or simply a wrapper, does exactly what it sounds like — it wraps around an existing function to add something extra to it, without changing the original function itself. Suppose there is a function that calculates a customer’s discount, and now there is a need to add a step that logs every time that function is called for auditing purposes. Instead of going inside the original function and modifying it, one can write a wrapper around it that first does the logging and then calls the original function. The original function stays untouched, and the wrapper handles the extra responsibility.

3. Decorator

A decorator is essentially just a wrapper function with a cleaner, more elegant syntax in Python. Functionally, they are the same idea — adding extra behavior to an existing function without modifying it. The reason decorators come up so often in conversations is that many popular Python frameworks use them heavily, so one will frequently see developers talk about “decorating” a function, which just means they are wrapping it with some additional behavior in that clean Python style.

The Software Development Lifecycle (SDLC)

For anyone working closely with engineering teams, understanding how code travels from a developer’s laptop to a live production system is perhaps one of the most practically useful concepts to have in one’s arsenal — it is the backbone of almost every conversation around timelines, deployments, and why certain changes are not yet “live.”

1. Dev, Stage, and Prod

Before any piece of code reaches its end point — the real users, external customers, or other live software systems — it passes through three distinct environments: development, staging, and production, almost universally referred to as Dev, Stage, and Prod.

In the Dev environment, code is written and tested freely without any risk of disrupting anything in the external production system. It mostly takes place on a developer’s local machine and then gets uploaded to a repo that is not connected to the external systems yet. One can make any number of mistakes here and still not disrupt anything that’s already working. Think of it as an isolated project in a cloud environment.

Once the code is in good shape, it gets promoted to staging — a near-identical replica of the live system where changes are tested under realistic conditions. Only after passing through staging does the code finally land in production, which is the live environment that real users and downstream systems are interacting with. A surprising number of otherwise confusing developer conversations start making immediate sense once this three-stage mental model is understood.

2. Packaging

When code is developed, it typically exists on a developer’s local machine. In that state, it is dependent on that machine’s operating system, existing software versions, and packages like Python, NumPy, etc., to execute successfully. Now, one needs to make sure that this piece of code will run on every machine of every user that might use it — i.e., pass the input and get the output. In order to do that, code from an individual developer’s machine is converted into what is known as a container, and that container carries all of its requirements with it — the operating system, the software dependencies (e.g. python), the packages (e.g. numpy, sklearn) — everything needed to make the code run and execute, regardless of what is or isn’t already installed on the host machine. The process of converting an individual piece of code into a reusable, universal application in this way is called packaging.

3. Build

The end goal of most of the repos in a dev stage is to create something like a downloadable file. In Python, it’s called a .wheel file; in Java, these are called Jar files. It’s very much like those downloadable softwares one double-clicks and an application (like VS Code) gets installed on one’s computer. The idea is to write code and convert it into a downloadable format such that it can run on any machine. The entire process of running all the code inside the repo and then assembling all the individual pieces of code into a single, runnable unit in the last stage is called a build.

4. Artifact

What comes out of a successful build is called an artifact — a concrete, packaged output that represents a specific version of the code at a specific point in time. Think of it as the “finished product” of the build process. Artifacts are stored, versioned, and tracked, which means that if something goes wrong after introducing a new artifact to the end users, a previous artifact can always be retrieved and restored.

5. Lint Check

Whenever a build is initiated, the code goes through a set of automated quality gates known as quality gates and lint checks. The lint check scans the code for syntax errors, formatting issues, and basic inconsistencies — not unlike a grammar checker for writing.

If a lint check fails, then the build does not go through.

The rest of the jargon will come in later versions of my article.

I hope this helps! I tried my best to keep my explanations devoid of complex technical terms as much as possible. Feel free to let me know in the comments if, despite my strict vigilance, some obscure technical term has somehow slipped into any part of this article.

Note from the Author

Here is the link to my latest novel at wattpad. Do check it out if you are into contemporary romance and looking for some distraction in the middle of your technical reading. Search for “Can see choose Happiness?” in wattpad.

https://www.wattpad.com/story/404271156-can-she-choose-happiness