The Sandwich Problem
Why computers do exactly what you say — not what you mean
Most people think programming is hard because of the syntax — the arcane symbols, the brackets, the semicolons. It's not. Programming is hard because computers are brutally, unforgivingly literal. Once you understand that, everything else becomes easier.
The classic experiment
Here's an exercise teachers use with children to explain programming. Tell someone to make you a peanut butter sandwich. Then do exactly what they say — word for word, nothing more.
A computer is the world's most literal assistant
Imagine hiring someone who is infinitely capable — they can do anything you describe — but they have zero common sense, zero assumptions, zero initiative. They do exactly what you say. Nothing implied. Nothing assumed. "Clean the house" means nothing to them. "Vacuum the living room carpet in parallel rows, working from the far corner toward the door" — that they can do. Programming is learning to give instructions to this person.
▶ The sandwich instructions
Instruction: "Put the peanut butter on the bread"
Result
You pick up the closed jar of peanut butter and place it on top of the slice of bread.
Technically correct. Completely useless.
Revised instruction: "Spread the peanut butter on the bread"
Result
You put the knife flat on the bread and stare. What peanut butter? How do you get it from the jar?
The jar is still closed. You never said to open it.
Final instruction: "Open the jar, scoop some peanut butter with the knife, spread it across the top surface of one slice of bread"
Result
Sandwich successfully made.
This is how you write code. Every step. Every assumption stated explicitly.
Why this matters for every language
This literalness is not a bug in programming languages — it's the feature. When a computer does exactly what you say, every time, reliably and at speed, you can build incredible things. But you have to say it exactly right.
- JavaScript, Python, Java — All general-purpose languages. Same rules — if you forget a comma or a bracket, the program stops.
- SQL — A language for asking a database questions. "Give me all customers" means nothing — "SELECT * FROM customers" works.
- HTML and CSS — Languages for describing what a webpage looks like. "Make it blue" doesn't work. 'color: blue;' does.
- Git commands — A language for telling version control what to do. "Save my work" means nothing. "git add . && git commit -m 'message'" saves your work.
The liberating realization
You already know how to think in explicit steps. You give driving directions, recipes, assembly instructions. The only difference with programming is you have to be even more specific — and the language you use follows a strict set of rules. The thinking is the same. The vocabulary is new.
Breaking problems into steps
Before writing any code, programmers think through what they're asking the computer to do — in plain language first. This is called pseudocode or "algorithm design" in textbooks. But it's really just planning.
▶ Planning before coding: checking if a number is even
Step 1 — In plain English: what do we want?
Result
We want to know if a number can be divided by 2 with no remainder.
Step 2 — What's our input?
Result
A number (e.g. the user types "6").
Step 3 — What's the decision we need to make?
Result
IF the number divided by 2 leaves no remainder, say "even". OTHERWISE say "odd".
Step 4 — What's our output?
Result
A word: "even" or "odd".
Step 5 — Now write it (same logic, different syntax per language)
Result
JavaScript: if (n % 2 === 0) { return "even" } else { return "odd" }
Python: "even" if n % 2 == 0 else "odd"Same idea. Different vocabulary. Like "I love you" vs "Je t'aime" vs "Te amo".
Try this
Before the next lesson, try writing instructions for a robot to make a cup of tea. Write every single step, including: where the kettle is, what "boiling" means, how full the cup should be, and how long to wait for the teabag. Notice how many steps seem obvious to you but would stump a literal machine.