Simpler Programming Lingo
People add extra words when they want things to sound more important than they really are.
— George Carlin
As programmers, we build vastly intricate systems using nothing but text. In a way, words are both our tools and our building materials.
This means that it’s really important that we come up with good names for things.
For example, when we pick good variable and function names, we get a clear mental picture of how our programs work.
Likewise, when our code is filled names that are clunky, meaningless, or vague, it’s harder to understand what is happening. This slows us down and causes more mistakes.
Industry Jargon
If we agree that clear names are important in code, then what does that mean for the terms and lingo that we use as an industry?
For example, we have terms like “dependency injection” and “polymorphism” that are probably more complicated than they need to be.
You might argue, “Hey, these terms are complex because they have a precise technical meaning.” This is true to a point, but in the day-to-day task of programming, I don’t think they serve us very well.
Writing code requires a huge amount of mental effort and focus. When we’re in the zone, we need to juggle a dozen or so concepts in our head at any given time.
I believe that if we can shrink those concepts by using more concise language (like a kind of compression) we could reduce our cognitive load to make things easier.
In other words, the more compact our tools are, the more we can fit in our mental toolbox.
Speaking of Toolboxes
My grandfather was a carpenter, and I've recently started getting into woodworking myself.
It turns out carpentry has almost as much lingo as software engineering, but their terms are straight-foward and unpretentious.
For example: jig, pull saw, countersink, planer, biscuit jointer, cross cut, speed square, miter joint, etc.
What Makes a Good Name?
I believe a good name tends to have these qualities:
- Concise: Short, with few syllables. Easy to say and easy to type.
- Concrete: Familiar, or has a real world analog. Easy to imagine.
- Friendly: Not too technical, maybe even a little fun.
For example, in place of “dependency injection” (7 syllables), the term “plugin”
You could also think of each word as having a different conceptual “shape.”
Good word shapes are more ergonomic, like the curves in a handle that make a tool easier to grasp and more pleasant to use.
Bad word shapes are a hassle to use. They’re clunky and have rough edges that constantly result in annoying cuts and bruises, even if you’ve used them so often that you just accept it.
Here’s how I imagine the “word shapes” from our example:
__ ___ ___ _ _
__\ \_|__| |_|___/ /_ _| |__| |_
| | | |
| Dependency Injection | VS. | Plugin |
|__ ______ _____ _| |__________|
\_\ | /___/ | \__\
complex shape simple shape
What about the technical meaning?
Remember, words are just “pointers” to ideas or definitions. The word itself doesn’t need to fully convey its own meaning. That’s what glossaries are for.
For example, the term “AJAX” caught on over the alternatives because it was snappy and memorable. Even though it is now a bit outdated (the “X” for “XML” is rarely used nowadays), it’s still an easy way to refer to the idea of “updating web pages in real time”.
Good Examples
Here are some industry terms I like.
Once you learn what they mean, they tend to stick with you.
bit bug mixin sandbox duck typing push/pop grep factory template AJAX DRY front-end/back-end dead code monkey testing kludge linker library pipe pointer race dump syntactic sugar zombie process garbage collector code golf
Bad Examples & Alternatives
Here are some particularly clunky terms, and how they might be simplified.
This is just a start. You can probably think of better ones.
CURRENT ALTERNATIVE executable --> runnable instantiate --> spawn encapsulation --> boxing polymorphism --> swappable interface --> controls dependency injection --> plugin delegate --> passthru immutable --> locked, frozen mutable --> unlocked, fluid lambda --> inline function closure --> sticky function increment --> uptick decrement --> downtick subscribe --> listen coalesce --> absorb interpolation --> insertion hungarian notation --> prefixing shift --> pop-first unshift --> push-first obfuscate --> scramble asynchronous --> side-run memoization --> call-caching boolean --> bit
Last Note
The goal here isn’t to “dumb down” the language.
In fact, simplifying language is a perfectly natural thing to do. Humans have always streamlined language with things like contractions, abbreviations, acronyms, slang, etc.
While it takes a bit more creativity to choose words that will stick in our minds and convey difficult ideas (Naming is Hard), I think it’s worth the effort.
On a related note, check out George Carlin’s rant on Airline lingo.