Why Technical Language is Annoying but Necessary
Daniel Cranney
Extensibility. Asynchronous. Abstraction. Object-oriented. Encapsulation.
Do you really know what these words mean? Or, perhaps more importantly, do you need to know what they mean?
Before learning to code, I spent a decade working in education, primarily teaching filmmaking skills to media production degree students.
Video production and programming are different in many respects, but they have more in common than you might think. Both are incredibly technical pursuits, centered around problem-solving and—like any skills worth mastering—take years to perfect. Video production arguably demands a higher degree of creativity, but it requires less lateral thinking than debugging a complex code-related bug. While they’re similar, they diverge in key ways too.
Even so, both areas of expertise bring with them an entire glossary of terms for concepts, approaches, and technologies that the learner must understand alongside the hands-on skills they’re developing. As if learning to code (or to create video content) wasn’t complicated enough, this glossary of terms might just be making it harder.
My question is… does technical language, otherwise known as jargon, help or hinder us when we’re learning to code?
Why Technical Terms Exist
I should say upfront, I’m not opposed to all kinds of technical language. I know it’s not there just to make things sound more complex than they are or to make the person using it sound smarter (though it’s great for that, too).
Technical terms make communication precise.
Take the legal industry, for example. Legal professionals communicate almost entirely in technical language, so much so that it has its own name: legalese.
Similarly, the field of medicine is filled with long and complicated Greek and Latin-origin terms that often have quite literal meanings. Take the term gastroenteritis. Gastro comes from the Greek gaster, meaning belly. Entero comes from enteron, meaning intestine. The itis suffix means inflammation. If it’s just a word ‘created’ by putting origin words together, why not just call it "stomach and intestinal inflammation"?
Well, for a start, it’s more concise. Harder to understand in terms of meaning, sure, but definitely more concise, wrapping up a number of concepts into one (hard-to-decipher) word.
Secondly, it distinguishes the issue from other similar kinds of inflammation, making it more precise too.
Is Technical Language == Technical Knowledge?
Let’s stay focused on the field of medicine a little longer. We’ve accepted that technical terms are concise and precise, but these are only really beneficial for those using them.
In the case of medicine, this is the medical professional communicating with other professionals.
How about for the patient? When we hear professionals using technical language, do we assume they know more about the topic they’re discussing, even if we understand very little of what they’re saying?
In short, yes.
Michel Foucault, the French historian, author, and philosopher, wrote about how technical language shapes our interactions. He suggests that while it does legitimize expert opinions, it can also exclude others from participating in the conversation and subtly dictate their behavior.
In the case of medicine, it means we are more likely to take our doctors’ advice if they use technical language, even if we don’t understand the meaning of it.
Now let’s map this back onto the world of programming.
As a junior, you ask a couple of senior developers for help with an issue. They start discussing the problem between themselves and immediately switch to language you barely understand.
So, naturally, you zone out, unable to keep up, and mentally check out. You wait for the conversation to reach its conclusion and follow the advice they give you.
Did you learn anything new? I mean, you heard some new words, but you didn’t learn what they meant, so no, you didn’t learn much.
Now you might be asking yourself, is it so bad that the junior (or the patient, in the medical setting) is excluded from participating in the conversation? I mean, surely they should just leave it to the experts?
The issue with our programming scenario is that the power rests firmly with the seniors, who effectively speak in code (no pun intended!) to exclude someone with less knowledge from participating and, at the same time, deprive the junior of a valuable learning opportunity.
How to Use Jargon When Teaching Others
As a teacher, I quickly realised that overloading students with technical terms too early was counterproductive.
If I started talking about chromatic aberration or logarithmic profiles before they’d mastered the basics, I’d lose them. Instead, I’d allow them to learn visually and by getting their hands on equipment, then introduce the related terms once they’d experienced the technique, problem, or solution firsthand.
Only then could I reinforce this new kind of language, asking questions like, “X, could you explain how optical flow works to Y?”
If they first understood the concept in plain English, learning the terms afterward made them more concise and precise while still able to explain it to others in a jargon-free way, effectively passing on their knowledge.
Programming tends to flip that approach. Many technical articles, videos, and talks are so laden with terminology that you have to wade through abstract concepts and complex sentences just to make sense of what’s being said.
This can make programming feel more intimidating than it needs to be. But that doesn’t mean jargon is the enemy—it just means we need to use it wisely.
How to Find the Balance
The challenge, both in teaching and in programming, is finding the right balance. Technical terms are essential for precision, but they need to be introduced thoughtfully.
In filmmaking, I’d never skip over the term aperture just to keep things simple—it’s too important. Instead, I’d say, “This is the aperture—it’s like the pupil of your eye. It controls how much light gets in.”
A blend of plain language and technical terms made it easier for students to pick up the information, with the most capable students using the technical term immediately and less capable students opting to introduce it later.
The same approach works for programming. If I were explaining something like the event loop to someone new, I’d pair the technical term with a relatable analogy: “The event loop is like a to-do list for your code—it keeps checking what tasks need to be done next.” That way, they understand the concept without feeling overwhelmed, but they’re still learning the terminology.
Conclusion
In education, teaching in a way that makes the content accessible to different levels of student is called differentiation, and it’s something we don’t do well in the world of programming. By mixing technical language with plain language a little more, we can do our bit.
We need to meet people where they are, and make them feel included in the conversation, not excluded from it. Remember that you were where they are once.
Start with plain language to explain the what and why, then introduce technical terms when they’re ready, and never just to make yourself sound smart.
The key isn’t to avoid technical language - just make it a little more meaningful.
If you enjoyed this article and want to see more content about development, design, creativity and learning, then follow me on:
If you'd like to see my work, check out danielcranney.com.
Subscribe to my newsletter
Read articles from Daniel Cranney directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Daniel Cranney
Daniel Cranney
I am a teacher, designer and developer on the road to full stack. I love creatively solving problems by building web applications that look good and work well.