Will Winter Game Maker

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:

For example, in place of “dependency injection” (7 syllables), the term “plugin” (2 syllables) is shorter and more concrete.

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.

More Posts