DEV Community: Navas Herbert

Python Week 2: We Taught Python to Make Decisions

Navas Herbert — Mon, 25 May 2026 20:41:39 +0000

Last week, our programs were polite but passive. They'd take your name, store your age, print a receipt - but they couldn't respond to what you gave them. Every program ended the same way no matter what you typed.

This week, that changed.

Week 2 was about teaching Python to think. Or at least, to choose. We covered operators and conditionals - the building blocks that let a program look at a value and say: "based on this, I'll do one thing and not another."

It sounds small. It's not.

First: Operators - Asking Python Yes/No Questions

Before any if statement, students needed to understand comparison operators - the tools Python uses to evaluate whether something is true or false.

I framed it simply: an operator is just a question you ask Python. It always answers yes or no.

age = 20

print(age > 18)     # Is age greater than 18?
print(age == 20)    # Is age exactly 20?
print(age != 25)    # Is age NOT 25?
print(age >= 18)    # Is age 18 or older?
print(age <= 15)    # Is age 15 or younger?

True
True
True
True
False

Clean. Simple. Everyone got it immediately.

Then came the mistake I wait for every single cohort.

The Mistake Everyone Makes Exactly Once

age = 20

if age = 18:
    print("You are exactly 18")

SyntaxError: invalid syntax

"But I used equals?"

Right. And that's the problem. In Python, = means "store this value". == means "are these the same?" They look almost identical. They do completely different things.

age = 20          # ASSIGNMENT — put 20 in the box called age
age == 20         # COMPARISON — is age the same as 20? (True/False)

I told them: you will make this mistake. It will confuse you. You will stare at it for two minutes. Then you'll see the missing = and feel silly. That's normal. It happens to everyone, including people who've been coding for ten years.

After that, they started double-checking their equals signs. Good habit, hard-earned.

Logical Operators: Combining Questions

Sometimes one question isn't enough. We covered and, or, and not:

age = 22
has_id = True

# AND — both conditions must be True
if age >= 18 and has_id:
    print("Welcome in.")
else:
    print("Sorry, not tonight.")

Welcome in.

The analogy I used: a bouncer at a club in Westlands. They check your age and your ID. One isn't enough - both conditions have to pass or you're not getting in. and is the strict bouncer.

or is more relaxed:

is_student = False
has_discount_card = True

if is_student or has_discount_card:
    print("Discounted fare: KES 30")
else:
    print("Full fare: KES 50")

Discounted fare: KES 30

And not simply flips the answer:

is_raining = False

if not is_raining:
    print("No umbrella needed today.")

No umbrella needed today.

if / elif / else: The Decision Tree

Now the main event.

The structure is straightforward once you see it as a sequence of questions Python asks in order - stopping as soon as one is true:

score = 74

if score >= 80:
    print("Grade: A")
elif score >= 70:
    print("Grade: B")
elif score >= 60:
    print("Grade: C")
elif score >= 50:
    print("Grade: D")
else:
    print("Grade: F - please see your teacher")

Grade: B

Key rule I drilled in: Python checks from top to bottom and stops at the first True condition. It doesn't check the rest. This matters when conditions overlap:

score = 85

# WRONG — overlapping conditions, wrong order
if score >= 50:
    print("Grade: D")   # This fires for 85! Python stops here.
elif score >= 80:
    print("Grade: A")   # Never reached

Grade: D

Someone in the room got this wrong on their first attempt - which was exactly what I needed. We looked at the output together, traced through the logic, and found the bug. That exercise is worth more than five explanations.

The Moment That Got Everyone: The M-Pesa Checker

At the end of Week 1, I teased this program. This week we actually built it.

balance = float(input("Enter your M-Pesa balance (KES): "))

if balance >= 1000:
    print("✅ You're good. Send that money.")
elif balance >= 100:
    print("⚠️  Low balance — top up soon.")
elif balance > 0:
    print("❌ Very low. You can barely send a text.")
else:
    print("💀 Broke. Completely broke.")

One student - Otieno - typed 0 and got the last message. He laughed so hard the whole room started laughing. Then someone else typed their actual balance just to see what Python would tell them.

That's the moment. When the program stops being an exercise and becomes something they interact with. When they're not running code — they're using software.

After that, everyone wanted to build their own version.

Nested Conditions: An If Inside an If

Once students were comfortable with basic if/elif/else, we pushed further — what if the decision has layers?

age = int(input("Enter your age: "))
has_ticket = input("Do you have a ticket? (yes/no): ")

if age >= 18:
    if has_ticket == "yes":
        print("Enjoy the show! 🎬")
    else:
        print("You're old enough, but you need a ticket first.")
else:
    print("Sorry - this show is 18+.")

Enter your age: 22
Do you have a ticket? (yes/no): yes
Enjoy the show! 🎬

"You can put an if inside an if?"

Yes. And you can put one inside that one too - though I warned them: deeply nested conditions are a code smell. If you're four levels deep, step back and rethink. For now, two levels is fine.

We Built This Together: Matatu Fare Calculator

The session project. Students built this step by step, from scratch:

print("=== Nairobi Matatu Fare Calculator ===")

distance = float(input("Distance in km: "))
is_peak_hour = input("Is it peak hour? (yes/no): ")

# Base fare calculation
if distance <= 5:
    fare = 50
elif distance <= 15:
    fare = 100
elif distance <= 30:
    fare = 150
else:
    fare = 200

# Peak hour surcharge
if is_peak_hour == "yes":
    fare = fare * 1.5
    print(f"Peak hour surcharge applied.")

print(f"\nDistance: {distance} km")
print(f"Total fare: KES {fare:.0f}")

=== Nairobi Matatu Fare Calculator ===
Distance in km: 12
Is it peak hour? (yes/no): yes
Peak hour surcharge applied.

Distance: 12.0 km
Total fare: KES 150

What I loved about this exercise: students had to think about the real world to write correct code. What counts as peak hour? What if someone enters a negative distance? What if they type "YES" instead of "yes"? Those questions came up naturally - and they're exactly the kind of edge-case thinking that makes a good programmer.

Practice Problems

Try these yourself:

Easy:

# 1. Ask the user for a number. Print whether it's positive, negative, or zero.
# 2. Ask for two numbers. Print which one is larger (or "they're equal").
# 3. Ask for a temperature in Celsius. Print "Hot" if above 30, "Cold" if below 15, "Comfortable" otherwise.

Medium:

# A simple login checker
username = input("Enter username: ")
password = input("Enter password: ")

# Expected: username = "admin", password = "1234"
if username == "admin" and password == "1234":
    print("✅ Access granted. Welcome.")
elif username == "admin":
    print("❌ Wrong password.")
else:
    print("❌ Username not found.")

Challenge:

# Build a simple NHIF contribution calculator
# Rules (simplified):
# Gross salary < 5,999 → KES 150
# 6,000 – 7,999 → KES 300  
# 8,000 – 11,999 → KES 400
# 12,000 – 14,999 → KES 500
# 15,000 and above → KES 600

salary = float(input("Enter gross monthly salary (KES): "))
# Your if/elif/else here...

What I Noticed Teaching This Session

1. The = vs == error is a rite of passage - let it happen. Don't pre-warn students so much that they never make the mistake. Making it, reading the error, and fixing it themselves is how it sticks.

2. Real-world stakes make conditions more fun. The M-Pesa checker worked because students had an emotional relationship with their balance. Abstract exercises like if x > 5 don't carry that. Always anchor the condition in something that matters to them.

3. Students naturally found edge cases. Once they built the matatu calculator, they immediately started trying to break it — negative distances, letters instead of numbers. That curiosity is the beginning of a testing mindset. Don't discourage it.

4. elif takes a minute to click. A few students kept writing separate if statements instead of elif. I had to show them what goes wrong - multiple conditions firing for the same input - before they understood why elif exists.

I'm a data trainer in Nairobi running a full data programme —
Python foundations → Data Science or Data Engineering specialisations.
I write weekly about what we covered, what worked, and what surprised me.
Follow along or drop your questions in the comments.

Python Week 3: We Stopped Repeating Ourselves (Loops!)

Navas Herbert — Mon, 25 May 2026 20:22:12 +0000

I started this session with a challenge.

"Jose," I said, "print the names of all 40 students in this dataset - one per line."

He looked at me. Then at his keyboard. Then started typing print("Amina").

I let him get to the third name before I stopped him.

"What if there were 10,000 students?"

Silence.

"What if the list changed every week?"

More silence.

That's the setup for loops. You don't teach loops by explaining them - you first make people feel the pain of not having them. Then the solution lands differently.

The for Loop: Working Through a List

The for loop is Python's way of saying: go through every item in this collection and do something with each one.

My analogy: a class register. The teacher calls each name in order, marks attendance, moves to the next. They don't skip anyone. They don't stop early. They go through the whole list.

students = ["Amina", "Brian", "Njeri", "Kamau", "Wanjiku"]

for student in students:
    print(f"Good morning, {student}! 👋")

Good morning, Amina! 👋
Good morning, Brian! 👋
Good morning, Njeri! 👋
Good morning, Kamau! 👋
Good morning, Wanjiku! 👋

Five names. One loop. If the list had 10,000 names, same code - still works.

Jose closed his half-written print() statements and deleted them. That reaction is why I love teaching this session.

range(): Counting Without a List

Sometimes you don't have a list of items - you just want to repeat something a specific number of times. That's what range() is for.

for i in range(5):
    print(f"Attempt {i + 1}")

Attempt 1
Attempt 2
Attempt 3
Attempt 4
Attempt 5

Then came the question I wait for every cohort.

"Why does range(5) go from 0 to 4? Why not 1 to 5?"

Because Python counts like a programmer - starting from zero. range(5) means "give me 5 numbers starting at 0" - so 0, 1, 2, 3, 4.

If you want 1 to 5, you tell it explicitly:

for i in range(1, 6):
    print(i)

You can even count in steps:

# Count in 10s - like a matatu filling up every 10km
for km in range(0, 51, 10):
    print(f"Distance covered: {km} km")

Distance covered: 0 km
Distance covered: 10 km
Distance covered: 20 km
Distance covered: 30 km
Distance covered: 40 km
Distance covered: 50 km

Doing Real Work Inside a Loop

A loop is only useful if you do something meaningful inside it. We levelled up from printing names to processing data:

scores = [78, 45, 92, 61, 55, 88, 34, 73]
total = 0

for score in scores:
    total = total + score

average = total / len(scores)
print(f"Class average: {average:.1f}")

Class average: 65.8

Then we added a conditional inside the loop - finding students who failed:

scores = [78, 45, 92, 61, 55, 88, 34, 73]

print("Students who need support:")
for i in range(len(scores)):
    if scores[i] < 50:
        print(f"  Student {i + 1}: scored {scores[i]} - below pass mark")

Students who need support:
  Student 2: scored 45 - below pass mark
  Student 7: scored 34 - below pass mark

This is where students started to see it. A loop plus a conditional is already a mini data pipeline. You're iterating through records, applying a rule, flagging what matters.

The while Loop: Keep Going Until Something Changes

The for loop goes through a fixed collection. The while loop is different - it keeps running as long as a condition is true, and you don't always know in advance how many times that will be.

My analogy: a matatu waiting at the stage. It doesn't leave after a fixed number of passengers - it waits until it's full. While there's space, keep accepting passengers.

passengers = 0
capacity = 14

while passengers < capacity:
    passengers += 1
    print(f"Passenger {passengers} boards. Seats remaining: {capacity - passengers}")

print("Matatu is full. Twende!")

Passenger 1 boards. Seats remaining: 13
Passenger 2 boards. Seats remaining: 12
...
Passenger 14 boards. Seats remaining: 0
Matatu is full. Twende!

A more practical use - a simple login system that keeps asking until you get it right:

password = "lux2024"
attempts = 0

while True:
    entry = input("Enter password: ")
    attempts += 1

    if entry == password:
        print(f"✅ Access granted after {attempts} attempt(s).")
        break
    else:
        print("❌ Wrong password. Try again.")

Enter password: wrongpass
❌ Wrong password. Try again.
Enter password: lux2024
✅ Access granted after 2 attempt(s).

The Infinite Loop Nobody Saw Coming

This was the moment of the session.

One student - Aisha - was building the login checker and forgot the break. Her loop just kept asking for the password. Forever. Her laptop stopped responding to anything else.

"How do I stop it?!"

Ctrl + C. Always Ctrl + C.

She pressed it. The program stopped. The room exhaled.

I told everyone to write Ctrl + C at the top of their notes and circle it. It's the emergency exit for every infinite loop - and you will need it at some point. Better to learn it when Aisha accidentally teaches you than when you're alone at midnight wondering why your computer is hot.

The lesson from Aisha's loop: every while True must have a break inside it. Without a way out, the loop runs until you force-quit the program or your laptop gives up.

break and continue: Taking Control of the Loop

Once students understood that loops run to completion, I showed them two ways to interrupt that:

break - stop the loop entirely and exit:

# Search for a student in the register
register = ["Amina", "Brian", "Njeri", "Kamau", "Wanjiku"]
target = "Njeri"

for student in register:
    if student == target:
        print(f"Found {target}! ✅")
        break   # No need to keep searching
    print(f"Checking {student}...")

Checking Amina...
Checking Brian...
Found Njeri! ✅

continue - skip this item and move to the next one:

# Print all scores, but skip anyone who was absent (score = 0)
scores = [78, 0, 92, 0, 55, 88]

for score in scores:
    if score == 0:
        continue   # Skip absent students
    print(f"Score: {score}")

Score: 78
Score: 92
Score: 55
Score: 88

The analogy that landed for continue: a teacher calling the register and the student is absent. You don't stop the whole class - you just say "absent" and move to the next name.

Nested Loops: A Loop Inside a Loop

I saved this for the end - the concept that always gets a dramatic reaction.

# Multiplication table (3x3 preview)
for i in range(1, 4):
    for j in range(1, 4):
        print(f"{i} x {j} = {i * j}")
    print("---")

1 x 1 = 1
1 x 2 = 2
1 x 3 = 3
---
2 x 1 = 2
2 x 2 = 4
2 x 3 = 6
---
3 x 1 = 3
3 x 2 = 6
3 x 3 = 9
---

"The outer loop runs - and every time it does, the inner loop runs all the way through."

You could see people mentally tracing the logic. I gave them a minute to sit with it before moving on. Some concepts need a moment, not a faster explanation.

A practical example - checking every student against every subject:

students = ["Amina", "Brian", "Njeri"]
subjects = ["Maths", "English", "Science"]

for student in students:
    for subject in subjects:
        print(f"{student} → {subject}")
    print()

Amina → Maths
Amina → English
Amina → Science

Brian → Maths
Brian → English
Brian → Science

Njeri → Maths
Njeri → English
Njeri → Science

Practice Problems

Easy:

# 1. Print numbers 1 to 20 using a for loop and range()
# 2. Print only even numbers between 1 and 30
# 3. Loop through this list and print each item in uppercase:
#    groceries = ["unga", "sukari", "mafuta", "chumvi"]

Medium:

# A simple ATM PIN checker - give the user 3 attempts
correct_pin = "4821"
attempts = 0
max_attempts = 3

while attempts < max_attempts:
    pin = input("Enter your PIN: ")
    attempts += 1

    if pin == correct_pin:
        print("PIN accepted. Welcome.")
        break
    else:
        remaining = max_attempts - attempts
        if remaining > 0:
            print(f"Wrong PIN. {remaining} attempt(s) left.")
        else:
            print("Account locked. Please visit your branch.")

Challenge:

# Sales summary - loop through a list of daily sales,
# calculate total, find the highest day, count days below target

daily_sales = [12400, 8750, 15200, 6300, 19800, 11050, 9400]
target = 10000

# Your code here:
# 1. Total sales for the week
# 2. Best day (highest sales)
# 3. How many days missed the target

What I Noticed Teaching This Session

1. The pain-first setup works every time. Making Jose start writing 40 print() statements - even for just 3 names - made the loop feel like a rescue, not a concept.

2. Aisha's infinite loop was the best teaching moment of the week. An accident in front of the class, handled calmly, teaches Ctrl + C and loop safety more effectively than any slide ever could. I didn't plan it. I didn't need to.

3. Students started thinking like data people. When we looped through scores and flagged students below 50, someone said: "This is basically filtering - like SQL WHERE." That connection was electric. That's exactly what it is.

4. break and continue need contrast to make sense. Showing them without break (loop continues past the found item) before showing with break made the difference immediately visible.

What's Coming in Week 4: Functions

Right now our programs do things — but they can't remember how to do them. If we need to calculate a grade three times in different places, we write the logic three times. That's wrong.

Functions fix this:

def calculate_grade(score):
    if score >= 80:
        return "A"
    elif score >= 70:
        return "B"
    elif score >= 60:
        return "C"
    elif score >= 50:
        return "D"
    else:
        return "F"

print(calculate_grade(85))   # A
print(calculate_grade(62))   # C
print(calculate_grade(41))   # F

Write it once. Use it anywhere. That's next week.

Try It Yourself

Download Python 3
Download VS Code
This week's code on GitHub ← link coming soon

Start with the ATM PIN checker - it combines everything from Week 2 (conditionals) and Week 3 (while loops). If that runs cleanly, you're ready for functions.

I'm a data trainer in Nairobi running a full data programme -
Python foundations → Data Science or Data Engineering specialisations.
I write weekly about what we covered, what worked, and what surprised me.
Follow along or drop your questions in the comments.

We Switched From SQL to Python - Here's How Week 1 Went

Navas Herbert — Tue, 19 May 2026 19:14:34 +0000

Students just finished a full SQL journey - JOINs, window functions, CTEs, a hotel capstone dataset. They were dangerous with PostgreSQL. Confident. A little smug, even.

Then I told them we were switching to Python.

The energy in the room shifted. SQL felt structured - you ask a question, the table talks back. Python felt like a blank page. No table. No schema. Just a cursor blinking at you.

Week 1 was about changing that feeling. Here's exactly what we did.

First Question I Asked the Room

Before touching a keyboard, I asked everyone: "What do you think code actually is?"

Answers ranged from "instructions for a computer" to "I have no idea but it looks scary in movies."

Here's what I told them:

Code is just a very precise way of talking to a computer. The computer is not smart - it does exactly what you say, nothing more. Your job as a programmer is to be clear enough that it doesn't get confused.

That framing - the computer is not smart, you have to be precise - removes a lot of the intimidation. You're not learning to be a genius. You're learning to communicate clearly.

Setting Up: Python + VS Code

We installed Python 3 and VS Code. This part takes longer than it should with a full class (there's always one laptop that does something unexpected), but we got everyone running.

First file. First line of code:

print("Hello, Nairobi!")

Output:

Hello, Nairobi!

Simple. Silly, even. But I could see people smile when their computer actually said something back. That moment matters more than people realise - it's the first time the machine responds to them.

Variables: The Labelled Box Analogy

The first real concept: variables.

My analogy: imagine a variable is a labelled box. You put something inside the box, you write a name on the outside, and later you can pick up the box by its name and use whatever's inside.

name = "Amina"
age = 25
city = "Nairobi"

print(name)   # Amina
print(age)    # 25
print(city)   # Nairobi

Then we showed them that the box can be updated - the label stays the same but the content changes:

score = 40
print(score)   # 40

score = 85
print(score)   # 85

Someone asked: "So the old value just disappears?" Exactly. The box only holds one thing at a time. The new value replaces the old one.

Data Types: Not All Boxes Are The Same

Here's where it gets interesting. Python cares about what kind of thing you put in the box. We covered the four core types:

Type	Example	What it is
`int`	`42`	Whole numbers
`float`	`3.14`	Decimal numbers
`str`	`"Amina"`	Text (always in quotes)
`bool`	`True` / `False`	Yes or no — that's it

students = 30          # int
average_score = 74.5   # float
school_name = "Lux Academy"  # str
is_open = True         # bool

print(type(students))     # <class 'int'>
print(type(average_score))  # <class 'float'>
print(type(school_name))  # <class 'str'>
print(type(is_open))      # <class 'bool'>

The type() function became a favourite immediately. Students started wrapping everything in it just to check. Good habit, honestly.

The Mistake That Catches Everyone (And I Mean Everyone)

Mixing types without converting them first. This one gets everybody:

age = input("How old are you? ")
next_year = age + 1
print(next_year)

Error:

TypeError: can only concatenate str (not "int") to "str"

The confusion on their faces was real. "But I typed a number!"

Here's the thing: input() always returns a string, even if the user types 25. Python received the text "25", not the number 25. You have to tell it explicitly to treat it as a number:

age = int(input("How old are you? "))
next_year = age + 1
print("Next year you will be", next_year)

Output (if user types 25):

Next year you will be 26

This lesson - Python doesn't assume, you have to be explicit - is one of the most important mindset shifts for beginners. And once they've hit this error, they never forget it.

Type Conversion: Speaking Python's Language

We covered the three conversion tools they'll use constantly:

# String to integer
price_text = "250"
price = int(price_text)
print(price + 50)    # 300

# String to float
weight_text = "72.5"
weight = float(weight_text)
print(weight * 2)    # 145.0

# Number to string (for building sentences)
items = 5
message = "You have " + str(items) + " items in your cart"
print(message)       # You have 5 items in your cart

The last one - str() for building messages - connected immediately because we also introduced f-strings as a cleaner alternative:

name = "Brian"
balance = 4500
print(f"Hey {name}, your M-Pesa balance is KES {balance}")

Output:

Hey Brian, your M-Pesa balance is KES 4500

f-strings are technically Session 6 material but the students loved them so much I let it slide. Sometimes you follow the energy.

input(): Making Programs Interactive

input() is where things start feeling like actual software.

name = input("What is your name? ")
print(f"Welcome to the system, {name}!")

We built a small interactive program on the spot - a basic student registration prompt:

name = input("Enter student name: ")
age = int(input("Enter age: "))
course = input("Enter course: ")

print("--- Student Record ---")
print(f"Name:   {name}")
print(f"Age:    {age}")
print(f"Course: {course}")

Sample Run:

Enter student name: Wanjiku
Enter age: 23
Enter course: Data Engineering

--- Student Record ---
Name:   Wanjiku
Age:    23
Course: Data Engineering

This was the session highlight. Students went from writing print("Hello") to building something that takes input and structures a response - in one session. The room felt different after that exercise.

Practice Problems We Ran

A few of the exercises we worked through - try them yourself:

Easy:

# 1. Store your name, age, and city in variables. Print them.
# 2. Ask the user for two numbers and print their sum.
# 3. Use type() to check what type "3.14" is before and after float() conversion.

Medium:

# A kiosk receipt printer - ask for item name and price, print a formatted receipt
item = input("Item name: ")
price = float(input("Price (KES): "))
quantity = int(input("Quantity: "))

total = price * quantity
print(f"\n--- Receipt ---")
print(f"Item:     {item}")
print(f"Price:    KES {price}")
print(f"Qty:      {quantity}")
print(f"Total:    KES {total}")

Challenge:

# Temperature converter - ask user for Celsius, convert to Fahrenheit and Kelvin
celsius = float(input("Enter temperature in Celsius: "))
fahrenheit = (celsius * 9/5) + 32
kelvin = celsius + 273.15

print(f"{celsius}°C = {fahrenheit}°F = {kelvin}K")

What I Noticed Teaching This Session

The SQL background helped more than I expected. Students who came from our SQL class already understood the idea of data having types - a VARCHAR column vs an INT column. Python's str and int felt familiar. That prior context is genuinely useful.

input() is the best motivator at this stage. The second a program asks them a question and responds to their answer, it stops feeling like a tutorial and starts feeling like real software. Use it early and often.

The TypeError from input() is a gift. Don't avoid it -engineer it. Make students hit that error deliberately, read it, understand it, and fix it themselves. Error messages are information, not judgement.

What's Coming in Week 2

Next session: operators and conditionals. We'll teach Python to make decisions - if, elif, else - and build programs that respond differently depending on the input.

A little teaser for the students:

balance = float(input("Enter your M-Pesa balance: "))

if balance >= 1000:
    print("You're good to send money.")
elif balance >= 100:
    print("Low balance — top up soon.")
else:
    print("Insufficient balance.")

Suddenly Python isn't just printing things - it's thinking. See you next week.

Try It Yourself

All you need to follow along:

Download Python 3
Download VS Code
Create a file called week1.py, paste any example above, and run it

No setup complexity. No cloud accounts. Just Python and a text editor.

I'm a data trainer in Nairobi running a full data programme - Python foundations → Data Science or Data Engineering specialisations. I write weekly about what we covered, what worked, and what surprised me. Follow along or drop your questions in the comments , especially if you're teaching or learning Python from scratch.

I Taught SQL to Complete Beginners: Here's What Actually Happened

Navas Herbert — Sat, 16 May 2026 10:49:20 +0000

Let me set the scene.

A room full of people who had never written a single line of SQL in their lives. Some came from accounting. Some from operations. One person told me they still used Excel to track hospital records manually. And they were all looking at me like I was about to teach them magic.

Honestly? I kind of was.

This is my retrospective on our SQL journey - what we covered, what broke people's brains (in a good way), and the moments I realised teaching this stuff is genuinely one of the most fun things I do.

Where We Started: "What Even Is a Database?"

Before I could show anyone a SELECT statement, I had to answer the most fundamental question first: why does this exist?

My go-to analogy: a database is like a very organised filing cabinet. Each drawer is a table. Each folder inside the drawer is a row. Each label on the folder is a column. SQL is just the language you use to ask the filing cabinet questions.

Once that clicked, the first query felt almost anticlimactic - in a good way.

SELECT first_name, last_name
FROM students
WHERE grade = 'A';

"Wait… that's it?" Yes. That's it. The magic is in building from there.

Week 1: The Foundation (And the First Confused Faces)

We started with the basics - SELECT, WHERE, ORDER BY, GROUP BY, HAVING. We used a school dataset called Nairobi Academy (fictional Nairobi school - felt very local and relatable) and a hospital dataset called City Hospital.

The moment that got everyone: understanding the difference between WHERE and HAVING.

-- WHERE filters rows BEFORE grouping
SELECT department, COUNT(*) AS total_staff
FROM employees
WHERE status = 'Active'
GROUP BY department;

-- HAVING filters AFTER grouping
SELECT department, COUNT(*) AS total_staff
FROM employees
GROUP BY department
HAVING COUNT(*) > 5;

I used the analogy of a matatu route: WHERE is the conductor deciding who even boards the matatu. HAVING is checking at the destination who actually made it the whole way. That one landed really well.

The Thing That Broke Everyone (In the Best Way): JOINs

I won't lie - JOINs are where beginner SQL classes either soar or crash. I've seen it go both ways.

We covered:

INNER JOIN - only rows that match in both tables
LEFT JOIN - all rows from the left, matched where possible
RIGHT JOIN - all rows from the right
SELF JOIN - a table joining itself (yes, this is a thing)
LEFT JOIN + IS NULL - finding orphaned records

The self-join is always the one that causes dramatic pauses.

-- "Who is each employee's manager?" - same table, different roles
SELECT 
    e.first_name AS employee,
    m.first_name AS manager
FROM employees e
LEFT JOIN employees m ON e.manager_id = m.employee_id;

"Wait… it's joining to itself?"

Yes. Yes it is. Welcome to SQL.

Window Functions: When SQL Starts Feeling Like a Superpower

This is the week I could see people's eyes light up.

Window functions let you do calculations across rows without collapsing them into a group. We covered ROW_NUMBER, RANK, DENSE_RANK, NTILE, running averages with AVG OVER, and time-travel queries with LAG and LEAD.

-- Rank students by score within each class
SELECT 
    student_name,
    class,
    score,
    RANK() OVER (PARTITION BY class ORDER BY score DESC) AS class_rank
FROM results;

And LAG - the one that made the data analysts in the room go quiet for a moment before saying "oh wow":

-- Compare this month's sales to last month's
SELECT 
    month,
    total_sales,
    LAG(total_sales) OVER (ORDER BY month) AS previous_month,
    total_sales - LAG(total_sales) OVER (ORDER BY month) AS difference
FROM monthly_sales;

No subquery. No join. Just clean, readable SQL. This is the moment people stop thinking of SQL as "just for pulling data" and start seeing it as an analytical tool.

CTEs: Writing SQL Like a Human Being

Before CTEs, students were writing nested subqueries that looked like abstract art. Beautiful in theory, impossible to read three days later.

Common Table Expressions (WITH ... AS) changed everything.

-- Find students who scored above the class average
WITH class_averages AS (
    SELECT class, AVG(score) AS avg_score
    FROM results
    GROUP BY class
)
SELECT r.student_name, r.class, r.score
FROM results r
JOIN class_averages ca ON r.class = ca.class
WHERE r.score > ca.avg_score;

The rule I drilled in: write your CTEs like you're telling a story. First set up your averages, then filter against them. Each CTE is a chapter.

Data Cleaning: Where Reality Hits

Every SQL class eventually gets to the uncomfortable truth: real data is messy. Dirty, inconsistent, full of rogue spaces and names typed in ALL CAPS at 4pm on a Friday.

We built a dedicated dirty dataset and went to town with:

-- Standardise names that arrived inconsistently
UPDATE employees
SET 
    first_name = INITCAP(TRIM(first_name)),
    last_name = INITCAP(TRIM(last_name));

-- Strip non-numeric characters from phone numbers
UPDATE contacts
SET phone = REGEXP_REPLACE(phone, '[^0-9]', '', 'g');

-- Fill in missing values rather than leaving NULLs
SELECT 
    COALESCE(department, 'Unassigned') AS department
FROM employees;

Golden rule we repeated every cleaning session: always run a SELECT first before an UPDATE or DELETE. See exactly what you're about to change. Only then pull the trigger.

The Capstone: Tembo Hotel

The final project was set in Tembo Hotel - a fictional Nairobi hotel with ~285 rows of genuinely messy booking data. Students worked in groups to clean it, analyse it, and answer real business questions:

Which room types generate the most revenue?
Which months have the highest no-show rates?
Who are our repeat guests?

Watching groups go from "this data is a disaster" to producing clean queries with CTEs and window functions across a few sessions was something else.

What I Learned Teaching This

A few honest takeaways from being on the teaching side:

1. Analogies are not optional. Every concept needs a real-world anchor before any code appears. If you skip the analogy and go straight to syntax, you lose half the room.

2. Local context matters more than I expected. Using Nairobi names, M-Pesa examples, matatu analogies - students were visibly more engaged when the data felt like their world.

3. PostgreSQL is the right call for beginners. Clean syntax, no shortcuts, no backtick weirdness. If you learn PostgreSQL first, everything else makes sense later.

4. The moment someone writes their first CTE that actually works, they look different. Slightly smug. Entirely justified.

What's Next?

SQL was the foundation. Now we've moved into Python - same students, same energy, new language. We're building toward a full data programme where they'll split into Data Science and Data Engineering tracks.

I'll be writing about that journey too. Follow along if you're building something similar, learning from scratch yourself, or just enjoy watching beginners turn into dangerous analysts one query at a time.

See you next week.

I'm a data engineer in Nairobi. I write weekly about what I'm teaching, what's working, and what surprised me in the classroom. If you're a fellow trainer or a self-taught analyst, let's talk in the comments.

Making Africa Energy Data Accessible to LLMs - a Practical Guide

Navas Herbert — Sat, 16 May 2026 09:57:57 +0000

Introduction

As an AI enthusiast and trainer, I believe high-quality open data is essential for building useful language models and agents. This project - the "Africa Energy Data MCP" - wraps a public Africa Energy Data API and exposes it as MCP tools so LLMs (Claude, Cursor, etc.) can call them directly.

In this short guide you'll find a clear, step-by-step walkthrough for:

Setting up the project locally
Understanding the architecture
Connecting an MCP client (Claude / Cursor)
Running and testing the tools
Publishing options (brief)

Special thanks to my friend Denzel (dkkinyua) who developed the underlying API powering this project - check out his work here: https://github.com/dkkinyua/AfricaEnergyDataAPI/tree/main

Why this matters

LLMs become far more useful when they can call tools that fetch real data. This project makes historical electricity, energy and economic indicators for 54 African countries (2000–2022) trivially available to agents, with caching, retries and validation built in.

Quick highlights

Tools: get_electricity_data, get_energy_data, get_economic_data, check_api_health, list_countries
Tech: Python 3.11, httpx, mcp server, simple in-memory cache, structured logging
Containerization: Dockerfile + GitHub Actions example included

Step 1 - Get the code

Clone the repo and enter the project directory:

git clone https://github.com/Navashub/africa_energy_mcp.git
cd africa_energy_mcp

Step 2 - Install dependencies

Create a virtualenv and install requirements:

python -m venv venv
# Windows
venv\Scripts\activate
# macOS / Linux
source venv/bin/activate
pip install -r requirements.txt

Step 3 - Add your API key

Copy the example env file and paste your RapidAPI key from the API provider (Denzel's API or the RapidAPI listing):

cp .env.example .env
# edit .env and replace AFRICA_ENERGY_API_KEY with your key

Important: never commit .env or your API key to GitHub. The repo includes a .gitignore already.

Step 4 - Run the MCP server

Start the server locally:

py server.py

You should see structured logs on stderr indicating the MCP server initialized and registered tools. Leave this running — it listens on stdio for MCP clients.

Step 5 - Connect an MCP client (Claude / Cursor)

For local testing, point your MCP-capable client at the server.py process. Examples:

Claude Desktop (Windows) — edit %APPDATA%\Claude\claude_desktop_config.json and add:

{
  "mcpServers": {
    "africa-energy": {
      "command": "py",
      "args": ["D:\\mcp_projects\\africa_energy_mcp\\server.py"]
    }
  }
}

Cursor — add the equivalent mcp.servers entry in Cursor settings pointing to your local server.py.

Step 6 - Test useful queries

Start with discovery commands so you confirm connectivity:

"What countries are supported by the Africa Energy Data tool?" — should return the 54-country list (tool list_countries).
"Is the Africa Energy Data API online?" — check_api_health tool should return a health JSON.
Example: "Get electricity data for Kenya in 2022." — will call get_electricity_data and return JSON results.

If an endpoint returns a 500, that indicates the remote API backend failed — the error is on the API provider side. The MCP server will surface a clear error message in that case.

Architecture (brief)

server.py - MCP server that declares tools and routes calls
handlers.py - Input validation and mapping of tool arguments to API calls
api_client.py - httpx.AsyncClient wrapper with retries, 30s timeout, and a 10-minute in-memory cache
tools.py - Schemas for each MCP tool
config.py - Environment and constants (including the hardcoded list of 54 countries)

Containerization & CI

If you want remote hosting, the repo includes a Dockerfile and an example GitHub Actions workflow that builds and pushes a container to GHCR. Publishing requires a registry token — we added a workflow that prefers a GHCR_TOKEN secret or falls back to the repo GITHUB_TOKEN when allowed.

Acknowledgements

Huge thanks to Denzel (dkkinyua) for building the underlying Africa Energy Data API — please check his repository: https://github.com/dkkinyua/AfricaEnergyDataAPI/tree/main

Shout-out: This project was adapted and wrapped into an MCP server by an AI enthusiast and trainer (that’s me — Navashub) to make the data accessible to LLMs for education, research and production usage.

Best practices & tips

Keep your API keys secret - use .env locally and repository secrets for CI.
Test with list_countries and check_api_health before running large queries.
Increase REQUEST_TIMEOUT in config.py only if you know the backend requires more time.
For production hosting, use the Docker image and provide secrets through the host or the platform's secret mechanism.

Conclusion

Making structured, historical energy data available to LLMs unlocks better automated analysis, answers, and decision support. This project is a small but practical bridge - thanks to Denzel for the API and to you for exploring it.