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:
Top comments (0)