Category Archives: Getting Started

I Had to Unlearn How I Was Taught to Learn

For a long time, I thought I was struggling with tech.

HTML felt manageable.
CSS eventually made sense.
JavaScript, however, felt unnecessarily hard.

At first, I blamed myself.

I assumed I am stuck in my root-Arts…Literature and later Political science and Public administration.
Or that I had started too late.
Or that maybe this kind of learning just wasn’t for people like me- Those who dread maths.

But with time — and reflection — I realized something deeper:

I wasn’t struggling with technology.
I was struggling with how I had been taught to learn.

Like many in my era, I grew up learning in a very traditional way.

You sit in a classroom.
A teacher explains.
You take notes.
You memorize.
You repeat.

Progress is visible because:

  • the teacher controls the pace,
  • the curriculum is fixed,
  • and success is measured by exams and grades.

You are rarely asked to decide what to learn next, how and when.
You are rarely asked to diagnose your own confusion. The liberty of thereof is missing.
And you are almost never taught how to learn independently. Sitting behind some machine, taking tutorials from YouTube or scavenging websites for facts took time to deepen.

The old traditional system works — until it doesn’t.

When I moved into online learning, I carried those same expectations with me.

I expected:

  • clear instructions,
  • linear progression,
  • someone to tell me when I was “ready” to move on.

But online learning doesn’t work that way.

There is no teacher watching.
No classroom structure.
No one checking your understanding.

You are the pace-setter.
You are the problem-solver.
You are the feedback system.

And that shift is not small.

What made things harder was that I didn’t recognise this gap immediately. No Exams at the end of a session to determine if you go further. No validation, no permission. Only you and the freedom to explore the infinite body of knowledge that internet placed on your fingers.

So when tutorials didn’t flow, I thought the problem was the material.
When concepts didn’t stick, I thought the problem was me. The baggage of the traditional way of learning and the modern way that beckons became a sort of internal conflict. How do I appropriate the freedom that modernity provides. That independence is where the confusion rests.

I kept consuming content — videos, articles, explanations — believing that more input would lead to clarity.

It rarely did.

What I was missing wasn’t information.
It was learning autonomy.

Online learning demands something traditional education rarely trains you for:

  • deciding what matters,
  • pausing when confused,
  • experimenting without permission,
  • and accepting that progress may feel invisible for a while.

That was uncomfortable.

It felt like learning without guardrails.

The turning point came when I stopped forcing myself to learn the way I was taught in school.

I stopped waiting to be “taught.”
I started allowing myself to explore.

Small projects.
Simple experiments.
Trial and error without judgment.

That’s when things began to change.

I began to realize that learning online isn’t about following instructions perfectly.

It’s about:

  • building intuition,
  • asking better questions,
  • and noticing patterns over time.

It’s messy.
It’s nonlinear.
And it requires patience with yourself.

Once I accepted that, the pressure eased.

Looking back now, I see that unlearning how I was taught to learn was harder than learning tech itself.

But it was also freeing.

It allowed me to:

  • slow down without guilt,
  • take responsibility for my progress,
  • and trust that understanding would come — even if it took longer than expected.

The old is sluggish to change but the mind is never old. That is where dream resides; where conjectures and imaginations forms. If you can reach anything there, you can achieve it. So if you are learning tech as an adult and feeling stuck, overwhelmed, or quietly frustrated, it may not be because you are incapable. You may simply need to guide your mind and the next step may just be the learning model.

You may simply be using the wrong learning model.

And once that realization clicks, everything changes.

This post is part of my ongoing learning archive.
→ My Tech Learning Journey — One Step at a Time

I am not an expert. I am a student learning, building, and documenting the process as it unfolds. everything you see here is part of that journey.

far from being an expert. I am just a student willing to learn with you. that is why your comments are very important for me. You need login to drop a comment — just drop your name and share your thoughts below 👇

If you are learning too, your voice matters.

Share your thoughts below and let’s grow through this together.

(You do not need to log in to comment — just drop your name and join the conversation.)

The First Time Code Started Making Sense

After working through a few small Python projects, something subtle began to change.

Not suddenly.
Not dramatically.

But noticeably.

For the first time, I wasn’t just typing code.

I was beginning to understand it.

From Guessing to Seeing

Before this point, most of what I did felt like guessing.

  • Try something
  • Run it
  • Fix errors
  • Repeat

Sometimes it worked.
Most times, I wasn’t sure why it worked.

But then, something shifted.

Patterns Started Appearing

I began to notice small patterns:

  • Input comes in
  • It gets stored
  • Something happens to it
  • Then it produces a result

This wasn’t theory anymore.

I could see it happening.

Code Became Predictable

That was the real turning point.

Instead of hoping the code would work…

I started expecting what it would do.

Even when I made mistakes, I could now trace:

“This is where it went wrong”

Understanding Over Memorization

I wasn’t memorizing syntax anymore.

I was thinking in steps:

  • What do I want?
  • What data do I need?
  • What should happen to it?

That shift—from memorizing to thinking—changed everything.

The Role of Simple Projects

Looking back, it wasn’t complex projects that helped me reach this point.

It was the simple ones.

The Mad Libs project.
The small scripts.
The repeated practice.

They built something quietly:

confidence through clarity

A Different Kind of Progress

This stage didn’t feel like progress in the usual sense.

There were no big achievements.
No impressive outputs.

But internally, something important happened:

Things started connecting.

What I Learned From This Stage

  • Understanding grows slowly, not suddenly
  • Small projects are powerful
  • Repetition builds clarity
  • Logic is something you develop—not something you memorize

Where This Leads Next

Now, a new challenge begins.

Not writing code…

But understanding errors.

Because the next real skill is not getting it right the first time—

It’s knowing what to do when things go wrong.

Tech Journey — Season 1, Episode 10

Stage: Logic, Errors & the Terminal

How a Simple Python Mad Libs Project Changed Everything

After I pivoted to Python, something interesting happened. I had tried to familiarise myself with its language which sounded much more like English than the rest I had seen. That was a breath of fresh air, after the JavaScripts shivers.

So I feel in love with the simplistic nature of the Python language and more instructive is that I didn’t begin with something impressive.
No dashboards.
No automation tools.
No complex algorithms.

I wasn’t looking for something complex anymore.
I was looking for something that made sense.

And that’s when I found a simple project…

A simple Mad Libs story generator.

It looked too basic to matter. Almost playful.

But it changed everything.

At first glance, it felt too basic—almost childish. The kind of thing you might overlook while chasing “serious” coding projects. But something about it drew me in. Like a quiet invitation I didn’t expect, yet couldn’t ignore.

And when I accepted it, everything changed.

The Project That Didn’t Look Important

The idea was simple:

  • Ask the user for a few words
  • Plug those words into a story
  • Print the result

That was it.

No complexity. No sophistication.

But beneath that simplicity was something powerful—something I didn’t fully understand until I started building it.

What It Taught Me (Without Trying Too Hard)

That small project opened a door I didn’t even know existed.

For the first time, I began to truly see how programming works:

  • Input flows into logic
    What the user enters isn’t just data—it becomes part of the program’s behavior.
  • Decisions affect outcomes
    A small change in input completely transforms the result.
  • Code tells a story—step by step
    Each line has a purpose. Each instruction moves the story forward.

And suddenly, programming stopped feeling abstract.

From Confusion to Clarity

Before this, Python felt like a collection of rules I needed to memorize:

  • Syntax
  • Keywords
  • Structures

But with Mad Libs, something shifted.

I wasn’t just writing code anymore.

I was thinking in code.

I could see how scattered pieces—inputs, variables, print statements—came together to form something meaningful. Something interactive. Something alive.

At the click of a button, a complete story appeared.

And I understood why.

The Unexpected Motivation

At first, the output was amusing. Even silly.

But that “silliness” became fuel.

I found myself wanting to improve it:

  • Add better prompts
  • Make the stories funnier
  • Share it with my kids

Yes… my kids. Jordy would love this, I thought. And so would Stephanie.

It may sound childish—but that was the turning point.

Because now, I wasn’t learning Python just for the sake of learning.
I was learning so I could create something enjoyable and shareable.

That changed everything.

Why This Project Mattered So Much

Looking back, that simple Mad Libs project was more than just a beginner exercise.

It was my breakthrough moment.

Not because it was complex—
but because it was clear.

Not because it impressed anyone—
but because it made sense to me.

And in learning, that’s what truly matters.

Simple Python Mad Libs Story

print(“Let’s create a fun story! 🎉\n”)

name = input(“Enter a name: “)
place = input(“Enter a place: “)
adjective = input(“Enter an adjective: “)
action = input(“Enter an action (verb): “)
object_item = input(“Enter an object: “)

print(“\nHere is your story:\n”)

story = f”””
One day, {name} went to {place}.
It was a very {adjective} day.

Suddenly, {name} decided to {action} with a {object_item}.
No one expected it—but it turned out amazing!

And that was the beginning of something special.
“””

print(story)

You can copy the above code and try it in yourself on VSCODE

A Lesson for Anyone Starting Out

If you’re just beginning your tech journey, don’t underestimate simple projects.

The ones that look “too easy” are often the ones that:

  • Build your confidence
  • Strengthen your understanding
  • Change how you think

You don’t need to start big.

You need to start clear.

Final Thought

That little Mad Libs script didn’t just teach me Python.

It taught me how to think.And sometimes, that’s all it takes—
one small, simple project
to change everything.

This post is part of my ongoing learning archive.
→ My Tech Learning Journey — One Step at a Time

No login needed to drop a comment — just drop your name and share your thoughts below 👇

Why I Pivoted from JavaScript to Python — And What It Taught Me About Learning Tech

Introduction

Learning technology often looks simple from the outside. or so it seemed for me at a time.

Many people watch videos, read tutorials, and believe that programming is just about memorizing a few commands and writing lines of code. I also started my journey with a similar expectation.

At the beginning, everything felt exciting and clear. But at some point in the journey, I encountered something that many beginners eventually face — what I now call “The JavaScript Wall.”

This experience taught me an important lesson about learning technology and eventually led me to pivot from JavaScript to Python.

When HTML and CSS Felt Straightforward

My entry into web development started with HTML and CSS.

HTML introduced me to the basic structure of web pages. It felt almost like writing a document that the browser could understand.

CSS came next, and suddenly the web page could be styled. Colors, spacing, layout, and fonts began to bring life to the page. The understanding did a thing to me.

The feedback was immediate. You write something and instantly see the result on the screen. That kind of learning is very encouraging for beginners.

At that stage, it felt like progress would continue smoothly. But I was about to find out with JavaScript.

The Moment JavaScript Changed Everything

Then I started learning JavaScript.

This was the moment when programming stopped being just about structure and design and started becoming about logic. The logic I encountered as a first year student at the University of PortHarcourt was different.

JavaScript introduced ideas that were deeper than anything I had encountered before:

  • variables
  • functions
  • conditions
  • loops
  • program logic

Suddenly, it was not just about what appears on the screen, but how the computer thinks.

This was the moment I hit what I now call The JavaScript Wall.

Realising Programming Is Deeper Than It Looks

At first, I thought the problem was simply my ability.

Many beginners have this same reaction when they meet their first programming challenge. It is easy to think:

  • maybe I started too late
  • maybe programming is only for very young people
  • maybe this is not for me

But with time, I realised something important.

Programming itself is deeper than it appears at the beginning.

The early stages are friendly and visual. But as you go deeper, you start dealing with the logic that powers the entire digital world.

My Quiet Learning Phase

Instead of rushing forward, I decided to slow down.

I spent some time quietly reviewing what I had learned so far. I read more carefully. I practiced more deliberately. I tried to understand the ideas behind the code rather than simply copying examples.

This phase was not very visible on social media, but it was one of the most important stages of my learning journey.

Sometimes the most meaningful progress happens away from the spotlight.

Discovering Python

During this period of reflection, I encountered Python.

What immediately caught my attention was how readable the language felt.

Compared to many other programming languages, Python often reads almost like plain English. The structure felt simpler and easier to follow.

For example, tasks that required several lines of complex syntax in some languages could often be written in a more straightforward way in Python.

This clarity made a big difference for me.

Programming still required thinking and practice, but the language itself did not feel like an additional obstacle.

Why the Pivot Made Sense

My decision to pivot from JavaScript to Python was not about abandoning JavaScript completely.

JavaScript remains one of the most important languages on the web.

However, for my personal learning style, Python provided a clearer path for understanding programming logic at a deeper level.

Instead of constantly struggling with syntax, I could focus more on the ideas behind the code.

And that is what programming is really about.

The Lesson for Other Learners

Looking back, the experience taught me an important lesson.

Hitting a wall while learning something new is not a sign of failure.

It is often a sign that you are entering a deeper stage of understanding.

Sometimes the best response is not to quit, but to pause, reflect, and explore different paths.

Learning technology is not a straight road. It is a journey filled with experimentation, adjustments, and discovery.

Final Thoughts

The JavaScript wall was not the end of my learning journey.

In many ways, it was the moment that made the journey more meaningful.

It forced me to slow down, think more deeply, and eventually find a language that made programming feel clearer again.

And that discovery opened a new chapter in my tech learning journey.

If you are also learning technology or any other thing for that matter and have encountered a similar wall, remember that you are not alone.

Every learner meets one eventually.The key is simply to keep moving forward — one step at a time.

This post is part of my ongoing learning archive.
→ My Tech Learning Journey — One Step at a Time

No login needed — just drop your name and share your thoughts below 👇

Why JavaScript Felt Like a Brick Wall

After getting more or less comfortable with HTML and CSS, JavaScript felt like the natural next step.

That was the narrative everywhere or so I thought:
structure first, styling next, logic after.

So I stepped into JavaScript expecting momentum. I assumed the confidence I had built would carry me forward. It felt like a good time to go a step forward.

Instead, I hit a wall.

Things stopped behaving predictably. Many things seemed to change. I needed to recalibrate. With HTML and CSS, my practice lived almost entirely inside VS Code. JavaScript broke that comfort. Suddenly, I had to explore the wider world of the browser—its console, its layers, and how every small change ripples through a page.

A small mistake could cause a big problem.
A missing character could break everything.
And the feedback I received — error messages — felt less helpful and more overwhelming.

With HTML and CSS, I could usually see what was wrong.
With JavaScript, things failed quietly or loudly, but rarely clearly.

The page didn’t just look wrong.
It stopped working altogether.

At first, I thought the problem was JavaScript.

It felt unforgiving.
Too abstract.
Too sensitive.

But looking back now, I can see that the real issue wasn’t the language.

It was my expectation.

I assumed that because I have become conversant with structure and styling, logic would come easily.

I thought progression was linear:
HTML → CSS → JavaScript.

I was wrong. JavaScript didn’t build on confidence the same way CSS did.

It demanded something different.

JavaScript exposed gaps I hadn’t realized were there.

It forced me to confront:

  • how logic actually flows,
  • how conditions affect outcomes,
  • how code thinks step by step,
  • how decisions are made before results appear.

This wasn’t about syntax alone.
It was about thinking in sequence, not just arrangement.

And that kind of thinking hadn’t been fully formed yet.

What made this phase difficult wasn’t failure.

It was uncertainty.

I could no longer rely on visual feedback alone. I had to trust invisible processes. I had to understand what was happening before something appeared — or didn’t.

That shift was uncomfortable.

But it was also revealing.

JavaScript didn’t block me because I wasn’t capable.
It slowed me down because I needed a different foundation.

What felt like resistance was actually information.

Feedback.

That moment forced me to pause.

Not to quit — but to rethink how I was learning.

I began to question the assumption that there was only one correct order. I started to wonder whether understanding logic required a different entry point.

JavaScript didn’t fail me.

It showed me what I was missing.

And that realization changed the direction of the journey that followed.

This post is part of my ongoing learning archive.
→ My Tech Learning Journey — One Step at a Time

The Moment CSS Made Me Feel Confident

HTML helped me understand structure-the sequence that follows the words as we see them on our web pages.

CSS did something else.

It gave me confidence- The power to affect the styles and colours of those words: the building blocks, that appear on the web.

Not the loud kind of confidence. Not the kind that announces itself.
The quiet kind — the kind that settles in slowly and stays.

At first, Cascading Style Sheet, CSS felt like decoration.

Colors.
Spacing.
Fonts.
Layout tweaks.

It didn’t seem essential in the way HTML did. HTML explained what things were- essentially the building blocks. CSS only changed how they looked — or so I thought.

But the first time I changed a color and saw the page respond, something shifted.

Then it happened again.

I adjusted spacing and the layout stopped feeling cramped.
I styled a button and it finally looked clickable and appeared in clean colours that could be tweaked by mere adjustment of a few codes.
I fixed a broken alignment and understood why it had been wrong in the first place.

None of these moments were dramatic.
But together, they changed how I felt about what I was building.

For the first time, I wasn’t just placing content on a page.

I was shaping it.

CSS didn’t make me feel like an expert.

It made me feel in control — even if only a little.

That mattered more than I expected.

Before then, tech often felt fragile. One small change could break everything. the small frustration that creeps in when it does. I wasn’t always sure why something looked wrong, only that it did.

CSS slowed that chaos down. It meant that for every break, there is a reason. Once the reason is discovered and fixed, everything became normal again.

It taught me that layout follows rules.
That spacing isn’t random.
That visual structure has logic behind it.

Once I understood that, things stopped breaking “mysteriously.”

They broke for reasons. That clarity removed frustrations. If something breaks, find the cause and fix it. That awareness replaced frustrations with patience.

So CSS also taught me patience.

Sometimes a single property didn’t work the way I expected. Sometimes fixing one thing exposed another problem. Sometimes the solution wasn’t obvious.

But each adjustment taught me something.

I began to recognize patterns:

  • why elements stack the way they do,
  • why margins behave differently from padding,
  • why a small change can have a big visual effect…
  • And the beauty of all them put together.

The page stopped feeling hostile.

It started feeling negotiable.

What CSS really gave me wasn’t that beauty.

It gave me incremental control. A feeling of ability that was not as concrete as it became.

I didn’t need to know everything to improve something.
I just needed to understand the next small step.

That realization changed how I approached learning.

Learning tech wasn’t about mastery.
It was about steady influence over the system in front of me. A little consistent steps that beats intensity.

That confidence carried me forward.

Not because the next phase was easier — it wasn’t.
But because I had learned something important by then:

I could move from confusion to clarity, one adjustment at a time.

And once you experience that even once, you trust that it can happen again.

This post is part of my ongoing learning archive.
→ My Tech Learning Journey — One Step at a Time

Why I Started My Tech Journey with HTML

When I decided to learn tech, I didn’t start with Python or JavaScript.

I started with HTML.

Before then I had become very interested in how images, colours and texts take shape on the web. The forms they take from the time of request till when it appears on our screens. What is responsible for these dynamics? Why do some texts appear in italics, bold or normal? What is responsible for the difference in colours? How is the spacing between words achieved? Why do some texts appear on the right and others on the left? How is this achieved? How do I get to have options and when I make inputs, I get results? It was these interests that churned on as the days passed that led me to the building block of the web-HTML.

At the time, it didn’t feel like a bold decision especially when I discovered a few days into the study what Ai could now do in that respect. Even a friend of my in the Tech industry whom I had informed of my interest and my decision to learn this skill alluded to this fact. He said it was a waste of time and advised that I focus on other more profitable aspect of Tech. But that did not assuage the thirst and I kept on. And Thank God I did!

But it felt almost underwhelming. I did not understand why. HTML wasn’t glamorous. It didn’t promise automation, intelligence, or complex logic. It was just structure — tags, elements, and files.

And at first, it felt too simple.
Almost boring.

But looking back now, that simplicity was exactly what I needed. It provided the type of ground that formed my very first steps in this journey. The exact type I so much desired.

HTML was the first time tech stopped feeling abstract.

Before then, “the web” was something I used, not something I understood. Pages loaded. Buttons worked. Content appeared. But none of it had a shape in my mind only bewilderment that later gave rise to interest.

HTML changed that.

It showed me that the web isn’t magic — it’s structure.
Headings, paragraphs, links, images.
Files connecting to files.
Content arranged intentionally.

For the first time, I could see how things fit together.

What HTML gave me wasn’t intelligence.
It gave me orientation. A picture; an outline.

I began to understand:

  • how content is displayed,
  • how a browser reads files,
  • how one file can point to another,
  • how a simple mistake can break a page — and how fixing it restores order.

These weren’t advanced concepts, but they were grounding.

Instead of feeling lost inside “tech,” I had a map.

More importantly, HTML gave me early wins. I now saw how websites are built. How the texts are formed. How images are rendered.

I typed something.
I saved the file.
I opened it in a browser.

And there it was.

It didn’t matter that it looked ugly.
It didn’t matter that it wasn’t styled.
What mattered was that something I created appeared in front of me.

That moment did more for my confidence than any explanation ever could. And it was fun too to see the “magic” I could now activate!!

HTML didn’t make me feel “smart.”

It made me feel capable.

That difference is subtle, but important.

Feeling smart fades quickly when things get hard.
Feeling capable stays with you when you hit confusion.

I had been somewhat carefree in handling files. HTML taught me that I could:

  • follow structure,
  • make sense of errors,
  • fix what was broken,
  • and build something visible from nothing.

At the beginning, that matters more than complexity.

Looking back now, I see that starting with HTML wasn’t about learning a language.

It was about learning how to stand inside tech without fear.

It slowed things down in the right way.
It removed pressure.
It allowed understanding to form without intimidation.

Though I am still learning but that foundation made everything that followed possible.

If you’re starting tech today, HTML is not a waste of time.

It won’t impress anyone just like I did not impress my friend.
It won’t make you feel advanced.

But it will give you something more valuable early on:

A sense that you belong here.
A sense that you can build.
A sense that learning is possible.

And sometimes, that’s the most important foundation of all.

This post is part of my ongoing learning archive.
→ My Tech Learning Journey — One Step at a Time

Why I am Documenting My Tech Learning Properly This Time

I have been learning tech for a while now. 

HTML.
CSS.
JavaScript.
Python.

On paper, it looks like progress. And in many ways, it was.

But recently, I realized something important:

I learned, what I should consider, a lot of things, yet I didn’t truly document the journey.

Not the confusion.
Not the incessant nudge to give up.

Not the false starts.
Not the moments when things didn’t make sense but I kept going anyway.

What existed were outcomes — not the thinking that led to them.

For a long time, I assumed documentation was something you did after you had figured things out. Something reserved for experts, teachers, or people who already had clarity.

So I focused on consuming content instead:

  • tutorials,
  • guides,
  • videos,
  • explanations.

I was learning, yes — but quietly. Internally. Without leaving a trace of how my understanding was forming.

Looking back now, I see that this made it harder to notice patterns:

  • where I was improving,
  • where I was stuck,
  • what actually helped me move forward.

This time,  I am doing it differently.

Not because I suddenly became more disciplined.
Not because I want to teach.
And certainly not because I think I have “arrived.”

I am documenting because clarity doesn’t come from speed.
It comes from structure.

Writing forces me to slow down.
To name confusion instead of rushing past it.
To understand why something works, not just that it does.

This space — ObisDeck — is not a tutorial platform in the traditional sense.

It is:

  • a learning archive,
  • a thinking log,
  • a place where progress is allowed to be slow,
  • and where understanding is allowed to form honestly.

Some entries will be reflective.
Some will be practical.
Some will simply capture a shift in how I see things.

All of them will be real.

I am not documenting to prove anything.

I am documenting because I have learned that when learning remains invisible, it’s easy to feel like nothing is happening — even when growth is taking place.

By writing things down, I give my learning a shape.
By structuring it, I give it direction.

That’s what this journey is about.

If you’re learning tech quietly —
if you’ve started, stopped, restarted, or hesitated —
or if you’ve felt like you’re “doing the work” but still unsure where you stand,

you’re welcome to follow along.

This is not a race.
It’s a process.

And this is the first step.

This post is part of my ongoing learning archive.
→ My Tech Learning Journey — One Step at a Time

Why Tutorials Alone Didn’t Give Me Flow

There was a period in my learning where everything looked right from the outside.

I was watching tutorials- Youtube videos and others.
I was reading guides-including PDF´s of code journals, W3Schools website and the in-depth coverage it gave in almost all programming languages.
I was following along, typing what I saw, and getting the expected results.

By most standards, I was “learning.”

But internally, something felt off. And so I felt.

I wasn’t lost, yet I wasn’t settled either. I could reproduce steps, but once the tutorial ended, the confidence faded quickly. The sense of flow I expected never really arrived. I could not actually connect the dots thereafter.

At that stage, my learning was mostly driven by consumption. Wait longer, it tends to dissipate-lost almost completely. And with a bit of frustration at how I could forget so soon, I would go back to try to fill the gaps again.

I moved from one tutorial to the next, assuming that consistency alone would eventually turn into understanding. Each video felt productive. Each article felt useful. And in isolation, they were.

But what I didn’t realize at the time was that I was collecting information, not owning it.

I could follow instructions, but I struggled to explain why something worked. If a small detail changed, I had to go back to the tutorial. If I faced a slightly different problem, the clarity disappeared.

The knowledge was there — but it wasn’t anchored.

This wasn’t a failure of tutorials.

In fact, tutorials helped me overcome fear. They introduced me to tools, concepts, and possibilities I might not have approached on my own. They lowered the barrier to entry and made learning feel accessible.

But they had a limitation I didn’t see early enough.

Tutorials are designed to show a path, not to build ownership. They guide you forward, but they don’t pause to ask whether you truly understand what just happened.

And I wasn’t pausing either. Just going.

The real issue wasn’t that I was learning the “wrong” way.
It was that I hadn’t yet learned how I needed to learn.

I mistook movement for progress.
I assumed that more effort will bring clarity and that staying busy meant things were sinking in.

But flow doesn’t come from repetition alone. It comes from clarity — and clarity only appears when you slow down enough to reflect.

That realization didn’t arrive as frustration or burnout. It came quietly.

I noticed that the moments where things finally made sense were the moments when I stepped away from the tutorial and tried to explain the idea to myself — sometimes in writing, sometimes mentally, sometimes by rebuilding something without guidance.

Those moments were slower. Less impressive. Less visible.

But they stayed with me.

That was the beginning of a shift.

I didn’t abandon tutorials. I simply stopped letting them lead the entire process. I began paying attention to what confused me, where I hesitated, and what I couldn’t explain clearly.

Writing became a tool, not for teaching others, but for understanding myself.

Documenting what I was learning forced me to confront gaps that tutorials had quietly allowed me to skip. Reflection turned passive knowledge into something more solid. Then the dots started connecting.

That’s when learning started to feel different.

This post sits between From Fear to Flow and the more structured journey that followed.

It represents the phase where learning looked productive, but understanding was still forming. It explains why documentation became necessary — not for content, not for performance, but for clarity.

The stages that come after this are shaped by that realization.

I didn’t need more speed.
I needed more structure.

And that’s where the next part of the journey begins.

This post is part of my ongoing learning archive.
→ My Tech Learning Journey — One Step at a Time

Blue-Light Blocking Glasses: Do They Really Work — And Should You Be Using Them?

Tired young professional rubbing eyes after hours on laptop screen at night, showing digital eye strain
Tired young professional rubbing eyes after hours on laptop screen at night, showing digital eye strain

Introduction: The Hidden Strain of Modern Life

It is late at night, and your phone screen glows inches from your face. Your eyes burn, your head feels heavy, and when you finally switch off, sleep doesn’t come easily. Sound familiar?

You are not alone. Research shows that the average adult now spends over seven hours a day in front of digital screens — phones, laptops, TVs, tablets. For professionals, creators, and students, it’s even higher. The result? A silent epidemic of digital eye strain and disrupted sleep.

Enter blue-light blocking glasses — hailed by some as a wellness hack and dismissed by others as hype. As someone who lives at the intersection of content creation and wellness expertise, I have dug deep into the science, the user experience, and the practical benefits. Here’s what you need to know.

What Exactly Is Blue Light?

Blue light is part of the visible light spectrum, with high-energy, short wavelengths. It comes from the sun (good in moderation) but also floods out of our screens — laptops, smartphones, and LED lighting.

The problem is timing. During the day, blue light can boost alertness and productivity. But at night, excess exposure can suppress melatonin, the hormone that helps you sleep. Prolonged daily exposure has also been linked to digital eye strain, headaches, and blurred vision. Research shows that blue light can suppress melatonin and disrupt sleep cycles.

Why Screen Time Is Becoming a Health Crisis

The modern lifestyle means screen time is no longer optional — it is work, school, entertainment, and even social life. In surveys, professionals report:

  • Insomnia after late-night scrolling.
  • Eyestrain and dryness after long Zoom sessions.
  • Headaches from switching between multiple screens.

Eye specialists now warn that while blue light won’t “burn your retina” overnight, years of exposure without countermeasures can compound stress on the visual system.

What Are Blue-Light Blocking Glasses?

Blue-light blocking glasses are designed with special lenses that filter high-energy visible light before it reaches your eyes. Depending on the brand, they may have clear lenses for everyday use, or amber/yellow lenses that block more light (especially for nighttime).

Blue-light blocking glasses placed neatly beside a laptop and coffee on a bright desk, representing digital wellness.
Blue-light blocking glasses placed neatly beside a laptop and coffee on a bright desk, representing digital wellness.

Potential benefits:

  • ✅ Less eye strain during long screen sessions.
  • ✅ Reduced glare and flicker sensitivity.
  • ✅ Better sleep quality when used in the evening.
  • ✅ Fewer headaches linked to digital fatigue.

Do they work for everyone? No. Some studies show mixed results. But thousands of users — from gamers to office workers — report noticeable relief. As with most wellness tools, it’s about stacking small wins.

Who Should Consider Wearing Them?

If you fall into one of these groups, glasses might make a big difference:

  • Office professionals spending 8+ hours on a laptop.
  • Students studying late at night.
  • Content creators, coders, designers, or video editors.
  • Gamers and streamers.
  • Parents who worry about kids’ screen habits.

As one optometrist puts it: “Lifestyle changes are the foundation, but for heavy screen users, glasses are a simple, affordable extra layer of protection.”

How to Choose the Right Pair

Not all glasses are created equal. Here’s what to look for:

  • Frame comfort — You’ll be wearing them for hours.
  • Lens clarity — Clear lenses for day use, amber for heavy night use.
  • Anti-glare coating — Reduces reflections from office or studio lights.
  • Price vs. quality — Don’t chase the cheapest; balance value and durability.

👉 One of the most reliable starting points is this pair of Blue-Light Blocking Glasses on Amazon (Affiliate Link). They’re affordable, lightweight, and effective for everyday use.

Complementary Habits for Digital Wellness

Glasses work best when combined with smart habits:

  • 🔆 Turn on “Night Shift” or “Blue Light Filter” mode on devices after sunset.
  • 👁 Follow the 20-20-20 rule: every 20 minutes, look 20 feet away for 20 seconds.
  • 🌙 Keep screens away in the hour before bed.
  • 💧 Stay hydrated — dehydration can make eye strain worse.

Think of glasses as part of a toolkit, not a standalone cure. Explore more tips in my guide on healthy screen habits.

Real-World Results

While the science is still evolving, users worldwide share real benefits:

  • “I no longer get splitting headaches after long gaming sessions.”
  • “I fall asleep faster, even after late-night laptop work.”
  • “As a teacher grading papers online, my eyes don’t burn like before.”

And yes — as a content creator myself, I’ve noticed that editing video for hours feels less harsh with glasses on.

Conclusion: A Small Change With Big Payoff

Blue-light blocking glasses won’t solve all your digital wellness problems. But if you spend hours on screens — and let’s be honest, we all do — they’re a simple, affordable tool worth testing. How to Choose the Right Pair

Smiling person wearing blue-light glasses while working on laptop, looking relaxed and productive
Blue-light glasses can make screen time more comfortable — and your day more productive

Your eyes deserve better. Your sleep deserves better. And your productivity depends on both.

👉 If you’re curious to try them, start with this recommended pair on Amazon.Check this affordable pair of blue-light blocking glasses on Amazon and if you want to take your digital wellness further, subscribe to my newsletter — I share simple, science-backed tips every week to help you work smarter, rest deeper, and live better.