It’s sometimes hard to understand what IT people are talking about because of all the technical terms they throw around. So I compiled this little dictionary of IT terms for beginners!
It may seem silly, but communication problems are all too common in IT teams. Programmers and other computer science professionals use a technical language of their own that may not be too accessible to non-technical people. But effective communication is one of the keys to survival in the industry, so it’s definitely worth understanding what those terms mean so you’re on the same page as everyone else.
Let’s demystify some of the most common IT terms in the industry.
Common IT Terms and Their Definitions
Bug – An error or flaw in your code that causes unexpected behavior in the associated program. My favorite story is one that most computer scientists are familiar with. In the late 1940s at Harvard University, an error was detected in an early electromechanical computer, Mark II. One of the operators of Grace Hopper's team found a real moth trapped inside the computer that happened to be causing the machine to malfunction. The moth was taped to a log book with a note that read, “First actual case of bug being found.” To my knowledge, this is the earliest usage of the term “bug” in the context of computer science.
Code review – A process in which one developer (preferable one with more experience) reviews code written by another. It's a common practice in many software companies, as it helps avoid bugs and ensure coding consistency. You may hear people refer to this as CR.
Commit – The action of adding the latest changes to source code (or the addition of new files) to a repository. Often used as a part of one of the basic Git commands, “git commit.” More on Git and version control later in this article!
Daily (stand-up) – A daily progress-tracking meeting in a Scrum team, where all the team members gather to talk about the the tasks they’re currently working on and any progress they’ve made. Often, some of the members are working remotely, so a team may host video calls and place the laptop with the virtual co-worker somewhere within sight of the whole team. As the name suggests, the attendees participate while standing. This helps to keep the meetings short.
Deployment – A term used sometimes interchangeably with release, which causes confusion because they have slightly different meanings. Deployment is the installation and configuration of a software version onto a target system (production environment). But before we can install and configure a new version of our software on the production environment (which is visible to all end users), we first install it on two testing environments (test and staging) to be sure that everything goes fine. End users have no access to these environments—they're for testing purposes only. These environments look similar to the production environment, especially the staging, which often has the same test data (all the content of the website or the data in the application) as the production. For more information, check out the definition of release towards the end of this article.
Debugging – The process of detecting and removing bugs from a piece of software. Both developers and quality assurance teams engage in this practice regularly to ensure that code is working as intended. They employ methods like automated and manual tests, as well as unit tests. My personal favorite type of debugging is widely applied and very efficient, and it’s also got a humorous name: rubber duck debugging. Simply put, many developers keep a rubber duck on their desk—yes, an actual rubber duck. When they run across a problem in their code that they can’t figure out, they start explaining their code out loud to the duck—who is, by the way, an excellent listener. This process is very effective and helps developers iron out any flaws in their logic or identify code that isn’t doing what it’s supposed to be doing. In the unlikely event that you don’t have a proper rubber duck, you can ask your co-worker to serve as a substitute!
Feature – A functionality in a piece of software that the client has requested. Sometimes, when developers accidentally introduce bugs in their software, they jokingly refer to them as “unexpected features.”
Git – The most popular version control system, Git is software that’s used for managing changes to code when developing big applications (though it’s still quite useful even with small projects) or whenever you’re working on a coding project with a team. Though it’s often used by programmers, Git is also very useful for quality assurance specialists and software architects. Some of the most frequently used Git commands are “git status”, “git add”, “git commit,” and “git push.” But depending on the situation, you may only need “git commit” and “git push.” In fact, based on these two commands, there’s a list of special safety instructions for programmers in case of a fire—perhaps you’ve seen it on some mugs, T-shirts, or memes: “1. git commit 2. git push 3. leave the building.”
IDE – Acronym standing for Integrated Development Environment, a complex application designed to allow programmers to write code and create applications more efficiently. Some of the most popular ones are IntelliJ IDEA, Webstorm, PyCharm, Spyder, and Visual Studio. An IDE usually consists of a source code editor, build automation tools, and a debugger. What many programmers appreciate is the intelligent code completion and numerous keyboard shortcuts that come with an IDE, as these features make writing code much faster. Often, IDEs are integrated with version control systems like Git to allow you to track changes to your files from within the IDE. Some of them are designed for particular programming languages, while others (like Visual Studio Code) are more universal. But every software developer has their own favorite IDE. Which one’s yours?
Jira – One of the most popular issue-tracking applications in the IT industry. Over time, it’s grown from a simple bug tracker into a complex software managing platform for agile projects, with customizable workflows and agile boards. Jira supports integration with many other widely used developers tools, which makes work a lot easier. Fun fact! Rumor has it that the name of the software is a truncation of Gojira, the Japanese word for Godzilla.
Library – A pre-written collection of code that can be added by a software developer to a program to achieve some specific functionality or automate a process. Without libraries and linking, you’d have to repeatedly copy-paste source code into your project directory, or re-write the code yourself. There are libraries for most (or all) the programming languages. But when I started to learn how to code, I remember how amazed I was by the number of libraries for Python. There’s a Python library for just about anything you can think of!
Log file – A simple text file where events that occur in an operating system or other software are recorded in real time. It’s a tool used by programmers in the process of debugging because it helps to find an error easily. Often, errors are listed in the log files and indicate the file name and even the line number where something went wrong.
Push – The action of publishing commits from the repository on your machine (known as a local repository, or local “repo”) to a remote repository (one hosted on the web, like on GitHub). It’s one of the most common Git keywords, and it’s used in the basic command “git push.”
Scrum – A very popular framework for agile development, mostly used for software development. A Scrum team breaks its work into iterations called sprints, and every sprint starts with a planning meeting and ends with review and retrospective meetings. All the team members attend these events and participate in planning work. Any team member can suggest improvements and changes to the process during retrospective meetings. It may seem that you need to spend a lot of time on these meeting and that this distracts you from real coding work, but it also allows you to have a genuine impact on the process of planning and makes you feel like you’re an important member of the team.
Sprint – An iteration of development for a fixed period of time (usually 2–4 weeks) within the Scrum framework. During a sprint, the team delivers a piece of software (i.e., a new functionality in the application) arranged with the client. Often, there’s a release after a sprint, or after a few sprints if the delivered functionality is complex.
Source code – The collection of code that’s used to build an application. It contains of all the declarations, instructions, functions, loops, and other statements and “tells” the program how to function. Usually, it’s the collection of many files (sometimes even thousands of files!) written in more than one programming language. A good practice is to add comments to source code to make it more maintainable and easier to understand for other developers.
Story points – Also a term related to the Scrum framework, a story point is a relative measure of the size of a unit of work (a “story”). This one was really confusing for me at the beginning, and I found it hard to use story points instead of hours or days when evaluating the difficulty level of a given task. It didn’t help that most of my team members used its acronym, SP. We really love acronyms here in IT.
Release – Usually, this refers to a new version of the application. It very often is, but does not necessarily need to be, customer centric. The moments before the release are always tense because everyone tries to finish as many tasks as possible without causing a catastrophe in the production environment. That’s why some companies host “no-release Fridays” to make it less stressful for the team and avoid potential trainwrecks just before weekend.
Repository – A data structure where all necessary files for a project or application are stored, as well as the history of all changes made to those files. Repositories make it easy for you to track all changes in your development in case you ever need or want to restore an older version of your code.
Many beginners feel a bit lost when entering the IT industry and trying to communicate with other team members. Don't worry if you feel like that too! And don't hesitate to ask for clarification. At the very beginning of my first coding job, I swear there were some situations when my colleagues were explaining something to me, and the only words I could understand were the conjunctions!
Familiarizing yourself with technical lingo takes a bit of work, but it’s doable. The first step requires having the courage to admit you don’t know these technical terms and seeking clarification. But trust me: Your team will appreciate you behind honest instead of pretending to know something you don’t!
Are there any terms that you found difficult to understand at the beginning of your IT experience? Share them in the comments—let's develop this dictionary together!