As a new developer, technical jargon can be overwhelming, especially during meetings or interviews.
This article provides actionable tactics on how to learn technical jargon and how to handle these delicate situations.
Then at some point in our learning journey, we start to hear words and phrases we know are important but do not yet understand. We hear words like sprints, scrum, and agile, and we hear phrases such as test-driven development and the Big O notation.
Your first response to hearing technical jargon may be to worry.
Rest assured, you are not alone in feeling this way. Understanding what technical jargon is, how to learn it, and how to handle situations when it comes up will help you to overcome any fears you might have.
According to trusty Wikipedia:
Jargon is specialized terminology associated with a particular field or area of activity. - Wikipedia
In our case, technical jargon is words and phrases describing tools, technologies, and development methods.
It may seem like the tech field is full of more jargon than other fields. While this may or may not be true, tech is a field that is constantly expanding with new languages and tools, leaving plenty of room for the creation of new technical jargon.
To learn tech language, it is best to:
- Understand the overall concept
- Know that it is context specific
- Create a definition list
Rather than memorise words or acronyms, it would be better to understand the overall concept. Once you do that, you may find you remember the jargon without needing to try!
For example, let’s take a look at agile, which is a development methodology.
Agile development allows flexibility, giving developers the ability to create and respond to change.
In simple terms, the concept of agile is a guide of principles of how to develop software.
Understating the concepts of technical words and phrases will make it easier for you to learn and understand their definitions. 🧐
In conversations, it is vital to identify the context of the technical words or phrases to understand their meaning.
A lot of terms are context specific. For example, API (Application Programming Interface) has a definition, but depending on the context, the meaning can change. This library has a nice API, and an API endpoint is two different meanings.
To confuse matters further, some acronyms are used more than once and you have to decide the meaning based on context. For example, MVP could mean Mode-View-Presenter or Most Valuable Profesional. Saas could mean Software as a Service or Syntactically Awesome Style Sheets.
It is also important to note that context-specific terms can differ from company to company.
Below is an example list containing a few essential technical words and phrases, their Wikipedia definitions, and some notes. Use this as your starting point and add more definitions as you learn them ⬇️
- 🧪 Algorithms
- An algorithm is a finite sequence of rigorous instructions, typically used to solve a class of specific problems or to perform a computation. Using algorithms to break down problems into simpler steps is an essential skill for developers.
- 🏎️ Big O notation
- Big O notation is a mathematical notation that describes the limiting behavior of a function when the argument tends towards a particular value or infinity. As the size and complexity of your programs increase, for scalability, it is crucial to understand and decide what to use for maximum efficiency.
- 🔶 Data Structures
- A data structure is a data organization, management, and storage format that is usually chosen for efficient access to data. Data structures provide efficiency and help data items to traverse easily.
- ❌ D.R.Y.
- "Don't repeat yourself" (DRY) is a principle of software development aimed at reducing repetition of software patterns. The DRY principle will help you create better and more succinct code.
- 📦 Test-driven development
- Test-driven development (TDD) is a software development process relying on software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. Testing your code first will help prevent debugging your code later!
Naturally, the best way to enter an interview or meeting is to come prepared.
You can prepare yourself by learning, researching, and documenting technical words and phrases as described earlier.
If you are interviewing for your first job in tech, you will not be expected to know methodologies such as agile, as you have not yet worked in a team environment. However, it will benefit you if you know about these methodologies and understand their concept.
As for the common question, “do I need to learn algorithms and data structures,” the consensus is no unless you apply for a FAANG company. However, learning them will significantly benefit you as a web developer and set you apart from other applicants. 👍
During meetings, if you do not understand the technical jargon discussed, it is best if you ask to clarify. Most likely, you are not the only one in the meeting who doesn't understand!
If you’re working from home, you can look it up during the meeting, and you won't have to ask. 😉
As a developer, you will reach a point in your learning journey when you start to come across words and phrases that you know are important but that you don’t yet understand. The words and phrases referred to are known as technical jargon.
Since you may not yet work on a team as a developer, you may find it challenging to learn methodologies such as agile. When facing these scenarios, researching the jargon’s overall concept will make it easier for you to learn and understand its definition.
You may find creating a jargon definition list to be beneficial. Consider starting one, and add the word or phrases, their definitions, and some custom notes as you come across them.
Keep in mind that technical jargon is context-specific, and its meaning can vary from company to company. If you are unsure of what the discussion in a meeting is about, be brave and ask for clarification. You and your colleagues will be relieved that you did when the technical jargon is finally understood!