Phase 0 · Foundations

Before we write any code

By the end of this page you'll have typed real commands into a real terminal, made a folder and a file, and read that file back.

⏱ ~25 minutes🧩 Needs: nothing at all💻 Code: none yet

Imagine you ask a friend to make you a cup of tea. Forty minutes later they come back holding a kettle stuffed with tea bags and no water at all. You'd assume they were joking. A computer is not joking. A computer is the most literal thing you will ever meet. Learning to program is mostly learning to say what you actually mean.

That's the whole job. Not maths. Not typing fast. Not memorising a thousand words. Saying exactly what you mean, in an order that works, to something with no common sense whatsoever.

So we are not going to write Java yet. First we'll get you comfortable in the room where the work happens. Skip this page and every later page quietly assumes you already know these moves. Then you lose an hour to something that was never the lesson.

Wait — what is Java actually for?

Fair question, and most courses never answer it. Java is a language for writing instructions. What those instructions do is up to you.

Real things people build with it: Android apps, the software banks run on, huge chunks of Netflix and Amazon, Minecraft, and most of the invisible machinery behind websites — the part that remembers your account and takes your money. It runs on everything from a phone to a server the size of a fridge.

What you'll build in this course, in order: a program that prints one line. A game where the computer guesses your number in seven tries. A word counter that reads a real file. Then a playable Wordle, in your terminal, with the colours. That's the end of the first phase, and you'll have written every line of it.

After that it gets more serious — a web server, a database, a program that runs other programs. But that's months away, and none of it works without today.

Worth remembering
Going deeper Why does Java need two tools, and not one?

Because the translation and the running are genuinely separate jobs, done at separate times. javac translates your text once, ahead of time, into an instruction set no human writes by hand. java then carries out those instructions, and can do it a thousand times without translating again.

The payoff is that the translated file runs unchanged on a Mac, a Linux server or a phone — anywhere that has a java to carry it out. Languages that translate straight to one machine's own instructions lose that. Chapter 0.1 is entirely about this split, and it's more interesting than it sounds: the two tools fail in completely different ways, and telling those failures apart is a real skill.

What you'll be able to do at the end

Section 1A program is a recipe. The cook has no common sense.

Think of it like this

A cake recipe is a list of exact steps. Crack two eggs. Add 200g of sugar. Mix for thirty seconds. Bake at 180°C for twenty-five minutes. It's written so precisely that anyone following it gets roughly the same cake. That's the point of a recipe. It moves knowledge out of one person's head and into a list of steps.

A program is exactly that — a list of steps, written down, that a machine carries out. The word "code" means those steps written in a language the machine's tools can deal with. Nothing more mysterious than that.

But there is one difference, and it is the difference that will define your next few months. A human following a recipe fills in the gaps. If the recipe says "add the eggs" and you have eggs in shells, you crack them. Nobody wrote "crack them". You just knew.

A computer never fills in a gap. Ever. It does exactly the steps, in exactly the order. And if you left out "crack them"? It puts whole eggs in the bowl and carries on cheerfully. It will not stop and ask. It will not think "hmm, that seems odd".

The one sentence to remember

A bug is a program doing the wrong thing. Almost every bug comes down to this: the recipe said what it said, not what you meant. When something goes wrong later, your first move is never "the computer is broken". It's "what did I actually tell it?"

This is also, weirdly, the good news. A machine with no common sense is also a machine with no moods. It doesn't get bored on step 400. It doesn't do it differently on a Tuesday. Give it the same steps and the same starting point and you get the same result, every single time, forever. That reliability is the thing you'll lean on when you're hunting a bug at midnight.

You write a recipe that says: "Put the pizza in the oven. Set the oven to 200°C. Wait 12 minutes. Take the pizza out." A human follows it and gets a fine pizza. A computer follows it. What happens?

Section 2Files, folders, and what "saving" actually means

You've used files for years. Let's make sure we mean the same thing by the word. In a few minutes you'll be talking to your computer about them directly.

A file is a named lump of information stored on your computer's disk. A photo is a file. A song is a file. A shopping list you typed is a file. From your computer's side there is no difference between those three. They are all long lines of numbers with a name attached. The name is what lets you find it again.

A folder — sometimes called a directory, same thing, different decade — is a named box that holds files. It can also hold other folders. That last part is the important bit. Folders inside folders inside folders is how your entire computer is arranged. It's one giant tree of boxes.

Think of it like this

Your computer is a filing cabinet. Folders are the drawers, and drawers can contain smaller boxes, which can contain smaller boxes still. A file's full name is really the whole route to it: cabinet → Users drawer → your drawer → Desktop box → note.txt. Written down, that route looks like /Users/you/Desktop/note.txt. Those slashes stand for the word "then". That's one machine's spelling of a route. Yours will read a little differently, and Section 5 shows you how to see it.

That full route has a name: it's called a path. A path is a set of directions to one exact spot. You will type paths constantly. So say this out loud once: the slashes separate the boxes. The last piece is the actual file.

Saving is not automatic, and this trips up everyone

Here's a thing nobody explains. When you open a file and start typing, you are not editing the file. You're editing a copy, held in memory.

Your computer keeps things in two separate places, and the difference matters enormously here. Memory is the fast, temporary one. It holds whatever the computer is thinking about right now, and it empties completely the moment the power goes off. The disk is the slow, permanent one. It keeps things while the machine is switched off, which is why your photos are still there tomorrow.

Memory is what you're holding in your head. The disk is a notebook you write in. Typing into an editor only changes what's in your head — nothing reaches the notebook until you save.

The file on the disk still says the old thing. It says the old thing right up until the moment you save. Saving means "take what's in memory and write it over the file on the disk". That's it. That's all saving is: copying from the forgetful place to the permanent place.

Watch out

This is why unsaved work vanishes when a program crashes — it was only ever in the forgetful place. It's also why your very first Java confusion will probably be "I changed my code but nothing changed". Nine times out of ten, you didn't save. Get into the habit now: type, then ⌘S (or Ctrl+S), every time, until your fingers do it without asking.

You type two new paragraphs into an essay. You haven't pressed save since you started them. Then the battery dies. When you switch the laptop back on and open the file, what's in it?

Section 3The terminal is not hacker stuff

Right now, when you want your computer to do something, you point at a picture and click it. That click is you giving an instruction: open this, run that. You've been programming your computer with your finger this whole time. You only ever had a menu of choices someone else drew for you.

The terminal is the same conversation, typed. It's a window where you type the name of an instruction and press Enter. Your computer does it, then types back. That's the entire idea. A window for typing instructions instead of clicking them.

Think of it like this

Clicking icons is ordering from a picture menu — lovely, but you can only have what's pictured. The terminal is walking into the kitchen and talking to the chef. More effort at first, and then suddenly you can ask for things that were never on the menu.

Why do programmers live in there? Three honest reasons.

One: most programming tools have no icon at all. The tool that turns your Java text into a running program is called javac. It has no window, no buttons, nothing to double-click. It exists only as a name you can type. If you can't type, you can't reach it.

Two: typed instructions can be written down and repeated. "Click the third menu, then the button on the left" is a story you have to re-tell. But javac Hello.java is a thing you can save in a file. You can hand it to a colleague, or run it automatically at 3am. This is a much bigger deal than it sounds.

Three: the terminal tells you what went wrong. When a click fails you often get a shrug and a beep. When a typed command fails, you usually get a paragraph explaining what it tried and where it stopped. Those paragraphs look intimidating for about a week, and then they become the most useful text on your screen.

On the film-hacker thing

Black window, green text, someone typing furiously — films have made the terminal look like breaking in somewhere. It isn't. It's a text box. You cannot accidentally hack a bank, and nothing you type in this chapter can harm your machine. The commands you'll learn today only look at things and make new folders. We'll flag it loudly, later, if anything can actually delete something.

Open it now

One set of commands, for every computer

This course teaches one set of commands — the kind used on macOS and Linux. There's a good reason for that. Servers run that kind. So do nearly all the programming instructions you'll ever read. Learn these words once and they keep working, everywhere, for years.

On Windows: you need one install first, and then you're set for the whole course. Git Bash is the easiest route — it arrives free with Git for Windows. WSL, the Windows Subsystem for Linux, is the more powerful route and takes a little longer to set up. Either one gives you a terminal where every command in this course works exactly as written.

Windows also comes with PowerShell and Command Prompt. Those are real tools and plenty of people work in them. But they use different names for these commands, so following along in them will fight you. One install now saves you months of that.

On macOS or Linux: nothing to install. Your terminal already speaks all of this.

On a Mac: press ⌘ + Space, type "Terminal", press Enter. On Windows: open Git Bash from the Start menu, or start WSL — see the box above. On Linux you already know, or Ctrl+Alt+T works nearly everywhere.

You'll get a mostly-empty window with a line of text ending in something like $ or %. That symbol is called the prompt, and it means "I'm ready, type something". Throughout this course, when you see $ at the start of a code line, that's the prompt. Don't type the $ itself. Everything after it is yours to type.

Section 4Is the toolbox even there?

Java needs two tools installed on your machine. They arrive together in a bundle called the JDK — the Java Development Kit. That's a grand name for "a box with the Java tools in it". Chapter 0.1 is entirely about what each tool does and why there are two. For now we only want to know they exist.

The trick for checking is that most command-line tools will tell you their version number if you ask politely. So we ask both of them.

Predict before you run

You're about to run java -version and then javac -version. Do you expect two version numbers, one, or an angry message? And what do you think happens if a tool isn't installed — does the terminal crash, go silent, or say something?

what actually happens on the machine this course was written on
$ java -version
openjdk version "17.0.17" 2025-10-21 LTS
OpenJDK Runtime Environment Zulu17.62+17-CA (build 17.0.17+10-LTS)
OpenJDK 64-Bit Server VM Zulu17.62+17-CA (build 17.0.17+10-LTS, mixed mode, sharing)

$ javac -version
javac 17.0.17

Two answers, both starting with 17. That's the number that matters — this whole course is written and tested against Java 17. Your version string will read a bit differently from this one, and that's fine. Several companies build Java, and this machine happens to run Zulu's build. If your number starts with 17 or higher, you're set.

Notice java is chatty and javac is terse. No reason. Different tools, different authors, decades apart. Software is full of this.

And if a tool is missing, the terminal doesn't crash — it tells you it's never heard of it:

what a missing (or mistyped) tool looks like
$ javcac -version
zsh: command not found: javcac

Different terminals word that line a bit differently — mine opens with zsh, Git Bash opens with bash. The meaning is always the same. That's the terminal saying "I looked everywhere for a tool called javcac and there isn't one". Which in that example is fair, because I typo'd it. Read the name it's complaining about very carefully before you believe anything is broken. The fix is often a single letter.

If yours really says command not found

Then the JDK isn't installed, or it's installed somewhere your terminal doesn't look. That's a genuine blocker and not a you-problem. You cannot think your way past a missing tool. Install a JDK 17 or newer. Then close the terminal window completely, open a fresh one, and try again. That last step matters more than you'd think. A terminal window works out where the tools live at the moment it opens. So an old window will never notice a new install.

Section 5Five commands you'll type ten thousand times

Every command you type gets carried out somewhere. Not everywhere — somewhere. The terminal always sits inside exactly one folder. That folder is called the current folder, or "working directory" — same thing. It's the terminal's idea of where it's standing.

Almost every command acts on the current folder by default. If you say "list the files", it lists the files here. If you say "read note.txt", it looks for note.txt here, and nowhere else. It won't go hunting. Remember the recipe with no common sense.

Here are the five commands. Read the table, but the real learning is in the walkthrough underneath it.

CommandShort forWhat it does
pwdprint working directoryPrints the full path of where I'm standing right now.
lslistLists what's inside the current folder.
mkdir practicemake directoryCreates a new empty folder called practice, here.
cd practicechange directorySteps into practice. That folder is now "here".
cd ..—Steps back out, into the folder that contains this one.

Two of those need a word of explanation. The command mkdir is pronounced "make dir". It takes the name you want as an extra word after it. That extra word has a name: an argument, which means "the thing you're giving the command to work on". And .. — two dots — is a shorthand that every command understands. It means "the folder one level up", the box this box is sitting in. So cd .. is "step out".

Walking the tree, one command at a time

1. Where am I? Always the first question. A fresh terminal usually starts in your home folder. That's the folder that belongs to you personally, with your Desktop and Documents inside it.

terminal
$ pwd
/Users/you

Read it right to left. I am in a folder called you. That sits inside a folder called Users. And Users sits at the very top of the tree. Yours will have your actual account name where mine says you.

That route is a Mac's shape. On Linux your home folder is /home/you. In Git Bash on Windows it reads /c/Users/you, and in WSL it reads /home/you again. The idea never changes — only the spelling of the route does.

2. What's in here? ls needs no extra word after it. On its own it shows you the contents of the current folder.

terminal
$ ls
Desktop    Documents    Downloads    Music    Pictures

Those are the same folders you see in a file window. Same computer, same boxes — you're looking at them through text instead of pictures.

Your own list won't match mine, and it isn't meant to. Every computer keeps different things in its home folder.

3. Make somewhere to work. Never do experiments in a folder full of things you care about. Make a fresh empty one.

terminal
$ mkdir practice
$ ls
Desktop    Documents    Downloads    Music    Pictures    practice

Look at line 2 closely: mkdir printed nothing at all. That's not a failure. On the command line, silence means "done, no problems". You'll unlearn your instinct to expect a cheerful confirmation. We only know it worked because ls now shows practice.

4. Step inside. cd moves where "here" means.

terminal
$ cd practice
$ pwd
/Users/you/practice

cd also said nothing. But pwd proves it worked — the path grew by one box on the end. That is the entire concept of the current folder, right there in one changed line of text.

5. An empty folder looks like a bug. Run ls in your brand new folder.

terminal
$ ls
$ 

Nothing. Not "empty", not "0 files" — nothing, and then the prompt again. The folder is empty, so ls lists nothing, so nothing appears. It's completely logical and it still makes every beginner think the terminal has frozen.

6. Step back out. Two dots means "up one".

terminal
$ cd ..
$ pwd
/Users/you

The path shrank back. You can chain it: cd ../.. goes up two levels. And plain cd with nothing after it always teleports you home, which is the fastest way to un-lose yourself.

Predict before you run

Here's the one that gets everybody. There's a file called note.txt inside practice. You are standing in practice's parent folder — one level up. You run cat note.txt, which is the command for "print this file's contents". You can literally see the file in your Finder window. What does the terminal say?

what actually happens
$ pwd
/Users/you
$ cat note.txt
cat: note.txt: No such file or directory
$ ls -l practice
total 8
-rw-r--r--  1 you  staff  38  5 Sep 05:56 note.txt

Read those two answers together, because they look like a contradiction and aren't. "No such file" — and then, two lines later, there the file is, 38 bytes of it.

Both are true. cat note.txt means "print the file called note.txt in the current folder", and there isn't one there. The file is one box down. The terminal didn't search for it, because you never asked it to search. No common sense, remember?

If you guessed wrong here, brilliant — you just paid for this lesson at a discount. The alternative is losing forty minutes to it at 1am. "But the file IS there!" is almost always "I'm in a different folder than I think". The cure is one keystroke: pwd. Ask where you are before you argue with the machine.

That last command shows the other trick, by the way: ls -l practice. The -l asks for the long, detailed listing — sizes and dates. The extra word tells ls to look in practice instead of here. Most commands will happily work on somewhere else if you name it.

One line of that listing, one file. The middle columns name whoever owns the file, and every machine fills them in differently. Mine say you staff. Yours won't, and nothing here depends on them. The parts to read are the name, the size and the date.

Try all five right here, before you touch your own terminal

Below is a pretend terminal. It lives on this page, it cannot break anything, and it answers the way a real one would — same replies, same error messages. Nothing you type here touches your computer.

Use it to get the five commands into your fingers. Try this exact sequence, and read each answer before typing the next:

  1. pwd — where am I?
  2. ls — what's here?
  3. mkdir practice — make a folder. Notice it says nothing back.
  4. ls — now what's here?
  5. cd practice then pwd — did the answer change?
  6. cd .. then pwd — and back again.
  7. cat notes.txt — read a file.

Then go off the script. Type a command that doesn't exist. Try cd nowhere. Try cat missing.txt. Those error messages are the ones you'll meet for real, so meeting them now — where nothing is at stake — is time well spent. Press the up arrow to bring back what you typed before.

Practice terminal — a simulation, safe to break. Type help to see what it knows.
~ $
This is practice, not the real thing

That box is a simulation, and it only knows this chapter's commands. It exists so your first command works on the first try. But it cannot compile or run a Java program, and the rest of this course happens in your own terminal — the one you opened in Section 3. When the five commands feel easy here, go and do the same seven steps there.

Section 6Your editor — and why Word is the wrong tool

Java code is text. Plain text. Letters, digits, brackets, spaces — and absolutely nothing else. So you need a program that writes plain text and nothing else. That program is called a text editor.

Word is not one, and neither is Google Docs or Apple's Pages. Those are word processors, and the difference is not snobbery — it's that they secretly add things. Turn on the invisible marks in a Word document and look. You'll find instructions about fonts, sizes, margins and colours wrapped around every letter. Wonderful for an essay. Poison for code, because javac reads those instructions as part of your program. It has no idea what to do with them.

The classic Word disaster

Word "helpfully" turns straight quotes "like this" into curly quotes “like this”. To you they look nearly identical. To Java they are completely different characters, and the curly ones are meaningless. So your program fails. The error message points at a line that looks perfectly fine. And you stare at it for an hour. Real thing. Happens to people every year.

Use a real text editor instead. They're all free. VS Code is the common choice and it understands Java. Sublime Text is good too. On a Mac even TextEdit works, as long as you switch it to plain text first. That's Format → Make Plain Text. What you want from an editor is boring honesty. What you type is exactly what lands in the file.

One more thing to know about file names. A file extension is the bit after the dot — the .txt in note.txt, the .java in Hello.java. It's a label saying what kind of file this is. Tools take it seriously — javac will refuse a file that doesn't end in .java. So when your editor asks where to save, check the name it's about to use, every time.

Section 7Closing the loop

Time to put the two halves together. So far you have an editor (which makes files) and a terminal (which does things with files). The whole rest of this course is those two things passing work back and forth.

We need one more command: cat. It's short for "concatenate", which means "join things end to end" — a terrible name, because joining is not what you'll use it for. All you need to know is this: cat somefile prints that file's contents into your terminal. It's how you check what a file really says, rather than what your editor claims it says.

Predict before you run

You type a sentence into note.txt in your editor, hit save, then run cat note.txt from the same folder. Easy one — but be specific: does cat open a window? Does it change anything? And what happens to your terminal afterwards?

what actually happens
$ ls
note.txt
$ cat note.txt
Today I opened a terminal on purpose.
$ 

No window. No change to the file. It printed the contents where you were already looking. Then it handed the prompt straight back and got out of the way. That's the personality of nearly every command-line tool: do one small thing, print the result, stop.

Now look at what just happened as a loop. You made a change in one program (the editor). You asked a second program (the terminal) to act on it. You read the answer with your own eyes. That's it. That's the loop:

The loop this whole course runs on

edit a file → tell the terminal to do something with it → read what happened

Right now the "do something" is nothing more than print it. In the very next chapter, the "do something" becomes translate it into a program and run it. And the loop doesn't change at all. Same three moves. You already know the shape of every chapter after this one.

Your turn

Do these for real, in a real terminal. Reading about typing is not typing.

Section 8Check yourself

You run a command, and the terminal prints nothing at all before showing the prompt again. What's the most likely explanation?

A friend messages you: "I saved my file but the terminal keeps saying no such file or directory. My computer is broken." Judgment call — what do you tell them to type first?

Section 9What broke, and what surprised you

This section is yours, and it's not filler. Somewhere in the last twenty minutes something didn't go the way this page said it would. A command not found. An editor that saved your file somewhere you didn't expect. A version number that starts with a different digit. A path with a space in it that behaved oddly.

Write it down — in a real note, in your own words. Not "it didn't work". Something more like: "I ran cat note.txt, expected my sentence, got No such file or directory. Turned out I was one folder up." That sentence, written by you, is worth more than this entire page. It's a bug report about your own mental model. That's how you stop making the same mistake twice.

Then answer these three without scrolling up. In your own words, not this page's words:

  1. What is a program, and what's the one thing it will never do for you?
  2. What did cd practice actually change, and how would you prove it?
  3. Why is a word processor the wrong tool for writing code?
Next up

You have a toolbox with two tools in it. You might reasonably be wondering why on earth you need two. Chapter 0.1 answers that, starting from an uncomfortable fact: your computer cannot read Java. Not "finds it hard" — cannot. We're going to find out what actually reads it, and then break the thing six different ways on purpose.

Nice. Chapter marked complete.