DEV Community: Tehreem Fatima

Building the Higher or Lower Game: A Fun Way to Practice Python Fundamentals

Tehreem Fatima — Sat, 12 Sep 2026 09:37:23 +0000

Introduction

I'm on Day 14 of Dr. Angela Yu's "100 Days of Code" course, and today I built something that was actually fun to play with while learning Python concepts. The game is simple: compare Instagram followers between two celebrities and guess who has more. It sounds easy, but building it taught me valuable lessons about data structures, game logic, and user experience.

GitHub Repo: Higher or Lower Game

What I Built

A command-line game where:

The computer randomly picks two celebrities/brands/athletes
You see their name, profession, and country
You guess who has more Instagram followers (A or B)
You keep playing and building your score until you guess wrong
One wrong guess ends the game

Simple concept. But the code behind it? That's where the learning happens.

The Data Structure Challenge

This project introduced me to a data structure I hadn't really used deeply before: a list of dictionaries.

data = [
    {
        'name': 'Cristiano Ronaldo',
        'follower_count': 215,
        'description': 'Footballer',
        'country': 'Portugal'
    },
    # ... 50+ more profiles
]

This is different from my previous projects. In my student management system, I used a dictionary with student names as keys. Here, I'm working with a list of dictionaries—each entry is independent, and I randomly pick from the list.

The difference matters:

Dictionary with keys: Great for lookups by name
List of dictionaries: Better for iterating, random selection, collections of similar data

This is a subtle but important distinction that will come up a lot in real-world programming.

Game Logic: The Interesting Part

The core logic has three steps:

Step 1: Format and Display
I created a format_participant() function to display each profile consistently:

f"{data['name']}, a {data['description']}, from {data['country']}"

Clean, reusable, easy to read.

Step 2: Compare Followers
The follower_count() function compares two participants and returns who has more followers:

if participant1["follower_count"] > participant2["follower_count"]:
    return participant1
else:
    return participant2

Simple comparison logic, but it's the heart of the game.

Step 3: Check User's Guess
The compare() function maps the user's input (A or B) to the actual participant objects:

if guess == "A":
    user_choice = participant1
else:
    user_choice = participant2

Then I compare if the user chose correctly.

What Made This Different from My Previous Projects

Before: I built management systems (student tracker, book store, pharmacy inventory)

This: I built a game

Management systems are CRUD (Create, Read, Update, Delete). They follow a predictable pattern. Games require different thinking:

Win/lose conditions
Score tracking
Continuous flow until failure
User engagement and fun

This project made me think about user experience, not just functionality.

What I Learned

1. Random Selection and Game Flow

participant2 = random.choice(data)
while participant2 == participant1:
    participant2 = random.choice(data)

I had to ensure the two participants are always different. This is a common pattern: keep trying until you get a valid result.

2. Breaking Logic Into Functions

Instead of one massive game loop, I separated concerns:

Formatting display
Comparing values
Mapping user input
Running the game

Each function does ONE thing. When something goes wrong, I know exactly where to look.

3. Input Validation Without Crashing

while guess != "A" and guess != "B":
    guess = input("You type incorrect value. Type 'A' or 'B': ").strip().title()

This loop ensures the user enters valid input before proceeding. No crashes, just re-asking.

4. Screen Management

print("\n" * 25)  # Clear screen

Small detail, but it makes the game feel polished. After each round, the screen clears so it doesn't get cluttered.

The Difference Between Theory and Practice

When I first learned about functions, it seemed abstract. "Why break code into functions?"

Building this game, I felt the difference:

If the display format changes, I update ONE function (format_participant())
If the comparison logic needs to change, I update ONE function (follower_count())
If I want to add a new feature, I know where to add it

This is why professional developers structure code this way. It's not just about looking good—it's about maintainability.

What Surprised Me

I thought building a game would be harder. But because I:

Separated concerns into functions
Validated input properly
Thought about the flow before coding

...it came together quickly and worked on the first try.

The surprise wasn't that it was easy. The surprise was that good planning makes coding easy.

Next Steps

This game works, but here's what I could add:

Save high scores to a file
Add difficulty levels
Track statistics (correct answers, most guessed celebrity)
Implement a leaderboard
Add more celebrities

But for now, I'm happy with v1.0.0.

What This Taught Me About Learning

I'm 14 days into a 100-day journey. I've built 10+ projects. I'm not a professional—I'm still a beginner.

But I'm noticing something: the more I build, the faster I learn.

When I started, writing functions felt tedious. Now, I naturally break problems into functions before I start coding.

When I started, validation seemed annoying. Now, I automatically add it.

This is how learning works. Not through tutorials, but through building things and seeing patterns emerge.

Challenge to Other Learners

If you're learning to code:

Don't just watch tutorials
Build projects that interest YOU
Don't aim for perfection—aim for "working"
Break your code into functions
Think about the user experience, not just the code

I built this game because I thought it would be fun. And it was. That engagement matters more than any tutorial.

Let's Connect

If you're also learning to code, I'd love to hear about your journey. What projects are you building? What surprised you most about learning to code?

Drop a comment below!

Project Links:

Author: Tehreem Fatima

Learning Journey: Day 14 of 100 Days of Code

Current Focus: Python Fundamentals & Project-Based Learning

My Python Learning Journey: Refactoring My Hangman Game from v1.0 to v2.0

Tehreem Fatima — Wed, 02 Sep 2026 12:14:29 +0000

This is the first post in my Python learning journey, where I document what I'm learning, what I'm building, the mistakes I make, and how my code improves over time.

A Little About Me

I'm currently studying Biomedical Engineering Technology, and I've been learning Python alongside my studies because I want to develop strong programming skills and build practical projects during my degree.

I'm still a beginner. I haven't been programming for years, and I'm not trying to present myself as an experienced developer. My goal is much simpler:

Learn → Build → Make mistakes → Improve → Repeat.

Instead of only completing tutorials, I've been trying to build small projects to actually apply what I learn. So far, I've worked with variables, conditionals, loops, lists, strings, dictionaries, functions, randomization, and sets.

One of my first real projects was a simple Hangman game. And then I decided to refactor it.

My Hangman Game — v1.0

My first version was written mostly as one continuous program.

It worked. I could:

Randomly select a word
Display blanks for the letters
Allow the player to guess letters
Track lives
Display Hangman stages
Reveal correctly guessed letters
Determine whether the player won or lost

At this stage, my main focus was simply getting the program to work. And honestly, that's an important stage when you're learning. I wasn't thinking deeply about software architecture. I was thinking:

"Can I make this work?"

The answer was yes. But once I looked at the program again, I started noticing something: the code was becoming difficult to manage.

The Problem With My First Version

As I added more functionality, the program became longer and harder to reason about. Different responsibilities were mixed together:

Choosing a word
Getting user input
Validating input
Updating the hidden word
Tracking lives
Checking whether the player won
Displaying messages

Everything was happening in the main game loop. This worked for a small project, but I started asking myself:

"What if I want to change one particular part of the game?"

For example, what if I wanted to improve input validation? I would have to dig through the larger program to find that logic.

That's when I realized: making a program work and structuring a program well are two different things.

So I decided to refactor it.

Refactoring Hangman — v2.0

For version 2.0, my main goal was to break the program into smaller functions.

Instead of one large block of code responsible for everything, I separated different responsibilities:

def generating_word(words_list):
    # Selects a random word

def generating_blanks(choosen_word):
    # Creates blank display

def getting_input():
    # Gets player input

def input_validation(guess_letter):
    # Validates input

def replacing_blanks(word, choosen_word, guess_letter, i):
    # Updates word with correct guesses

def game_win_lose(choosen_word, word, remaining_lives, guess_letter):
    # Checks win/lose conditions

This made the structure much easier to understand. Instead of one large program, I could look at individual pieces and understand what each one was supposed to do.

Adding Input Validation

Previously, the program could receive input like "hello" when it should only accept a single letter. So I added validation to ensure:

Exactly one character
An alphabetic character

This was a small addition, but it taught me something important: user input cannot always be trusted to be valid.

Preventing Duplicate Guesses

I added tracking for previously guessed letters using a Python set:

guessed_letters = set()

if guess_letter in guessed_letters:
    print("You already guessed that letter!")

This was a good practical example of learning a data structure and actually using it in a real project, rather than just doing exercises.

Breaking the Game Into Responsibilities

My v2.0 structure now looks like:

main()
  ↓
play_game()
  ├── generating_word()
  ├── generating_blanks()
  ├── getting_input()
  ├── input_validation()
  ├── replacing_blanks()
  └── game_win_lose()

This is one of the biggest things I learned from this project. A function shouldn't just exist because "functions are good." It should have a clear responsibility.

What I Learned From the Refactoring

The biggest lesson wasn't about syntax. It was about thinking differently about code.

When I first started programming, I mostly focused on:

"Does my code work?"

Now I'm slowly learning to ask:

"Is my code organized?"
"Can I understand it later?"
"Can I change one part without breaking everything?"
"Does each function have a clear purpose?"

I definitely still have a lot to learn, but I think this project was an important step in that direction.

What I Still Need to Improve

My Hangman v2.0 isn't perfect. There are still things I can improve:

Being more careful about when to validate input versus when to store it
Removing unnecessary return values
Better error handling

These are small things, but that's exactly why I'm documenting them. I don't want to only show the final version and pretend I knew everything from the beginning. The mistakes are part of the learning process.

v1.0 → v2.0: The Progression

Version	Main Focus
v1.0	Make the game work
v2.0	Improve structure and reliability
Future	Further improvements as I learn

v1.0 taught me how to build the game.

v2.0 taught me how to think about improving the code.

And I think that difference is important.

The Biggest Takeaway

If I had to summarize what this project taught me in one sentence, it would be this:

The most important part of learning to code isn't writing code that works—it's writing code that you (and others) can understand, maintain, and improve.

This shift in thinking will probably make more of a difference in my programming journey than any specific syntax I've learned.

What's Next?

I'm continuing my Python journey by building more projects rather than only following tutorials. My goal isn't to rush through Python topics—it's to understand concepts well enough that I can approach new problems with confidence.

There will probably be plenty of bugs, bad code, rewrites, and moments where I wonder why something isn't working. But that's part of learning.

I'll be documenting this journey here.

This is only the beginning.

Let's Connect

If you're also learning to code, I'd love to hear about your journey! What projects are you building? What mistakes are you making? Drop a comment below—I promise I'm making plenty of my own.

Project Links: