As I was pouring over some Ruby code the other day at Flatiron Code School, an odd memory flashed across my mind: the day back in the late 60’s when I had my very first violin lesson. As the memory opened up and the shadow of my 8-year-old self took possession of me briefly, I witnessed that boy take hold of the violin and the bow for the first time; then his teacher helps him play all the open strings. “Here is the G-string,” she explained. “And the D, A, and E strings.”

That was a very long time ago. But even today, over a half century later, I still practice playing the open strings. In doing so, I am surprised and delighted by the insights I harvest from this, the most basic of violin tasks:
“I did not know the G-string reacted quite that way when sounded from this part of the bow,” I might observe, or perhaps, “Listen how a warmer tone can achieved on the E-string if I do that with the bow.”

Perhaps one thing my experience might tell us is that it doesn’t hurt to go back to the beginning of our trail in a given discipline. In fact, such an exploration could be very fruitful.

The Assignment Operator

Consider this Ruby statement:

my_number = 5

How would you read the above statement outloud?

If you said, “My number equals 5, “ you would be saying just about what everyone says. However, I want to show you that not only is this not quite right, but also that by saying, or more importantly by thinking this way will confuse you and complicate your debugging. (For those of you who already know where I’m going, please have patience and hear me out!)

It’s an Assignment Operator, Not an Equals Sign

Consider again our Ruby statement:

my_number = 5

Let’s take a few minutes out and do some cool visualizing with me:

I want you to imagine an empty shoebox.

Conjure up an imaginary sticky note and write on it “my_number”.

Now take that sticky note with “my_number” written on it and attach it to the outside of the shoebox.

Lastly, imagine a nice, heavy piece of metal shaped to look like the number “5” and place that metal “5” inside the shoebox.

Now, after visualizing our little procedure above, we can now re-language how we express our original Ruby statement as follows:

“The shoebox with the sticky label ‘my_number’ contains the number ‘5’”

You’ll note that I cannot say, “my_number equals ‘5’. My metal clump shaped like the number “5” is not the same (does not equal) my shoebox. My shoebox is merely the container for my metal clump.

Now that we’ve come this far, let’s refactor how we language our Ruby statement. We already know there is a shoebox involved, so we can shorten our statement and leave out the word “shoebox” like this:

“‘My_number’ contains the number ‘5’”

Although we’ve shortened our statement, keep on visualizing the shoebox as we continue to refactor.

Well, I think we’ve come far enough so now that with one more refactoring, we can language our original Ruby statement in a way that will allow us to communicate with our colleagues when we talk about our code:

“‘my_number’ contains the number ‘5’” now becomes:
“‘my_number’ takes the value of ‘5’”.

If you don’t like that way of languaging, I’ll give you an alternative:
“‘my_number’” is set to ‘5’”

And I’ll suggest one last way to read outloud our original Ruby statement:
“‘my_number’ is assigned to ‘5’”

In fact, this last version may be the most accurate as the “=” sign in Ruby
is called the Assignment Operator.

(https://www.tutorialspoint.com/ruby/ruby_operators.htm)
(https://docs.ruby-lang.org/en/2.0.0/syntax/assignment_rdoc.html)

Why Is This Important?

I had this discussion with a colleague the other day when I brought up this subject of the assignment operator. “But I can say ‘equals’, Donny. I already know what it really means,” they argued.

Their statement, in my opinion, underestimates the power of the spoken word. For example, if I keep telling you over and over again that the sky is green, and given the right circumstances and motivation, I can at least create doubt in your mind over time as to the true color of the sky. Don’t politicians do this kind of thing all the time?

When you say ‘equals’ with your mouth, even if you “know” what the truth is about the assignment operator, you create a cognitive dissonance which over time will cause you to doubt, even unconsciously, what you’re saying with your code. The whole reason I’m writing this article is because I’ve seen colleagues say ‘equals’ and then witness confusion in those colleagues’ minds when they try to debug and understand what their code is really saying.

Be the Queer One

So now comes the fun part!

Next time you’re pair programming as the driver and want to declare a new variable and its value, try saying “is set to”, “takes the value of”, or “is assigned to” instead of “equals.”

Truth be told, over the hundreds of video tutorials on coding I’ve seen and all the teachers I’ve studied with, only a very small percentage of them ever use the language I’m advocating in this article. So if you really do what I’m suggesting, you will get to be “The Queer One.”

But take it from someone who knows a thing or two about being queer: sometimes it’s “The Queer One” who arrives a little closer to the “heart of the matter.”

Keep on coding out your dreams. Namaste and blessings,

Donny