Understanding What Software Developers Talk About

Software developers have their own way for explaining the problems they encounter and the intentions behind their solutions. Their jargon is often opaque to their colleagues who don’t write code. In this post, I attempt to illuminate for non-developers the main subject areas that developers discuss in their day-to-day activities without going into too much detail about their vocabulary.


In the realm of websites and web applications, software developers can be divided into two camps: front-end developers and back-end developers. Additionally, the term “full-stack developer” is used by someone who identifies as both.

A front-end developer spends most of their time writing code to run inside a browser. A back-end developer spends most of their time writing code to run inside a server or database, or to write code for The Cloud. More about this later.

In some organizations there may also be quality engineers and system engineers that assist with the production of software. Additionally, an organization may have delivery managers, security engineers, architects, and others who have a responsibility in ensuring the timely release of software to the Internet.

Amongst these roles, particularly the developers, is a language that has common topics, such as:

Yet developers have concerns that are specific to their role.

First, let’s explore topics that developers have in common.

Programming Languages

The foundation of code, a programming language has one primary task: inform other developers what the software design is. The secondary task is to instruct the computer to perform a sequence of actions.

A programming language, like human language, has a grammar and a syntax; it has rules. These are strict rules, and when a rule is broken the programmer will encounter an error like a “syntax error” or “incompatible type error”. These messages are generated by the program when it is converting the language into something the computer can understand.

Often the language contains words that do have some resemblance to English. Words such as for, while, interface and class. There will be other symbols that were originally part of English grammar and punctuation but now have different meanings. The semicolon, for example, can cause arguments to break out between JavaScript programmers. The use of space on lines of code can frustrate Python and Ruby programmers if there is too much or not enough.

Here’s an example of JavaScript code:

const months = ["", "January", "February", "March", "April", "May", "June",
    "July", "August", "September", "October", "November", "December"];

const formatDate = (value) => {
    const [y, m, d] = value.split("-").map(s => parseInt(s));
    return !isNaN(d) ? `${d} ${months[m]} ${y}` : `${months[m]} ${y}`.trim();

Code reviews

Programming, despite the “lone hacker” myth, is a social activity and the code produced by this activity is subject to review. This review usually occurs when it is ready for a “pull request” (see below). This “code review” is generally an opportunity for other programmers, not directly involved with the problem the code is attempting to solve, to ensure the code meets certain standards for:

These standards may be “industry standard”, “company standard”, “team standard” or completely arbitrary.

Choosing a language

How do programmers or developers decide what language they will use to write the software? There are a number of factors, such as:

But it could also be that a language is not chosen because it does not meet this previous list of factors.

Additionally, programmers may not choose a language based on typical human traits such as:

Functional language

When a programming language is considered “functional” there are strict rules for how code uses and moves data through the software. It is a paradigm that is compared against the more dominant “object-oriented” approach where objects are coded to handle changes to, and movement of, data.

Software Libraries

Parts of a library
A software library is composed of reusable elements like the reference section of a library (Source: Wikimedia)

It is apparently a virtue in the software industry that a good developer is a “lazy developer”. A lazy developer will find ways to be economical with their time. Repetition is a bane to all developers and is not a great use of their time. They would rather let the computer do all that menial work.

A lazy developer will also look for code that has already been written that solves their problem. Now this code may not be a 100% fit, but if it’s close enough and “free” (i.e. open source), then that’ll satisfy the lazy developer’s needs. This code is a “software library”. It provides components and functions to help the developer keep moving and focussed on delivery of the feature.

Software libraries are discussed in terms of modules, API (application programmable interface), components, interfaces, documentation, or its actual source code; this is the “developer experience” or DX. While a library doesn’t need to have excellent DX for it to be used, its longevity is defined by how long developers put up with frustration before finding another library or writing their own version. A library considered to have great DX is React, the tool of choice for building UIs by front-end developers.

Choosing a library is also based on the same factors for choosing a programming language.

Software frameworks

When a “framework” is talked about, it is usually at the beginning of a project because they can be one of the most significant pieces of a software project.

There are different scales of frameworks, such as .NET or Angular JS, but for the purposes of this document, you can imagine a framework as a collection of libraries.

Data Exchange and JSON

For the front-end to display information in the browser, it has to communicate its needs with the back-end.

When the browser requests a URL from the back-end it is performing an HTTP request. The back-end server can respond with the expected data or send back an error such as “not found” or “internal server error”. This is the data exchange between the front-end and back-end - a URL is a piece of data (it identifies the resource); a CSS file or an image are types of data the server sends to the front-end.

A URL (uniform resource location) is made up of important parts to help the identification of a resource on a server:

URL breakdown, following HTTP: The Definitive Guide
After HTTP: The Definitive Guide

This data exchange also occurs when a user clicks a link or a button that triggers an HTTP request. Traditionally this means the entire page is updated. However, in modern web application development, this usually results in a partial update to the UI. This type of data exchange relies on JavaScript and a data format known as JSON.

JSON (pronounced as JAY-SON, it means JavaScript Object Notation) is the de-facto format in the software industry because it is text-based, has a simple set of rules, and is human-readable (good for debugging). It is also easy for JavaScript to digest and use in the updates of UIs.

Example JSON:

  "title": "Understanding What Software Developers Talk About",
  "category": "philosophy",
  "tags": [
  "year": 2021

The back-end will send JSON to the front-end in the data exchange usually as a method of moving raw data from the database to the front-end.


When it comes to software, the instruments that a developer relies on for day-to-day productivity are:

This list is not exhaustive and points 1 - 4 will often be a cause for debate amongst developers.


“What does your computer run?” This type of question is usually to start a dialog of comparison between the hardware specs and operating system pros and cons that exist on developers’ computers. The choice of computer is usually mandated by their employer but they may be given the opportunity to use their preferred operating system. Otherwise the developer is stuck with an operating system they end up loathing for various reasons and will describe at length during lunch (or any given opportunity).

Windows, Mac, or Linux? This decision for an operating system is usually based on the same criteria as choosing a programming language if the developer is given the opportunity.

Text editors

Developers need a place to transfer their ideas into code and it is the text editor as the computer application that allows them to do so.

A fancy, bells-and-whistles, text editor is called an Integrated Developer Environment (IDE). An IDE will combine the text-editing facility with other tools that aids the production of software. Visual Studio, IntelliJ, JetBrains WebStorm, and Sublime Text are examples.

Some developers eschew these extra facilities and will use a simpler text editor such as Vim, Emacs or something obscure. These editors exist in the command line terminal.

Developers settle on their editor of choice by how well it suits their intellectual muscles.

Webstorm: an integrated development environment (IDE)
Webstorm: an integrated development environment (IDE)

Command-line terminal

This is a bare-bones window that incorporates a “shell” through which developers can issue commands directly to the operating system. It is this place where developers will use their software tools to aid in the production of software such as run tests, check code style or save the code changes in their version control system (see below).

The terminal window showing the command-line interface of a shell
The terminal window showing the command-line interface of a "shell"

Software instruments

These are small programs that assist developers to verify and validate their code. Back-end and front-end developers have different instruments but in general they fall into these categories:


Probably not as important as the preceding four topics but if my favourite mug goes missing from the kitchen, I will be disappointed, and will begin the search for it in case I did misplace it.

Version Control Systems

It’s standard practice for developers to keep backups of their code in a place that isn’t on their own computers. Usually the backups are stored on a server somewhere else in the world; that server might be owned by an entity like Github or Atlassian’s Bitbucket. This process of protecting source code is called “version control”.

The version control tool that is pretty much the industry standard these days is called “Git”. Git allows developers to work on different versions of a code base, called branches or forks, that do not cause disruption to the code that is working in production. These branches, when stored in Github or Bitbucket, are kept separate to the main or “master” branch (version) of the code that is used in production.

Git also allows developers to fix up their mistakes, track who wrote what line of code, and provide a history of all the changes that have occurred.

The user profile page on Github for Enterprise
The user profile page on Github for Enterprise

When developers are finished with the work on a feature, and it is ready to be “merged” into the main part of the code, the developers will “create a pull request”. A pull request gives the authors an opportunity to explain why the changes were made. A pull request also gives other developers a chance to review the changes, also known as a “code review”. If the changes pass the review, then the code can be merged into the “master” or “main” branch. If not, then the authors have to address the feedback of the reviewers and when ready, request another review of the code to hopefully bring the pull request closer to merging.

Build Systems

“The build is broken”. A phrase, when spoken, is in a tone of stark seriousness. It may also be referred to in an ironic manner: “X broke the build this morning!”.

But what’s happened? What is “The Build”?

In fact, the build refers to a system that covers these concepts:

Much like programming languages, developers make their choices for each of the components that a team uses for these processes.

Build tools

These take all the text files containing code and translate (“compile”) these into artefacts that the computer can understand. These artefacts are then used by the web server for back-end code or even in the browser (e.g. TypeScript converted to JavaScript).

Continuous integration

Continuous Integration (CI) is the process where code is taken from its repository, built, tested, and then packaged for deployment.

These are machines, often working on an in-house server or in The Cloud, that operate when a pull request has occurred. When the pull request is successfully merged, Github or Bitbucket will send the code to these CI machines. If all the operations do not experience an error, artefacts are generated that will be deployed into production.

It is “continuous” in the sense that any successful change of code will trigger this process and no human intervenes.

Typical CI environments are Jenkins, Hudson, Buildkite, Bitbucket, TeamCity and Travis CI.

Buildkite, a continuous integration and continuous deployment tool. Here this image shows successful builds
Buildkite, a continuous integration and continuous deployment tool. Here this image shows successful builds

Continuous Deployment

Like CI, but it adds the operation for setting up the production environment and placing the artefacts generated by CI into that environment.

The production environment may be hosted Amazon Web Services (AWS); Microsoft Azure; Google Cloud Platform (GCP); Heroku; Netlify; or something else that is in The Cloud.


This area of software production is the purview of developer operations, referred to as “DevOps”. In the past this was the domain of specialist engineers such as the Systems Engineer or Site/Systems Reliability Engineer (SRE). In recent times, it has become a responsibility for developers. In fact, in some organizations, it is part of Team Managed Infrastructure (TMI) and system engineers provide assistance when needed.

Genre of Developer

Let’s cover the types of developer one finds in teams who produce software.

Back-end developer

Back-end developer figure

What they do:
Writes code for a web server, application server, system infrastructure, cloud infrastructure, or a database.

What they talk about:
The following is a list of topics specific to back-end developers:

Topic Category Extra comments
ASP.NET Software Framework Microsoft
.NET Software Framework Microsoft
C# Programming Language Microsoft
SQL query Programming Language The language of most databases to retrieve or manipulate data
Database performance System How fast a database can respond to requests for data or how quick it can store data changes
REST Web Services / API Conceptual framework for organizing data and resources
Java Programming Language Oracle / open source
Spring Web Services / API Software framework for building websites, REST programs or other APIs
Ruby on Rails Software Framework / API Popular framework, using the Ruby programming language, for building websites and web APIs
Python Programming Language Popular with data scientists and system engineers due to its simple yet expressive syntax
Scala Programming Language Popular with programmers who don’t like Java but like functional languages
Node System Instrument A tool that allows developers fond of JavaScript to write software for the back-end

Back-end developers may also talk about functional programming - where “monad”, “functor”, “optional”, “algebraic data type”, “Scala” or “Haskell” may be heard - as their preferred style of writing code. This does lead into the discussion about the paradigms of programming which is out of scope for this document.

Front-end developer

Front-end developer figure

What they do:
Writes code to be downloaded by a web browser for display with a user interface.

What they talk about:
The following is a list of topics specific to front-end developers:

Topic Category Extra comments
HTML Programming Language Defines the structure of a web page
CSS Programming Language Defines the style for a web page
JavaScript Programming Language Adds behaviour and interaction to a web page
React Software Library Combines HTML and JavaScript to define components for the UI
React Hooks Software Concept Part of React, a paradigm for organizing code within components
GraphQL Software Concept A specification for defining how data is exchanged between the front-end and back-end. Its strength is flexibility and uses JSON
Jest Software Library For writing and running unit tests and is used mostly in conjunction with React

Along with technical expertise, a front-end developer of high calibre is conversant with UI / UX / product principles and can interpret designs without explicit guidance.

System engineers

These people advocate for secure and healthy systems. Referred above, they are responsible for the many pieces of the systems that are running in production or running on “staging” (the test environment).

Full-stack or “generalist” developers

This role describes someone who is comfortable writing code for the front-end or the back-end. Someone who can, for example, switch between JavaScript, C# and SQL effortlessly.

When companies are looking for ways to reduce costs, they will expect “specialist” developers to take on more “generalist” responsibilities.


While this post doesn’t delve deeply into what concerns software developers, I hope I have shone a light for you onto their subjects and cleared some of the mystery.

Communication is a crucial ingredient in teams that thrive. Thus it is important to understand the problems and intent of team members to allow a high level of cooperation and confidence.

This page posted under the category: philosophy