Commands Need a Receiver Imagine you are in a big, noisy school canteen. You shout across the room: "Can someone bring me a glass of water?" But nobody hears you. Or everyone is looking the other way. Or they hear something but cannot make out the words. No water comes. Your request was clear and specific — a good command. But nothing happened. Why? Because nobody received it. Both Sides of a Command Every command has two sides: The sender: the person or thing giving the instruction The receiver: the thing that hears, understands, and acts on it For a command to work, both sides must be working. A command with no receiver — or the wrong receiver — does nothing. Example Sender Receiver --- --- --- Pressing Volume Up on a remote You The TV Tapping play on Spotify You The Spotify app A microwave timer beeping The timer The buzzer A smoke alarm going off The smoke sensor The alarm circuit Every command in the table goes from a sender to a receiver. The receiver is the one that actually does something . The TV Remote, Up Close Here is how a TV remote actually works: 1. You press a button — say, Volume Up 2. The remote sends out a tiny burst of invisible infrared light 3. The pattern of that light burst means "Volume Up" — a different pattern for every button 4. The TV has a sensor on the front that watches for infrared signals 5. When the sensor receives the right pattern, the TV increases the volume If the sensor is covered, the signal cannot reach it. If you point the remote at the wall, the signal bounces the wrong way. If the battery is dead, no signal is sent at all. In every case — the command fails to reach its receiver. The receiver must be able to see the command. And it must understand it. What Makes a Good Receiver? For something to successfully receive a command, three things must be true: Requirement What It Means Example --- --- --- On and ready The receiver must be switched on and waiting A TV that is unplugged cannot receive remote commands Listening The receiver must be watching for commands The TV's infrared sensor is always on and watching Understands the language The command must use a format the receiver recognises A Samsung remote sends different patterns than a Sony remote — they may not understand each other The third one is especially important. Have you ever tried using your TV remote to control a completely different device — like pointing it at a fan? Nothing happens. Not because the signal is not there — but because the fan does not understand TV remote language. When the Receiver Says "I Don't Understand" Sometimes a command reaches its receiver, but the receiver cannot make sense of it. In a computer programme, this is called an error . The computer received your instruction — but it did not understand it, or could not carry it out. An error message is the computer's way of telling you: "I got your command, but I could not do it — here is why." This is actually helpful. An error is not a failure — it is the receiver communicating back to the sender. It is information you can use to fix the command and try again. The Receiver in Programming When you write a programme, the programme itself is the receiver. You write commands in a specific language — Python, JavaScript, Scratch, Swift — and the computer's interpreter reads those commands and carries them out. The interpreter is always listening, always ready to receive. This is why programming languages exist. They are the agreed-upon format that the computer's interpreter understands — the "language" of the receiver. If you write a command in English (like "add these two numbers together"), the interpreter does not understand it. But if you write it in Python ( ), the interpreter understands it perfectly and gives you 8. ✅ Summary A command only works when it reaches a receiver that is on, listening, and able to understand it. The TV remote needs the TV's sensor to be watching. A programme needs an interpreter that understands the language. When the chain breaks — the TV is off, the signal goes the wrong direction, the language is wrong — the command fails. Error messages are how receivers communicate back: "I received something, but I could not carry it out." A good programmer thinks about both the command they are sending and the receiver that will carry it out. Coming up next: Giving Good Commands — why being specific is everything, and what happens when a command is slightly off.