I Can Has Websiting Job? Learning to Talk Tech


(Previous: Full Stack JavaScript)

In my experience learning and teaching languages, I’ve noticed that there’s often a wide gap between being able to put together a coherent sentence and being able to explain why and how that sentence works.

Even a simple sentence like “I’m eating a cheeseburger” can be difficult to break down and explain in grammatical terms (especially when you’re trying to explain or understand across a language barrier).

Seriously, how do you explain the “cheezburger” part of this?

In the cheeseburger sentence, in big picture terms, there is a subject, there is a verb, and there is an object… But what kind of verb is it? And what kind of object? Why can we say “I’m eating” or “I eat”, but not “I’m eat”? Why is it different to say “I’m eating cheeseburger” and “I’m eating the cheeseburger”? (And Lord help the grammar explainer taking on additional cultural add-ons like explaining how native English speakers use the phrase “I can has cheezburger?“.)

Speaking, understanding, and explaining are completely different skills. Most people know this intuitively when it comes to language. A lot of people who can’t talk about grammar at all still speak English just fine.

But in the world of coding, building a common vocabulary of correct technical phrases is almost as important as getting the code to work.

Of course, I figured this out the hard way. When I was starting out coding, I assumed that, like in learning English, the most important task was getting the code to work, so I focused on that first. But I quickly ran into problems when asking developer friends for help. Why? I didn’t have the right vocabulary to explain my problems, and they weren’t used to people phrasing coding questions in non-coding vocabulary.

A typical exchange:

Me: “What’s a ‘return’? Why does the code have to ‘return’ the answer?”

Developer Friend: “‘Return’ returns the information after the function has run.”

Me: “Oh, so it’s like ‘console.log’. The return lets me see the answer.”

DF: “No, ‘console.log’ logs the information to the console. ‘Return’ returns the information.”

Me: “Right, so they both return information.”

DF: “No. One returns it, the other logs it.”

Me: *runs program with ‘return’ statement, then runs identical program with ‘console.log’ statement* “It looks the same to me.”

DF: *sighs*

It was like we were talking past each other. He didn’t understand my confusion, and I didn’t understand his explanation. And since he kept repeating the same words, I got more and more frustrated, since the words were part of my barrier to understanding. When teaching English, this is when you would reach for a few synonyms, a couple of examples, and possibly a pen to do some Pictionary-style explaining, but none of that was happening–just repetition.*

Here are a few more:

  • Chars are letters. Ints are integers. Doubles, Decimals, and Floats are all numbers involving a decimal point, with varying degrees of precision. Booleans (sometimes called bools) are values of either true or false. Variables are pieces of memory allocated to save specific data that you’re working with–the string that indicates a username, or the int that represents a user birthdate, or the answer to a difficult math problem that a function can calculate for you.
  • Functions are code snippets that perform a given task, often over and over. For example, you can write a function that will add all the numbers between x and y, then reuse that code every time you need a new set of numbers added.
  • When you use a function, you call it. Functions have parameters (strings, ints, booleans, etc) that are passed in when the function is called.
  • Programmers even have their own nonsense words: foo and bar. So if a programmer wants to use an example of a function and can’t think of a name, she might call it function Foo or function Bar or function fooBar. All of which is super confusing to newcomers.

Okay, great, you have some new words. So why does this matter?

Because if you go to your developer friend (or to Stack Overflow) and say “I tried to write a thingie** where the numbers between the numbers in the parentheses get added up to be used later, but when I run the program using easy numbers it doesn’t work,” they will stare at you blankly, and you will feel stupid for trying to ask.

But if you say “I tried to write a function that takes two integers as parameters–let’s call them x and y–and then sums all the integers from x through y (and including and y), and saves the answer in a variable I can access later, but when I call the function using 1 and 10, it doesn’t seem to be working,” you are likely to get some help. And not look stupid.

All of this precision of language is also important for interviewing. Because no matter how good you are at writing code, at some point you’ll have explain what you’ve been working on to a recruiter, and if you don’t know the magic words, you will come across looking like an amateur, even if you coded a really awesome app. You have to sound like you know what you’re talking about. Technical vocabulary creates a shared space, and learning it is part of what makes you in the “in” group of “people who know what they’re doing”.

For outsiders like me (women make up around 15% of programmers), learning to “talk tech”, on top of having to master the skills needed to be a good programmer, can feel like an unnecessary and arbitrary barrier, especially at the beginning. But it’s worth putting in the time–like with learning any other language,you will eventually reach a point where you’re not scrambling for the right word, and where you aren’t retranslating all of the tech terms into more familiar words in your head.

And hopefully, when you reach that point, you’ll be in a place to help bridge that gap for other people coming up through the pipeline.

(Next: Whiteboards in Engineeringland)

*If you’re interested in returns: When a function finishes running, the information it used and produced is lost, unless it’s saved to a variable that can be accessed outside of that function (like a previously created variable), or returned and saved into a new variable. So when a function that returns a value is called, it will often be called so that it automatically saves the answer in a variable, like this:

var returnedAnswer = myFunction(x, y);

Then the result of whatever “myFunction” was will be saved as “returnedAnswer”, and can be accessed or logged or printed or whatever else, even though the function is finished running.

Logging a function, on the other hand, just prints information to the console, and the console is only really used by developers–it’s kind of like the control room for a site, where you get a behind-the-scenes view of what is happening. “Console.log”is often used to print error messages, testing messages, and other messages to the console so they don’t interrupt the user’s experience on the site, but give the developer useful information. Beginning programmer sites often use a “console environment” where the learner has direct access to the console, which makes it easier to see what the program does and harder to understand why you don’t actually use “console.log” much in writing regular code.


** Just FYI, developers hate the word “thingie” as much as English majors hate it when people confuse “you’re” and “your”. You’re welcome.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s