Intro to Coding

Part 1: Coding Basics

Part 1 | Part 2 | Part 3 | Part 4

This is a long, careful lesson. It’s not hard, but it carefully takes you from “zero coding” to “I have some idea what’s going on.” Take your time reading it, and come back to it later in the semester as needed.

Lesson #1: Computers Are Dumb.

This is going to seem like a hot take, but it’s not.

Computers are machines. They are boxes of metal and silicon and plastic that just shuffle electrons around. They can only do a handful of things out of the box - everything else you have to teach it.

Worse, when writing code, the computer will only do exactly what you ask it to. They don’t exercise any kind of “judgment” in deciding what you mean. When you write a line of code and run it, it has to be dead clear to the computer, or it won’t work.

You might be wondering, “If computers are so dumb, how come they seem smart?”

Great question, thanks for asking.

Any “smarts” a computer shows is the result of two things:

  1. Humans being smart in how we tell computers what to do (“programming”)
  2. Computers being unbelievably fast at the simple things they do.

With human intelligence in programming, and electricity-speed execution, a computer can appear to do very “smart” stuff. Like solve a calculus problem, or give you travel tips for Morocco, or genearate a playlist to pump you up during a workout. How you build up to these things is all about programming.

Let’s zoom in both parts: speed and programming.

“Speed. I am speed.” – Lightning McQueen

One way computers do things that look smart is by doing dumb things really, really fast.

Here’s an analogy:

Say you have the world’s dumbest computer. All it can do is math. Actually less than that – it can’t do anything like add or subtract. Nope, it only knows how to one thing: “count up by 1.” So you could say, “Start at 3, and count up by 1” and it would correctly tell you “4.” You tell it “count up by 1 again” and it says “5.” That’s all it does.

But you need it to add two numbers for you, maybe 50000 + 75000. The problem: it doesn’t know what “plus” means. It doesn’t know addition. If you say, “Please add 50000 and 75000” it will cry and throw an error.

The only basic command you have is “count up by 1.” What to do? Well, you get clever. You tell it, “Start at 50000. Then, 75000 times, count up by 1. What number do you have now?”

This will work.

It seems like a really tedious way to get there. If you asked a human to count up 75,000 times, it would take them forever. But a computer can do this in the blink of an eye. It can count up, 75000 times, in about a millionth of a second, and correctly respond with, “125,000” before you can blink. The effect is that it looks like the computer knows addition! It doesn’t really, but with a human’s help, and superhero speed, it found a way to “do addition” by counting really fast.

Under the hood, even things like AI chatbots are doing dead simple things – mostly multiplying numbers. How you can turn “multiplication” into “brilliant conversation partner”… takes human ingenuity.

Programmers as machine operators

The key part to the solution above was the human. They considered what things the computer could natively do (“count up by 1”) and cleverly arranged only those native things to make it do something new (addition). The computer “got smarter” by way of a human.

This is sort of the gist of all of programming. There is rarely the perfect single command to do exactly what you want. Instead, you look at the limited set of things it can do, then you cleverly put these limited options together to get something much cooler.

It’s not unlike trying to cook dinner with only what you already have in the kitchen. You might be missing some important ingredients, so you have to get creative. The more clever you are, the more dishes you can find a way to make.

Interesting notes / history (optional read)

The fact that computers seem to get smarter every years is largely due to advances in how fast they can do things. There’s something called Moore’s Law that describes this trend of technical progress, which (very roughly) says that every 18 months, computer chips will get twice as fast. This trend has held for decades and does not appear to be slowing down. A computer chip made in July 2026 tends to be about twice as fast as a chip made in January 2025. Roughly, it can do twice as many things per second.

This is (one) reason why companies like Apple release new versions of the same product every year: faster computer chips keep becoming available, so they can make more powerful phones this year than last year. (Whether you, the consumer, will notice the benefit is another question - modern phones are already very snappy and can do amazing things, so the next version might not really feel different to you.)

Another way computers get faster is with better programming. The explosion of AI chatbots like ChatGPT (“large language models”) was enabled in part by a key research finding from Google about a more clever way to train these bots, making them dramatically more powerful.

Computer Languages, Human Languages

Like human-human communication, human-computer communicates requires a shared language. You can’t speak Greek to someone who only speaks Mandarin.

Out of the factory, your computer speaks no useful languages. They only have one, limited language (“assembly code”) which literally controls how the electricity flows in its circuits. Unless you’re a hardware engineer, this is not something you ever want to touch.

Instead, you “install” a programming language, like “R” (the language we use in this class). What you’re really installing is a translator - you write code in the R language, and the translator (invisibly) converts it into the electron-shuffling instructions that the computer can perform.

Language rules

R is a language, and just like human languages, R has rules. And the translator will enforce them.

In both human languages and computer languages, some things are valid words, and some are not. “Banana” is a valid English word, but “flopsomat” is not. If you said, “Flopsomat!” to someone, they’d give you a blank stare of confusion.

Likewise, the R programming language also has a set of valid words. For example, it has the word sum, which can be used to add up a bunch of numbers. That’s a native word in R. However, cloud is not a native word in R, so if you type that, the computer will be confused and throw an error.

Beyond the words themselves, both human and computer languages have grammar – rules about word order, punctuation, capitalization, spaces, etc.

The sentence, “Alice went to get her flu shot, finally” is valid English. However, “Alice shot get went flu to her, finally” is not. It has all the same words, but the order is grammatically incorrect. Similarly, in R, if you want to add up the numbers 4, 5, and 6, the correct way is to type sum(4, 5, 6) (we’ll teach you to use sum later). If you said (4, 5, 6)sum instead, the computer would throw an error. Despite using valid words, it recognizes that this is not correct “R grammar” and complains.

All languages also care about things like capitalization, punctuation, spaces, etc. In English, “aliCE WEnt to the Store?$ thankfully” is not correct. The words are right but the capitalization and punctuation are all wrong. Similarly, in R, while sum(4, 5, 6) is valid, sum(4 5 6) is not. Can you spot the difference?

Yes, R expects commas between the numbers in this case. Even though it would be obvious to a human what you intended with that code, a computer won’t try to guess what you mean. You follow the rules of the language, or it doesn’t work.

So get on board with your new coworker. It’s picky, but if asked nicely, it will do amazing things for you.

Getting your feet wet in R

“Running” code

In this class, you’ll do most of your coding work elsewhere - in a program called “R Studio” that we’ll talk about later in this tutorial. But in this lesson and many others on this website, we insert little boxes where you can write and try out R code without leaving the page.

When you press “play” on the box below, it will “run the code.” Meaning it will send the contents as a command to your computer. If the computer gives a response, it will be printed to the screen. Try running the command below by pressing the “play” button.

Did you notice anything weird? It doesn’t just print the answer 32, it also printed [1] at the start of the line: you seee [1] 32. For now you can just ignore the [1] part. We’ll come back to this later, but it’s harmless.

You can put many lines of code in the same block, and when you hit “play,” each line you wrote will become its own command. It will send each commands to the computer, one at a time. Try this:

When you hit “play,” it first sent the command 2 * 3, and the computer’s response was 6. Which was printed to the screen. Then it moved on to the next command, 7 * 8, and the response was 56. Also printed to the screen.

Errors

If something goes wrong with a command, the computer will stop and give you some kind of error. Further, it will not run any of the remaining commands in the cell. Consider the cell below. The first line is not a valid R command, so it will cause an error. Then the computer will stop, print something about the error, and not even get to the second or third lines.

Two things showed up for you. First is the real error message from R, which is all you would normally see when you are programming. Then there was a red box (“It looks like this might not be valid R code…”) which is something you’ll only see on this website, in these little practice boxes. It tries to give you a more helpful error, as R’s native error messages can be cryptic.

When you’re actually working, you’d just see this first part:

   Error: <text>:1:4: unexpected symbol
   1: 14 z
          ^

Obviously something went wrong, but what? If you squint, you can see that the problem seems to be on the first line (14 z 2). It’s hard to make sense of the mess it printed (“unexpected symbol”?), but at minimum you know there’s a problem. With time, you’ll learn to interpret these error messages for useful clues about what went wrong, but for now it’s enough to know “there’s a problem.”

The issue here is that z is not a valid word in R. It’s like you just said “flopsomat.” It doesn’t know what you mean, so it stops.

Getting useful - variables

Unlike a “variable” in a dataset (like the “species” of a penguin), a “variable” in code is just a label that you attach to something you want to save and refer back to later. Try running this cell and seeing if you can follow:

The first line is more complex than it seems! The <- (arrow?) is special in R: it’s how you create new variables (it’s a “less than” sign, followed by a dash).1 The stuff to the right of the <- is run as a command first. Then the computer’s output from that command is saved under the label z. Remember, z is not a native word in R! But it’s a valid word now – and it means 14. When you run the second line, z + 1, R recognizes z as a variable. The command z + 1 now means, “Go look up what z is, then add 1 to it, and give me the answer.”

You can think of R as slowly replacing things as it works:

  1. Given the commmand: z <- 7 * 2
  2. It sees the arrow symbol, and computes the right-hand part.
  3. It replaces 7 * 2 with 14.
  4. Now the command is z <- 14 which it can do. Make a variable called z that refers to the number 14.
  5. Goes to the next command, z + 1
  6. Recognizes z as a variable, and looks up its value: 14.
  7. Replaces z with its value to get 14 + 1
  8. Executes 14 + 1, which it knows how to do.
  9. Shows you the result: 15

You’ll make lots of variables as you do your work. You’ll load a whole dataset from a file, and save it as a variable (maybe calling it penguins, which is not otherwise a word in R). Then you’ll calculate something and save it as another variable, maybe average_bill_size.

Notice that the code cell above has two commands in it, but it only prints one thing. The line z <- 7 * 2 tells R to do some math and save the answer as z, which it does. Quietly. It doesn’t have anything else to say to you. By analogy, if you asked your roommate to take out the trash (and they are nice) they would do it and hopefully would not bring you anything back.

When R runs the second command, it has an output (15). You didn’t tell it to store this in a variable or anything, so it just prints it to the screen.

After all this, z still means 14! The second line didn’t change it z, it just asked what z + 1 was. See for yourself:

This command just says “look up z and tell me what it is.” It’s still 14.

You can change what z means. This is why it is a “variable.” Try this:

The first line says, “OK, now I want the z label to mean the number 200.” The second line just asks what z is. It prints 200. The previous value of 14 is totally forgotten.

IMPORTANT R does not know that one code cell is “above” or “below” another one on this page. It just knows when it gets commands, and follows them in the order it got them. It’s keeping track of the variables quietly, according to the commands it got in the order it got them.

To see how this can create confusion, scroll up to the cell that just has one command, z. Run it now – did you get the same output as the last time you ran it?

No. You get a different answer, because z has changed! It’s now 200, not 14. That may be fine, but now if you read this page from the top down, following the code and outputs, it will look like z became 200 out of nowhere. There’s no way to see that you ran the cells in a funky order. You can get yourself really confused this way, so be careful.

This is very relevant to your work. When you are doing a coding assignment for this class, you’ll write all your code in a text-editor-like thing called R Studio. In this editor, you can make a bunch of different cells (“chunks”) of code, and run the cells in any order you want. Usually you’ll just run them from the top down as you write them, but sometimes you go back and change stuff. That’s fine and normal, but if you’re not careful, you can create confusion about how you got what you got.

1 Technically, <- is called the “assignment operator,” which is how you assign a value to a variable (like assigning z the meaning of 200). If it’s more natural for you, you can actually use = instead of <- to the same effect. Run this cell to see:

Rules for variable names

You can name a variable z or x or bananas, but you can’t just name it anything:

  • They can be made of only letters, numbers, and the special characters . and _. No spaces or other funny business.
  • They have to start with a letter (or a period)
  • They are case-sensitive. sky and Sky are seen as totally different variables.
  • They can’t use the name of a native R word, like sum. You can’t make your own variable called sum.

These are examples of valid variable names:

  • apple
  • apple123
  • apple_123
  • apple.123_456.hello

These are NOT valid variable names

  • apple pi (spaces aren’t allowed - it will think you typed two different words)
  • apple(pie! (exclamation points and parentheses not allowed)
  • 123apple (can’t start with a number)
  • mean (this is a native R word for taking the average of some numbers, you can’t change it to mean something else)

Text as data: characters and strings

Say we want to store the name of our friend, George, in a variable called name.

The following code will not work:

Remember, computers are dumb. As written, it assumes George is some variable it needs to look up, but it doesn’t know of anything called George. So it throws an error.

However, this code will work (run it – though it won’t print anything)

By putting quotes around "George", we are telling R, “This is just some text data, don’t try to interpret it or anything.”

R will now create a variable called name that refers to the text data “George”. You don’t see any output, as R did its job and had nothing more to say. The lack of an error is R’s way of saying “OK, all good.”

Run the cell below to see that the variable is, indeed, set up correctly:

Characters and strings

Each “letter” in a piece of text data is called a “character.” Note that characters are more than just letters: numbers, spaces, punctuation, and anything you can type is a character. So the variable below is valid text data:

This text has 14 total characters. They are: A, l, e, x, , t, h, e, , G, R, E, A, T, and !. Spaces, punctuation, etc are characters too!

Next: Functions and packages →