Operators, and how a program makes up its mind

This morning I stood at my door holding an umbrella, deciding whether to take it. The sky was grey but not dark. The weather app said sixty percent chance of rain. I took it anyway, because being wrong about rain is worse than carrying an extra thing.

That little pause is what a program does every time it runs an if statement. It looks at what it knows, weighs a small question, and picks a path. Until you teach a program to do that, it can only march straight through its instructions like a person reading a recipe without ever checking whether the oven is on.

Why a program needs to make decisions

A program that prints "hello" five times does the same thing every run. That's fine for a first day, but it's not what software is for.

The interesting programs branch. A login form behaves differently depending on whether your password is right. A trotro app shows a different route depending on where you're standing. A calculator only adds when you press plus. Every one of those choices, somewhere under the hood, is an if.

Without if, your code is a list. With if, your code is a decision tree — and almost every real problem worth solving is shaped like a tree. You are about to stop writing recipes and start writing reasoning.

The math you already know, and the two you don't

Most arithmetic in Python looks exactly like what you learned in JHS. Same symbols, same rules.

print(3 + 4)     # 7
print(10 - 5)    # 5
print(6 * 7)     # 42
print(20 / 3)    # 6.666...

Two operators are new. Say I have GHS 100 and four of us want to share it in whole cedis — no coins, no change. How many whole cedis does each person get, and how much is left over?

money = 100
people = 4
 
each = money // people      # 25  — full cedis per person
leftover = money % people   # 0   — what didn't divide evenly

// is integer division — "how many full bags fit?" % (read it as "modulo") answers "what's left after you fill the bags?" Change money to 103 and you'll get 25 each and 3 left over. You'll reach for that leftover number more often than you'd guess — checking if something divides evenly, wrapping a counter around, picking every third row.

The question mark and the command

This is the single most common crash I see in week one.

= is a command. == is a question.

gpa = 3.5 tells Python: "from now on, the box called gpa holds 3.5." It's an instruction. There's no true or false involved.

gpa == 3.5 asks Python: "is the value in gpa equal to 3.5?" Python answers with True or False.

Why two equals signs for the question? Because one was already taken. The earliest programming languages used = for assignment, so by the time anyone needed an "are these equal?" operator, the single equals sign was busy. == got the job.

gpa = 3.7         # command: put 3.7 into gpa
print(gpa == 4.0) # question: is gpa equal to 4.0?  -> False
print(gpa >= 3.5) # question: is gpa at least 3.5?  -> True

If you ever write if gpa = 3.5: Python will stop you immediately. That's a good error to get — it means the language caught your slip before it became a bug.

Asking two questions at once

Most real decisions aren't single questions. Think of a doorman at an event in Accra. He checks: do you have a ticket and are you on the list? Both need to be true. That's and.

A more relaxed doorman might ask: are you a regular or do you know the manager? Either one is enough. That's or.

Sometimes you flip a check on its head — "let anyone in who is not on the banned list." That's not.

has_ticket = True
age = 22
 
if has_ticket and age >= 18:
    print("Come in.")
 
if has_ticket or knows_the_manager:
    print("Alright, come in.")
 
if not on_banned_list:
    print("You're fine.")

The rules, in plain English:

• and needs both sides to be true.
• or needs at least one side to be true.
• not flips true to false and false to true.

When you start combining them, wrap each question in parentheses. Don't make Python guess what you meant.

The decision tree, drawn on paper

Before you write a single if, take a pen and draw the decision on paper. A box with the question, an arrow left for "yes," an arrow right for "no," and what happens at the end of each. If you can draw it, you can code it. If you can't draw it, you don't understand the problem yet.

Here is a small program that picks one of three messages based on a score:

score = int(input("Your score out of 100: "))
 
if score >= 80:
    print("Strong — top tier.")
elif score >= 60:
    print("Solid — middle tier.")
else:
    print("Keep pushing — there's room to grow.")

Run that with a score of 92. Now 65. Now 40. Notice that exactly one message prints each time, never two. That is the whole point of if / elif / else — it's a fork in the road, not a checklist.

Two things to lock in:

The first true branch wins. Python checks top to bottom and stops at the first match. If you flipped the order and put if score >= 60 above if score >= 80, a 92 would still be told "middle tier" — because 92 is already greater than 60 and Python would never look further. Order is part of the logic, not decoration.

else is the safety net. It catches everything you didn't handle. Forget it, and a value that matches none of your branches slips through silently.

Take this with you

You are not learning operators. You are learning how to teach a machine to pause at the door and decide whether to take the umbrella. The arithmetic is the easy part — everyone gets + and -. The real shift is realising that == is a question, that and and or come straight from how you already talk about rules, and that an if ladder is just a flowchart you happened to type instead of draw. Once that clicks, every program you write from here on will have a small mind of its own.