When building Python tools exposed the gaps in my understanding
If a professional programmer went through the Tech Journey section of the ObisDeck website, especially some of my earlier posts, perhaps they would have a little laugh.
I probably would too – even with the little I know now.
How does a complete beginner, without a technical background, design his own learning curriculum after watching a few tutorials, reading articles and following social media posts?
Well, I did exactly that.
I had to start somewhere.
I had no formal teacher in the traditional sense. Instead, I had tutorials, documentation and a collection of AI assistants such as ChatGPT, DeepSeek and others.
If you read my earlier post about “from fear to flow,” you will probably remember how this new form of what I called democratised learning treated me at the beginning.
It wasn’t always pretty.
But I kept going.
Building Tools Exposed Something
Looking back now, I would arrange my learning differently.
I had pushed through some of the fundamentals — variables, conditions, loops, functions and so on — and soon found myself building tools.
And I loved building them.
There is something satisfying about writing code and watching it organise files, search through records or perform some task that you previously had to do manually.
Eventually, I had built about twenty small tools.
That sounds like progress.
And it was.
But the tools also exposed something uncomfortable.
I discovered gaps in my understanding.
Despite everything I had learned and built, I still struggled to sit down independently and write even a small piece of code to organise some files on my computer.
I knew what a Boolean was — or at least I thought I did. But I had not really understood the difference between seeing True and False as Python syntax and understanding them as part of decision-making logic.
I had used loops many times, but could I explain exactly what was happening to one item as it passed through a loop?
Not really.
That realization confused me.
How could I have gone through so much learning, built all those tools, and still feel empty when faced with something basic?
For a while, I tried to fight through it.
Then I realised something that has become increasingly important to the way I learn:
You cannot force your way through learning.
You can force yourself to sit at the computer. You can force yourself to watch another tutorial. You can even force yourself to type another hundred lines of code.
But you cannot force understanding.
Understanding has to develop.
Sometimes confusion is not telling you to quit. It is telling you that something underneath needs more attention.
So instead of pushing forward, I went backwards.
My Deep Understanding Detour
After about my twentieth tool, I started what I now call my Deep Understanding Roadmap.
The questions became deliberately basic.
What exactly is a collection?
What is an item?
What is the object I am working with right now?
What happens when Python enters a for loop?
Suppose I have:
prices = [80, 250, 50, 400, 120]
for price in prices:
print(price)
Previously, I might simply have said:
“The loop prints the prices.”
Correct.
But I wanted to understand what was happening underneath that statement.
Python does not somehow deal with all five prices as one mysterious lump.
The loop takes one item from the collection at a time.
First:
price = 80
Then, on the next iteration:
price = 250
Then 50, then 400, then 120.
That simple realization became surprisingly important.
I started calling it the CURRENT OBJECT or current item.
Instead of staring at the entire program and becoming overwhelmed, I could ask:
What object is Python working with right now?
That question has helped me more than I expected.
A String Is Not a List
Another gap became clearer.
Sometimes I was working with text:
text = “report.pdf\nphoto.jpg\nnotes.txt”
That is a string.
Then I could do this:
records = text.splitlines()
Now records is a list containing separate strings.
The original string did not mysteriously “turn into” a list. The method splitlines() returned a new list, and I assigned that list to another variable.
Again, this may sound painfully basic to an experienced programmer.
But that is exactly the point of this journey.
Something can look basic after you understand it. Before you understand it, it can be the thing preventing ten other ideas from making sense.
Attributes, Methods and the Object at Hand
I also started paying more attention to attributes and methods.
Methods became easier to recognise because they are things we call, usually represented by the parentheses:
name.upper()
or:
names.append(“Ada”)
But then another important question appeared:
What kind of object do I currently have?
Different types of objects provide different methods.
For example:
name = “obi”
name.upper()
Here, name is a string, so I can use string methods such as .upper().
But:
names = [“Obi”, “Ada”]
names.append(“Chidi”)
Here, names is a list, and .append() is a list method.
Attributes are different. They give us information associated with an object, while methods are functionality we can call on an object.
For example, when working with a file path:
file.name
file.exists()
.name gives information about the path, while .exists() performs a check and returns an answer.
Once again, the object at hand matters.
I am beginning to understand why asking “What object am I dealing with?” is such an important programming habit.
Then Indentation Exposed Me
If there was one subject that showed me how incomplete my understanding still was, it was indentation.
I had been indenting Python code before.
Of course I had.
You cannot get very far in Python without doing it.
But there is a big difference between knowing that Python requires indentation and understanding what that indentation means structurally.
Consider:
prices = [80, 250, 50, 400, 120]
for price in prices:
print(price)
print(“Finished”)
There are five prices, so the first print() is reached five times — once for each current item.
But:
print(“Finished”)
is outside the loop.
It is reached after the loop has finished.
Now consider:
for price in prices:
if price > 100:
print(price)
Something different is happening.
The for loop still visits all five prices.
All five.
But print(price) does not necessarily run five times because there is now a question standing between the current item and the action:
if price > 100:
That was a major realization for me.
FOR decides which item we are currently working on. IF asks whether a particular action should apply to that current item.
And indentation shows which instructions belong to which block.
I had previously written code where files accumulated in the wrong place or actions happened more times than I expected because I had placed a statement inside a loop when, logically, it belonged outside it.
The indentation was not decoration.
It was structure.
One sentence now helps me think about it:
Indentation helps determine when and how often an instruction can be reached; the instruction itself determines what happens when it is reached.
Suddenly, some of my earlier mistakes started making sense.
Then True and False Stopped Being Just Syntax
This brought me to one of my biggest misunderstandings: Boolean values.
I knew these:
True
False
But knowing their names is not the same as understanding why Python needs them.
Why should True and False matter so much?
Then I began thinking about them as answers to questions.
Suppose:
colour = “red”
Python can be asked:
colour == “red”
The answer is:
True
The colour itself is not True.
The question — or, more accurately, the expression — evaluates to True.
That distinction was important.
The same thing happens with numbers:
price = 250
price > 100
Python evaluates that expression as:
True
But:
price < 100
evaluates to:
False
Now I could see what Boolean values were doing.
They were not just strange words Python wanted me to memorise.
They were helping Python make decisions.
And Now Filtering Makes More Sense
Once I understood that, filtering started looking different too.
Take this:
prices = [80, 250, 50, 400, 120]
for price in prices:
if price > 100:
print(price)
The for loop visits every price.
The if statement asks the same question about each current price:
Is this price greater than 100?
For 80:
80 > 100
False.
No print.
For 250:
250 > 100
True.
Print it.
Then Python moves to the next current item and asks the question again.
That gave me a much clearer picture of filtering.
An if statement is not only for filtering — conditional logic can be used for many kinds of decisions — but filtering is one powerful thing we can build with it.
And I can now see a simple chain:
CURRENT ITEM → QUESTION → TRUE/FALSE → DECISION → ACTION
That little chain explains much more to me now than simply memorising the syntax of an if statement.
Confusion Does Not Always Mean You Are Failing
This detour has changed the way I look at confusion.
There was a time when becoming confused made me feel that perhaps I was not getting it.
Now I see it differently.
Sometimes confusion is a signal.
It can mean:
Slow down. There is something here you have used without fully understanding.
That does not mean every confusing subject requires abandoning what you are doing and starting from zero.
But sometimes recalibration is necessary.
Mine certainly was.
Going back to the fundamentals after building twenty tools could look like going backwards.
For me, it has been the opposite.
I am beginning to understand some of the code I had previously only learned how to use.
And the confidence is returning — but it is a different kind of confidence.
Not the confidence of “I have seen this before.”
More like:
“I think I can explain what Python is doing here.”
That distinction matters to me.
The Journey Is Still Ongoing
I am certainly not finished with this Deep Understanding Roadmap.
In fact, another interesting door has already opened.
What happens when we write:
found = False
before a loop?
What happens if something is found and we change it to:
found = True
Does that True survive when the loop moves to an item that does not match?
Why would I use:
found = False
in one situation,
a list:
matches = []
in another,
and a counter:
count = 0
in another?
These are the questions I am working through now.
And in the next episode of my Tech Journey, I will share what I am discovering about state, found, lists and counters — and how these very basic ideas are beginning to help me understand the small file-organisation programs on my own computer.
Twenty tools later, I went back to the beginning.
It turns out that going backwards was sometimes exactly what I needed to move forward.
Because one lesson is becoming clearer the longer I learn:
You cannot force your way through learning.
You can give it time.
You can practise.
You can question what you thought you understood.
You can go back when necessary.
But understanding has its own process.
And sometimes the moment you stop fighting that process is the moment things begin to make sense.
