Read this code:

let a = 10;
let b = a;
a = 0;

What are the values of a and b after it runs? Work it out in your head before reading further.

If you’ve been writing JavaScript for a while, you might object: “This snippet is much simpler than the code I’m writing every day. What’s the point?”

The goal of this exercise isn’t to introduce you to variables. We assume you’re already familiar with them. Instead, it is to make you notice and reflect on your mental model.

What’s a Mental Model?

Read the code above again with an intention to really be sure what the result is. (We’ll see why this intention is important a bit later.)

While you’re reading it for the second time, pay close attention to what’s happening in your head, step by step. You might notice a monologue like this:

• let a = 10;
  • Declare a variable called a. Set it to 10.
• let b = a;
  • Declare a variable called b. Set it to a.
  • Wait, what’s a again? Ah, it was 10. So b is 10 too.
• a = 0;
  • Set the a variable to 0.
• So a is 0 now, and b is 10. That’s our answer.

Maybe your monologue is a bit different. Maybe you say “assign” instead of “set,” or maybe you read it in a slightly different order. Maybe you arrived at a different result. Pay attention to how exactly it was different. Note how even this monologue doesn’t capture what’s really happening in your head. You might say “set b to a,” but what does it even mean to set a variable?

You might find that for every familiar fundamental programming concept (like a variable) and operations on it (like setting its value), there is a set of deep-rooted analogies that you associated with it. Some of them may come from the real world. Others may be repurposed from other fields you learned first, like numbers from math. These analogies might overlap and even contradict each other, but they still help you make sense of what’s happening in the code.

For example, many people first learned about variables as “boxes”—containers that hold your stuff. Even if you don’t vividly imagine boxes anymore when you see a variable, they might still behave “boxily” in your imagination.

These approximations of how something works in your head are known as “mental models.” It may be hard if you’ve been programming for a long time, but try to notice and introspect your mental models. They’re probably a combination of visual, spatial, and mechanical mental shortcuts. These intuitions (like “boxiness” of variables) influence how we read code our whole lives.

Unfortunately, sometimes our mental models are wrong. Maybe a tutorial we read early on sacrificed accuracy in order to make a concept easier to explain. Maybe, when we started learning JavaScript, we incorrectly “brought over” an expected behavior from a language we learned earlier. Maybe we inferred a mental model from some piece of code but never really verified it was accurate.

Identifying and fixing these problems is what Just JavaScript is all about. We will gradually build (or possibly rebuild) your mental model of JavaScript to be accurate and useful. A good mental model will give you confidence in your own code, and it will let you understand (and fix) code that someone else wrote.

(By the way, a being 0 and b being 10 is the correct answer.)

Coding, Fast and Slow

“Thinking, Fast and Slow” is a book by Daniel Kahneman that explores the two different “systems” humans use when thinking.

Whenever we can, we rely on the “fast” system, which is good at pattern matching and “gut reactions.” We share this system (which is necessary for survival!) with many animals, and it gives us amazing powers like the ability to walk without falling over. But it’s not good at planning.

Uniquely, thanks to the development of the frontal lobe, humans also possess a “slow” thinking system. This “slow” system is responsible for complex step-by-step reasoning. It lets us plan future events, engage in arguments, or follow mathematical proofs.

Because using the “slow” system is so mentally draining, we tend to default to the “fast” one—even when dealing with intellectual tasks like coding.

Imagine that you’re in the middle of a lot of work, and you want to quickly identify what this function does. Take a glance at it:

function duplicateSpreadsheet(original) {
  if (original.hasPendingChanges) {
    throw new Error('You need to save the file before you can duplicate it.');
  }
  let copy = {
    created: Date.now(),
    author: original.author,
    cells: original.cells,
    metadata: original.metadata,
  };
  copy.metadata.title = 'Copy of ' + original.metadata.title;
  return copy;
}

You’ve probably noticed that:

• This function duplicates a spreadsheet.
• It throws an error if the original spreadsheet isn’t saved.
• It prepends “Copy of” to the new spreadsheet’s title.

What you might not have noticed (great job if you did!) is that this function also accidentally changes the title of the original spreadsheet. Missing bugs like this is something that happens to every programmer, every day.

Now that you know a bug exists, will you read the code differently? If you used the “fast” thinking system at first, you might switch to the more laborious “slow” system when you realize there’s a bug in the code.

When we use the “fast” system, we guess what the code does based on its overall structure, naming conventions and comments. Using the “slow” system, we retrace what the code does step by step—a tiring and time-consuming process.

This is why having an accurate mental model is so important. Simulating a computer in your head is hard, and when you have to fall back to the “slow” thinking system, your mental model is all you can rely on. With the wrong mental model, you’ll fundamentally misunderstand what to expect from your code, and all your effort will be wasted.

Don’t worry if you can’t find the bug at all—it just means you’ll get the most out of this course! Over the next modules, we’ll rebuild our mental model of JavaScript together, so that you can catch bugs like this immediately.

In the next module, we’ll start building mental models for some of the most fundamental JavaScript concepts—values and expressions.