Developers have their own exclusive language. You’ve heard it, I’m guilty of it— you’re in the middle of a meeting and you’re discussing a task when suddenly the developers turn to each other and say,
“Don’t we have the API key hard coded in that endpoint?”
“No, we’ve deprecated that endpoint. I can show you the diff later. If you don’t have it in your branch, try merging master.”
And you say,
“So… yes? No? Are we good?”
Non-developers are often left out of development-related tangents in conversations because sometimes it’s just easier to talk amongst ourselves and try to translate afterwards. There may also not be extra time in the workplace for transferring knowledge from the development team to the other teams.
But no more.
Whether you’re on a UX team, product management team or support team, in this article you’ll be able to find definitions of a handful of terms I personally hear being thrown around every day. I’ve broken them down by category and provided a moderate rundown of the concepts required for understanding the terms.
Terms: server, client, frontend, backend, API, endpoint, microservice, monolith
Clients And Servers
If you’re working on a team that’s building or selling software, chances are it’s built using client-server architecture design. What this means is that there are two main pieces of software:
- The server which is often a central piece of the whole system
- The client, which is often what the user actually interacts with in order to use the software.
In a web application, the client would be what’s actually in the browser (e.g. a website), and the server would be what the browser is talking to in order to get the information required to display content in the browser. The client is often referred to as the “front end” of the application and the server is referred to as the “back end” of the application.
So, a front-end web developer would be one that works on the user interface of an application in the browser whereas a back-end web developer would work on the server.
API stands for “application programming interface”. In the context of a web application, an API is often the way that browsers or other services communicate with servers. An API is often made up of endpoints: for example, you might send a request to
my-web-app.com/users to get information about the users in your account. Here’s an example from Stripe’s API documentation.
Microservices And Monoliths
There is an ever-growing buzz around microservices in software architecture. This refers to breaking down your application into independently-running “services” that communicate with each other. The opposite of an application built using microservices is called a monolith application: one single, a large application that contains all the code necessary to run.
Without going into too many details, one benefit of microservices is that they can be scaled independently of each other: if you have a messaging functionality that takes a lot of load, you can increase the number of those services, but if it was a monolith application, you’d can’t increase just one part of it without increasing everything.
One downfall of microservices is that the entire system is more complex, and it becomes harder to track down issues without additional tooling, whereas monolith applications are self-contained, and are typically not as hard to debug.
Terms: if-else, exceptions, try-catch, loops, boolean, integer, float, double, string, synchronous, asynchronous, hard code
There are a variety of keywords that come straight from programming languages or are related to actual coding, that end up making their way into conversations between developers.
The following are terms used in programming languages that refer to when to do things and the criteria under which they should happen.
- If-else: you can write code blocks that, given some condition, if it’s true, do one thing (called the if block), and if it’s not, do something else (called the else block)
- Exceptions: when something unexpected happens, you can invoke a special object called an exception that stops the current code and tells the surrounding code what happened (this is usually called “throwing an exception”)
- Try-catch: you can write code blocks that “try” something, and if an exception is thrown inside the “try”, you can “catch” it and do something productive with it
- Loops: as is probably clear from the name, loops are structures that allow code to be repeated rather than having to actually write it multiple times
- Synchronous: when one thing always happens after another in a particular order
- Asynchronous: when one thing may or may not happen in a particular order
There are a variety of data types used in programming languages:
- Boolean: true or false
- Integer: a whole number (e.g. 1, 2, 3)
- Float/Double: a decimal value (e.g. 1.0, 1.2)
- String: a series of text characters (e.g. “this is a string”)
There’s one more term that I hear thrown around that doesn’t really fit well into a category, but I wanted to mention it nonetheless.
Hard coding refers to when a developer writes something in the code explicitly instead of it being derived from something. An example of this would be if a developer at Twitter wrote explicitly in the code that the first tweet in your feed is “test tweet 123” instead of actually fetching your tweets sorted by most recent, then grabbing the text from there. It’s generally a sign of bad practice when used in production, but can be very useful in early prototyping.
Terms: environment, build, deploy, pipeline, continuous integration, continuous deployment, AWS
Once the code leaves the developer’s machine and heads off on its way to production it enters infrastructure-land. Infrastructure usually refers to the various interconnected tools and platforms that support your software.
An environment usually refers to a complete instance of this infrastructure plus the application: a “production environment” would refer to the actual live infrastructure and application, and a “dev environment” would refer to a setup on a developer’s computer that simulates the production environment as closely as possible.
Each time a new version of the application is ready, the actual resulting ready-to-use code of that version is usually referred to as a build. The process of this build getting to the production environment is referred to as deployment or the pipeline.
There are two workflow practices kicking around these days that aim to speed up the pipeline: continuous integration (often abbreviated to “CI”) and continuous deployment (often abbreviated to “CD”). When they appear together, they’re referred to as “CI/CD” (the “/” is not spoken out loud). Continuous integration is the practice of integrating changes that multiple developers make in an automated way. Continuous deployment is the practice of deploying changes (often to production) in an automated way.
A popular infrastructure choice is using a suite of cloud-based services. AWS stands for Amazon Web Services and refers to the suite of services that Amazon offers to development teams. AWS is a popular choice at that moment, highly contended by Google’s Cloud Platform, as well as a number of other vendors.
Languages, Frameworks, Tools
There are so many programming languages, frameworks and tools — hilariously, some agree that it’s difficult to distinguish between the names of tech-related tools and Pokémon. I’ve picked a few that might be thrown around on a web application team.
Lastly, there are databases: SQL stands for “structured query language” and comes in many flavours: MySQL, NoSQL, and PostgreSQL are all good examples. Other databases include MongoDB and Redis.
Data Structures And Design Patterns
Terms: message queue, pub-sub, listeners, queue, list, array, set, map, stack
There are a few common data structures in all programming languages that help manage data — strings, integers, booleans, etc.:
- List (or array): ordered collection
- Set: is an unordered collection, contains no duplicates
- Map (or dictionary): has keys that correspond to values
- Stack: the most recent object added is always the next object removed (eg. a literal stack of chairs)
- Queue: the most recent object added is always the last object removed (eg. a lineup)
One common design pattern these days is the observer pattern. Somewhere in the application, something “publishes” that event occurred — for example, a click. Somewhere else in that application, something had been “subscribed” to that event, or is “listening” for that event, and does something in response to it.
In web development, it’s common to discuss “click listeners” or doing something “on click”. This is an instance of the observer pattern being used.
Terms: unit test, integration test, end-to-end test
Testing is a critical part of the development cycle. There are a few types of tests worth knowing:
- Unit tests: usually the smallest and fastest tests, these tests typically test something in isolation from all other things
- Integration tests: small-to-large tests that typically test multiple components working together
- End-to-end tests (or, E2E tests): large tests that simulate a real user interacting with the application — on a web application, this would be interacting with a browser
Many developers are passionate about high-quality tests, but at the same time, many find it to be more of a chore.
Bits And Bytes
Terms: library, package, dependency, deprecated, script
There are certain terms that refer to specific types of software. A published piece of software that developers and integrate into their code is referred to as a library or a package. Once it’s a part of another project, it’s referred to as one of that project’s dependencies.
If the author of a library releases a new version or a new feature that replaces an old one or is for some reason no longer supporting a version of the feature, it’s referred to as deprecated.
When there is a standalone piece of code that can be run when needed, it’s referred to as a script.
Terms: git, GitHub, commit, branch, master, diff, push, pull, merge, merge conflicts, rebase, pull request, revert
Software projects are large and complex, and with multiple developers working at the same time in the same areas, things can get messy very quickly. Development teams make heavy use of version control to handle this issue. If you’re a UX person and use Abstract, you’re probably pretty familiar with version control.
The most common version control technology is called git and a popular online collaborative tool for teams using git is called GitHub. Each change that a developer makes is called a commit. Developers will work on separate branches — almost like parallel timelines — then merge them into the main branch once they’re finished. The main branch is typically called master. You can pull changes from a branch or push new changes to a branch.
Sometimes when merging, there are merge conflicts, meaning that changes in the two branches being merged overlap in some way, and developers have to resolve these manually.
Typically when a developer wants to merge their changes, they’ll open a pull request (sometimes called a merge request). This is when other developers can look at the diff — the “difference” between their changes and master — and leave review comments.
If something goes wrong, commits can be reverted: a new commit will be made that’s the opposite of the reverted commit, and it will be then merged, effectively undoing the changes.
If you’re not a software developer, congratulations! You could probably talk your way through a developer interview 😉