WD World

Helping Non-Developers Understand What Devs Are Doing

For non-developers who work with devs, it might seem like the devs are creating magic with code. In reality, it’s not nearly as mystical: as programmers, we’re basically linguists crafting ever-more descriptive language so that we can more easily communicate with machines.

An analogy may help non-developers understand what this means a little better. I’ve seen coding analogies based on cooking, architecture, and even one based on ordering a drink at a coffee shop. I like to use human language as an analogy because, well, we code using languages just like we speak using languages. Here’s my version.

In JavaScript, there are currently around 84 “reserved words” that make up the core of the language, and a syntax for coding that acts like the grammar that we learned in our language arts classes in grade school. For the purpose of illustration, we’ll just talk about opening and closing curly braces (i.e., ‘{‘ and ‘}’) as wrappers for the object of our sentence. So, in a sentence like, “Alex is a tennis fan,” ‘Alex’ is the subject, the verb ‘is’ tells us that we’re defining Alex in some way, and ‘a tennis fan’ is the object that goes into defining Alex. If we were to “codify” that into some made up English Script programming language–let’s call it EngScript–it might look like:
Alex is {
a tennis fan
}

So now let’s consider what a “core set” of EngScript keywords might look like. We’ll just round up the 84 reserved words that JavaScript gives us to an easy-to-work-with 100 most common English vocabulary words. Here’s that list:

The 100 Most Common Words in English

the
of
and
a
to
in
is
you
that
it
he
was
for
on
are
as
with
his
they
I
at
be
this
have
from
or
one
had
by
word
but
not
what
all
were
we
when
your
can
said
there
use
an
each
which
she
do
how
their
if
will
up
other
about
out
many
then
them
these
so
some
her
would
make
like
him
into
time
has
look
two
more
write
go
see
number
no
way
could
people
my
than
first
water
been
call
who
oil
its
now
find
long
down
day
did
get
come
made
may
part

Basically, programming is taking the core set of words and using them to define new words that we can use again and again in different contexts. So, let’s say that in EngScript I want to express the sentence, “Meet me at noon.” In our core set of 100 EngScript keywords in the table above, all I have at my disposal is, “____ __ at ____.” That’s not a very communicative sentence. We need some more definitions.

Let’s define ‘meet’. Using only the words available to us through our core set, I might define it as:
meet is {
when two or more people go to each other
}

We’ve just defined a new word that wasn’t in our original core set! But, we’re still only able to express, “Meet __ at ____.”

Let’s move on to defining ‘me’. We’ve got good comparisons with existing subject-object pronoun pairs, so let’s define it that way.
me is {
to 'I' like 'him' is to 'he'
}

So now we’ve got, “Meet me at ____,” ready to go. The final piece needed is ‘noon’. Let’s try to define it.
noon is {
when day time is in the middle
}

Whoops, we’ve hit an EngScript error: word ‘middle’ undefined. The word ‘middle’ is not part of our core set of words, so we’ll have to define it separately:
middle is {
the half way part
}

That’s better. We can now use the newly defined ‘middle’ word within our definition of ‘noon’. Our final EngScript code looks like this:
meet is {
when two or more people go to each other
}
me is {
to 'I' like 'him' is to 'he'
}
middle is {
the half way part
}
noon is {
when day time is in the middle
}

With all of this newly defined linguistic functionality, we can finally express, “Meet me at noon,” as semantically valid EngScript.
/commence rejoicing
Interestingly, despite adding more concrete meaning to how the code can be read by humans, this concept of defining new meaning in a programming language is called abstraction because it’s moving away from the core set of words and “wrapping” defining logic inside of those curly braces we used.  The end result is a codebase that’s easier to understand by the developers, and, therefore, easier to maintain in the long run. Just imagine if we tried to apply the definitions of our new words directly into those blanks we encountered: “____ __ at ____” would have been rendered, “When two or more people go to each other to ‘I’ like ‘him’ is to ‘he’ at when day time is in the half way part.” If another EngScript developer tried to maintain that, half of their day might be puzzling out what it actually meant in the first place.

Like most analogies, this one is overly simplified, but I think it helps get the point across. Software development is the deceptively simple job of using a core set of functional keywords to build a programmatic solution to a problem. In reality, it’s very complicated to build robust solutions from such simple foundational blocks, but it’s also what makes programming such a delightful challenge.

What we do best