Joe Lesko 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 hugely complex systems using nothing but text. You could say that words are both our tools and our building materials.

And because of that, coming up with good names is an essential task. (Possibly THE essential task of a programmer!)

When we pick good variable and function names, we get a clearer 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. It slows us down and we make more mistakes.

For example, compare this snippet of code...

if $blahBlah > $fooBar {
    $whirlyWham = 10

... whith this one:

if $withrawalAmount > $availableBalance {
    $overDraftFee = 10

These two snippets are essentially identical to the machine that is parsing them.

However, to any sane human, the first example is completely meaningless. A codebase filled with such nonsense would be impossible to maintain.

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, take the terms “dependency injection” and “polymorphism”.

They are meaningful, but to an extreme. They’re so verbose that it actually takes extra effort to imagine how they are used.

This technical jargon sounds important, and might make us feel smart when say them in front of non-programmers, 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.

Big, chunky technical jargon gets in the way almost as much as meaningless nonsense does.

I believe that if we can shrink those concepts by using more concise language (like a kind of compression) we can reduce our cognitive load to make things easier.

In other words, if we can make our tools more streamlined and ergonomic, the more we can fit in our mental toolbox.

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 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. After a while, we might just accept the pain and maybe even stop noticing it after a while, but the problem never goes away.

Here’s how I imagine the “word shapes” from our example:

  __   _   ___       ___             _    _
 _\ \_| |_|   |__|\_/  /_          _| |__| |_
|                        |        |          |
|  Dependency Injection  |   VS.  |  Plugin  |
|__  __  ___   _   _   __|        |__________|
  /_/  |/  /__/ |_| \__\

      complex shape               simple shape

You might say, “But it’s important to be technically precise!”

Remember, words are just “pointers” to their meaning. A word itself doesn’t need to fully communicate its own definition. (Unless you’re German, I guess!)

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.

duck typing
dead code
monkey testing
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
coalesce              -->  absorb
interpolation         -->  insertion
hungarian notation    -->  prefixing
shift                 -->  pop-first
unshift               -->  push-first
boolean               -->  bit
asynchronous          -->  side-run
memoization           -->  call-caching

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.

My Newsletter

Joe Lesko's Weekly Whatever

More Posts