This post is about my past experiences with tech jargon, during the first two years of my software dev career. I highly recommend it to newbies, especially for Bootcamp devs who are just hopping into the industry.
'It's some kind of elvish...'
I came into software development from a bar counter. Well, I've spent some time being a physics undergrad, so I had a basic idea about cognitively intensive work but still, tech jargon really caught me cold.
I was not totally a muggle, had some programming classes in uni, but that's nothing compared to the experience of people who discuss software related technical problems every day. Not even mentioning that they do this in the context of specific, work-related domains. Coming into this as a junior can be pretty intimidating.
Luckily, tech companies are usually promoting learning, as it's an essential part of almost every developer's job, thus they support bold proactivity and making mistakes during work rather than punishing it.
The bar might be high to get into some well-paying job, but usually, after you've hit that bar, you can indulge in blessed ignorance for a few weeks -sometimes even months- until you catch up with your colleagues in domain knowledge and local practices/tools.
And you'll need this time for sure.
Runes and Incantations
The first thing that I realized as a junior, was that how effortlessly my colleagues can express relationships and issues in a technical topic, using the perfect vocabulary. You know it's much harder to explain "you know there is this string handler operation that finds the domain in the text, that you keep copying around here and there" rather than saying "there's a redundant URL parser in your code, extract it".
In my first days, I've created an 'expressions' note in Google Keep to keep track of all the unknown concepts that I heard flying around me so I could google them later. I still have the note, and I'm still using it! Now I've decided to share it so others could benefit from it. These are not just technical expressions, but also general stuff that people tend to throw around in tech.
Heads up number one: non-native English speaker here
Some of these might not be a big deal if you're native English. Funny thing is: I'm not native English but all these expressions are written English in my notes too - which means these are words that we use in English even when we're talking between Hungarian developers.Heads up number two: gonna keep it casual
I'm not going to write down huge mathematical definitions, so this is gonna be pretty casual. I'm gonna go with an 'explain like I'm five' approach. Expect 'stuffs' and 'thingies'. I'm also not going into structural design patterns, like Proxy, Decorator, Adapter, Bridge, etc. For those, you'll gonna have to do a Design Patterns course if you don't know them yet.
Here we go!
1. Nested
I thought we could start with a very simple one. I bet this is nothing new, it was just not intuitive for me to use it in a tech context at first. I think it first came up with JSON. We refer to embedded structures as nested ones.
{
"firstName": "John",
"lastName": "Smith",
"address": {
"streetAddress": "21 2nd Street",
"city": "New York",
"state": "NY",
"postalCode": "10021-3100"
},
}
It kind of feels stupid to google 'access JSON in JSON' rather than googling 'access nested JSON objects'.
2. Best Effort
It's not super techy, but as a non-native English person, I did not encounter this expression before my tech jobs. Things that we do as 'Best effort' is something that "we do if the circumstances allow it", almost like a "maybe if it's possible, but not necessarily".
3. Race Condition
I thought the official Wikipedia explanation is not too heavyweight here:
A Race condition is a condition of a system where the system's substantive behavior is dependent on the sequence or timing of other uncontrollable events.
In practice, developers tend to carelessly throw around 'race condition' anytime when some process is hitting some other process in the software, resulting in some unwanted behavior (even if it doesn't always refer to that). A good example is when two or more threads can access shared data and they try to change it at the same time, resulting in some unexpected havoc.
4. Literals
A tricky one. In programming, a literal is basically a value that you write to express something literally. With a javascript example:
const a = 30
Where const is a keyword, a is the variable name, and 30 is a literal.
5. Idempotent
A command or function is idempotent when running it several times produces the same result as running it only once.
A good example is the touch command in bash. Creating a file with touch, and then creating a file with the same name as before will not yield a new file on the second run.
But then again, rm is not idempotent, as deleting a file twice will throw an error - as the file is deleted on the first run, and it does not exist on the second run.
Another example is a constructor of a singleton. Running it when the singleton instance was already created does not result in a new instance - just yields the already existing one.
6. Agnostic
This expression is similar to saying something has interoperability. We're using it to describe a high degree of compatibility. So, something is system-agnostic if it functions without knowing the underlying details of a system that it is working within.
Or for example: if a device supports both USB and FireWire, and doesn't care which of these interfaces the data arrived on, it's agnostic, or data agnostic.
7. Redundant
Redundancy is a very common theme in software development and it's a tricky one, as it can be used in a positive and negative sense as well.
Usually, when a developer says that some code is redundant, she/he essentially means that some parts of a program are unnecessary or unnecessarily recurring.
Dead code, unused variables, repeatedly recomputed values can all be redundancy issues. The typical case is when there is a certain operation in functions which is common, thus could be extracted to a separate step to reduce code replication. In this case, redundancy is the result of lazy programming and is generally considered bad practice...
...yet on the other hand, when we're talking about security for example, suddenly there's no redundancy that could be enough! (I'm exaggerating of course.) For example, a repeatedly recomputed value, or a repeated cache validation at the right places can be a great improvement when trying to ensure security. In this case, redundancy is about data validation and is generally considered good practice.
8. Transitive
The math definition is really straightforward, but with a mundane example:
If there's a nice gastro show in the TV during Saturday morning that gets my aunt Theresa in the mood to cook and that results in me eating a cranberry pie during the afternoon, then me having an afternoon treat is transitively related to having a nice cooking show on schedule during the morning.
For me, this expression came up when we were looking at python libraries during work and I had to realize that some python libraries actually have other python libraries as their dependencies - and that makes your code transitively depend on the dependencies of your libs. Wow.
9. Semantics
Okay, this is just a fancy word regarding the 'meaning of a language', or in our case the meaning of syntactically valid strings defined by a specific programming language.
When I say 'python is semantically simpler than Java' I mean that in python many things can be expressed simpler and shorter than in Java.
10-11. Explicit / Implicit
Two very important expressions, often used in programming. Implicit is often used to refer to something that’s done for you by other code behind the scenes. Consider this groovy expression:
def name = 'Richie'
Here I'm hoping that my expression will be handled as a string because groovy implicitly knows that this literal refers to a string, not a number or an array for instance.
But the nice thing is that in groovy I can say this:
String name = 'Richie'
Here I explicitly describe that the literal is a type of String that I'm storing to the name variable.
12. Interpolation
(Parameter Expansion, Parameter Substitution)
String interpolation is the process of evaluating a string literal containing one or more placeholders, thus yielding a result in which the placeholders are replaced with their corresponding values.
You know: Putting the strings into other strings! See the following javascript example.
const condiment = 'pepper'
// interpolation happens here:
const request = `Can I have some fresh ${condiment} on my steak?`
13. Robustness
This is a term often thrown around in DevOps. Robustness is the ability of a computer system to cope with errors during execution. Basically telling how error resistant is something.
14. Benchmark
A benchmark is a certain standard or point of reference against which things may be compared. Basically, a benchmark is an abstract point that we use to express some quality of a system.
Like if my system reached the 3 beer benchmark during a Friday night I'm much more susceptible to end up in a club.
15-16. Declarative / Imperative
A very simple one which can be a bit hard to understand. We like to call programming languages, tools, or design methods imperative/declarative.
I'll start with the ancient sentence:
“You know, imperative programming is like how you do something, and declarative programming is more like what you do, or something."
Better, let's do a mundane example! Let's say you have a puzzle completing machine that you want to complete a hard puzzle with:
- An imperative way to complete the puzzle is to describe to the machine step by step HOW to pick up the pieces, and what-and-when to do with them.
- A declarative way to complete the puzzle is to tell the machine WHAT the end result should be and let the machine figure out how to get the job done using its built-in mechanics.
React is declarative. Or if you're DevOps, Bazel build language is for example declarative.
- In React you're not explaining programmatically how to change the DOM, you're just managing the state changes, and React takes care of the DOM updates for you.
- In the Bazel BUILD files, you declare rules in a build graph. You're describing dependencies, but the build steps are run behind the scene for you (though you have some access to the inner implementation, configuration, etc).
17. Dependency Injection
I think this one is one of the hardest to grasp. Dependency injection is a clean coding technique tightly connected to the SOLID coding principles, code testability, and Object-Oriented Programming. Actually it mostly comes up when using classes - and it's a question of how a class/object has access to some resources.
Right now I'm going to give you my way of looking at it:
Let's say you have a piece of logic (let it be a module, function, class, etc). Then let's just say you have another piece of logic as well (let's say it's a service or another function). The dependency injection is when you're providing the reference of the second piece of logic to the first one as a parameter, instead of having the reference right in the first piece.
We like dependency injection because what you essentially do is you decouple the creation and management of a resource from your parent object.
I really recommend this StackOverflow post for references.
18. Lazy Initialization
And we end with a simple one: In programming lazy initialization is the tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed.
Hope you've enjoyed this small read!
Top comments (2)
As an ex-bartender I'm surprised you didn't know about race conditions :p
Concurrency is something every bartender has experience with.
True, I probably had a rough idea about that tbh :D