Forem: Sareena Rahim

Is It That Simple… Or Am I That Dumb?

Sareena Rahim — Sun, 05 Apr 2026 17:41:22 +0000

Somewhere in the middle of that day, I started thinking: maybe this just isn’t for me.

I had just started learning SQL and wanted to understand how people actually work with data.Not in theory, not in a tutorial. Real data.

So I found a waste management dataset in Excel and decided to analyze it with Python.

I started with a little confidence. And a little nervousness.
The kind of mix you feel when you're trying something new and you're not sure yet which one is going to win.

It started normally...

Open Excel.
Look at the data.
Go to PyCharm.
Write something.
Run it.

Wrong output.

Go back to Excel.
Look again.
Change the code.
Run it again.

Still wrong.

I took a break. Came back. Tried something different.

Still wrong.

When nothing connects

There’s a thing that happens when you’re learning to code.

You don’t need a big breakthrough to keep going.
You just need a small dot to connect.

One tiny thing that works.Something that tells you: you’re on the right track, keep going.

But when you keep trying and nothing connects.Not even a small dot.Something shifts inside you.

It stops feeling like debugging.

It starts feeling like confirmation.

Maybe this just isn’t for me.

And then… it worked

At some point ,I wasn’t even tracking time anymore. it worked.

The output was exactly what I wanted.

My first thought wasn’t relief.
It wasn’t pride.

It was:

Is it that simple… or am I that dumb?

I sat with that for a moment.

Both felt true at the same time.

What I didn’t notice until later

I still don’t have a clean answer to that question.

But something happened that day that I only understood much later.

I didn’t close the laptop.
I didn’t walk away.
I just kept going.

I'm Building Things I Don't Fully Understand Yet. Good

Sareena Rahim — Fri, 27 Mar 2026 16:16:17 +0000

There’s a specific kind of shame that comes with copying a pattern you don’t fully understand.

You paste it. It works. And instead of feeling good, you feel like a fraud.

Like you cheated on a test nobody was giving you.

I lived in that feeling for longer than I’d like to admit.

Waiting to feel ready

I used to have this rule for myself - unspoken, but firm:

Don’t build until you understand.

So I’d go back to the tutorial.
Re-read the documentation.
Watch the explanation one more time, slower this time, taking notes this time… surely this time it would click.

And then I’d sit down to build and still feel unready.

The thing about waiting to feel ready is that the feeling never actually comes.

It just shape-shifts.

First you need to understand functions.
Then you need to understand scope.
Then you need to understand why your code works before you write more of it.

It’s a very convincing trap.

It looks exactly like learning.

When I finally just built something

When I started building my first real project , not a tutorial, not a follow-along, something I actually wanted to exist - I ran into a wall almost immediately.

I knew what I wanted it to do.
I had no idea how to make it do that.

So I did something that felt wrong at the time:

I found a pattern that looked like it would work, and I used it without fully understanding why.

It worked.

And I moved on.

There were functions in that project I couldn’t fully explain.
Bugs I fixed by trying things until something stuck.
Logic that made sense in the moment,but would have taken me an hour to explain to someone else.

And slowly, without me planning it, something shifted.

The second time I used that pattern, it felt less foreign.
The third time, I started seeing why it was shaped that way.
By the fourth time, I’d modified it into something that actually fit what I was building.

Understanding didn’t come before the building.

It came through it.

The question that changed for me

For a long time, my question before touching anything new was:

“Do I fully understand this?”

The answer was almost always no.

So I’d go learn more.
Come back. Still no.
Go learn more.

At some point, I replaced it with a quieter, more honest question:

“Do I understand this well enough to try?”

That’s a question I can actually answer.

And the answer is almost always yes.

What building teaches that reading can’t

When you’re only reading and watching, everything stays abstract.

Neat. Clean. The examples always work.

But when you actually build something, the mess shows up. And the mess is where the real questions live.

Why is this breaking when the input changes?
Why does this work here but not there?
Am I making this more complicated than it needs to be?

Those questions don’t come from tutorials.

They come from being stuck inside something you’re genuinely trying to make work.

That’s the part no amount of pre-reading can give you.

Where I am now

I’m still a beginner.

There are entire parts of what I’m building that I don’t fully understand yet.

But here’s what I know now that I didn’t know before:

The understanding isn’t somewhere ahead of me, waiting until I’m ready.

It’s inside the work.

It always was.

You don’t find it by waiting.

You find it by building.

Learning to Think Made Coding Easier for Me

Sareena Rahim — Sun, 28 Dec 2025 16:59:03 +0000

For a long time, I thought my problem was that I didn't know enough.
So I tried to learn more.

More tutorials. More topics. More notes saved "for later."

But when I started looking into data structures and algorithms, everything suddenly felt... heavy. Not impossible. Just overwhelming.

Too many concepts at once. Too much theory before I could actually use anything. Too much pressure to understand everything perfectly.

That's when I realized something.

The real struggle wasn't coding. It was thinking clearly.

When "DSA is hard" actually means "I feel lost"

When I felt stuck, it wasn't because I couldn't write code.

It was because I didn't know where to start. I didn't know what actually mattered right now. And I was trying to hold too many ideas in my head at once.

The problem wasn't knowledge. It was clarity.

So instead of pushing harder, I just... slowed down.

I stopped trying to learn everything at once

I didn't sit down to "master DSA."

I focused on a few things that helped me think better:

Writing out what I wanted to do before coding it. Understanding time and space complexity enough to ask "is this reasonable?" Knowing what arrays, stacks, queues, and hash maps are actually useful for. Learning sorting and searching as ways to organize my thinking. Solving problems slowly, without rushing to the "right" answer.

No timelines. No pressure. Just trying to understand.

Things got clearer when I slowed down

Once I stopped memorizing and started connecting things, learning felt lighter.

I wasn't collecting information anymore. I was building understanding.
My process started looking like this:

Try to solve a problem. Notice where I get confused. Learn just that missing piece. Try again.

That loop made everything feel way more manageable.

What I've realized as a beginner

I don't need to know everything yet.

I just need to understand the problem in front of me.

When I focus on that, better questions show up naturally:

What is this problem actually asking? What kind of data am I working with? What happens in edge cases?

That's when coding starts feeling less like guessing and more like thinking.

Final thought

Tools will change. Languages will change. Even AI is changing how we write code.

But clear thinking? That'll always matter.

And right now, that's what I'm trying to get better at.

How do you approach learning new concepts?

How I Decide What to Learn Next

Sareena Rahim — Sun, 21 Dec 2025 10:43:46 +0000

One of the hardest parts of learning to code isn't coding.

It's deciding what to learn next.

There's always something new.Tools, frameworks, concepts, roadmaps. Spend a few minutes online and it can feel like you're already behind.

I used to think the solution was to do more. More tutorials. More topics. More tabs open.

That only made things messier.

The Question That Changed Everything

I stopped asking 'What should I learn?'

And started asking: 'What problem am I trying to solve right now?'

Not in theory. Not for the future. Right now.

If I'm working on something and need to store data, I focus on SQL. If I need to display it, I work on the UI. If my code feels tangled, I learn just enough to organize it better.

I don't learn things in isolation anymore. I learn them because I need them.

Learning in Small, Connected Steps

When I was building my expense tracker, I didn't sit down and "learn databases." I just had expenses that needed to be saved. So I learned enough SQL to store them.

Then I needed to group them by category. So I learned GROUP BY.

Then I wanted to show summaries. So I learned how to query and display data.

Each piece connected to the actual problem. Nothing was random.

My learning usually looks like this:

write some Python
connect it to a database
add a small feature
notice what's missing
learn that one thing

Then repeat.

This keeps learning connected instead of scattered. I'm not collecting random knowledge,I'm building understanding step by step.

I Avoid "Just in Case" Learning

I used to learn things just in case: 'What if I need this later?'

'Everyone says this is important.'

Most of it didn't stick. There was no context.

Now, I'm okay with not knowing things yet. If I don't need something today, I don't force it.

I'll learn Docker when I actually need to deploy something. I'll learn React when I'm building something that needs it. Not before.

You Don't Need to Learn Everything

Here's what I've realized: you can't learn everything. And you don't need to.

You just need to learn what helps you solve the problem in front of you.

That one thing. Right now.

The rest can wait.

Final Thought

Most of the time, the answer to 'what should I learn next?' isn't in a roadmap or a trending tutorial.

It's already in front of you,in the problem you're trying to solve.

What problem are you working on right now? That's probably what you should learn next.

How do you decide what to learn? Do you follow roadmaps, or learn as you go?

Why I Prefer Simple Code Over "Smart" Code

Sareena Rahim — Sun, 14 Dec 2025 06:41:27 +0000

When I started learning to code, I thought good code meant clever code.

You know, short variable names. One-liners that did a bunch of stuff at once. Logic squeezed into as few lines as possible.

It looked impressive. It felt impressive.

But over time, something became really clear: the code I understood fastest was never the "smart" one. It was always the simple one.

And that kind of changed how I think about writing code.

What "Smart" Code Usually Means

When people say "smart" code, they usually mean stuff like:

really compact logic
clever tricks and shortcuts
doing more with fewer lines
code that makes you go "wait, how does that even work?"

Look, I'm not saying clever code is always bad. Sometimes it makes sense.

But here's what I noticed: that "smart" code? Really hard to read. Especially when it's someone else's code.

You Don't Read Code Just Once

you don't just write code and forget about it.

You come back to it. You need to fix something. You want to add a feature. You completely forgot how that one function worked.

And when the code is simple? All of that becomes so much easier.

Simple code tells you a story. You don't have to stop every few lines and decode what's happening.

Honestly, when I open something I wrote a month ago, I just want to understand it without getting annoyed at myself.

An Actual Example From My Code

Okay, real talk. I was calculating a shopping cart total and wrote this:

# My "clever" version
total = sum([item['price'] * item['qty'] for item in cart if item['available']])

One line. Worked perfectly. Felt efficient.

I stared at it for a minute thinking, “This works… but how am I supposed to change it without breaking something?"

So I just rewrote it:

# Simple version
total = 0
for item in cart:
    if item['available']:
        total += item['price'] * item['qty']

Yeah, it’s more lines. But at least I could understand it.

Nothing felt hidden. So when I needed to change it, I wasn’t worried about breaking everything.

Debugging Simple Code Doesn't Make Me Want to Quit

When something breaks, I really don't want to untangle some clever nested logic.

I just want to see what went wrong. Where did the value change? Where did the condition fail? What broke and why?

With simple code, the problem usually jumps out at you. With "smart" code, everything's packed so tight that even finding a small bug takes forever.

And as someone still learning, that matters. Debugging is already hard enough without the code itself fighting you.

Simple Doesn't Mean Messy

Wait, I should clarify something.

Simple code doesn't mean:

bad code
repetitive code that could be better
no structure at all

Simple code just means: clear, readable, understandable.

Some of the best code I've seen online is simple. Not because the person couldn't write something fancier, but because they cared more about being clear than being impressive.

Clarity Over Cleverness

I'm not anti-clever-code. I'm just saying: clever code that nobody can read doesn't help me improve.

Right now, I want code that:

I can read without squinting

I can debug without crying

I can actually explain if someone asks

Maybe someday I'll write more advanced stuff. But even then, I hope I don't sacrifice clarity just to look clever.

Because code isn't just about making it work. It's about making it understandable.

And for me, simple code does that way better.

How do you approach this when you’re coding? Curious what works for you.

Learning Slowly, Learning Consistently: My Approach to Coding

Sareena Rahim — Sun, 07 Dec 2025 07:22:28 +0000

I'm a slow learner. There, I said it.

I can't rush through five tutorials a day. I can't build huge projects overnight. And for a long time, I thought that meant I wasn't cut out for coding.

But then I realized something: maybe slow isn't the problem. Maybe rushing is.

Why I Don't Rush My Learning

I've never believed in forcing myself to understand everything in one go. Some concepts just take time.

SQL JOINs didn't make sense immediately. Classes in Python felt confusing in the beginning. Even Git took a while.

But instead of pretending I understood, I'd revisit the topic later. Sometimes the next day, sometimes a week later... and every time, I understood it a little better.

This slow approach helps me:

actually remember what I learn
think clearly while coding
avoid unnecessary stress
stay honest with myself

I don't study to "finish a syllabus." I study to understand.

Consistency Over Speed

I don't code every single day. But I do come back to coding regularly.

My progress doesn't come from streaks or pressure. It comes from:

solving one LeetCode problem properly
writing one clean function
learning one SQL concept at a time

Many people think consistency means coding every day. For me, consistency means showing up in a way I can sustain.

If I can learn something properly today, that's enough.

How I Learn in a Clear, Honest Way

I don't try to look advanced. I don't try to memorize big definitions. I don't pretend I know topics I'm still figuring out.

Here's what I actually do:

1. I stick with simple learning cycles

Python, then SQL, then small projects... repeat. I don't switch topics every week. Staying focused on a few things helps me go deeper instead of spreading myself thin

2. I build small features

A summary function. A login system. A single SQL query. A visualization.

These small wins build real confidence. I'd rather finish one feature properly than start ten and abandon them all.

3. I don't chase "green squares"

I use GitHub to track my work, not force activity. Some days I push code, some days I don't. I never push just for the streak.

Progress isn't about daily commits. It's about meaningful work, even if it's just once or twice a week.

4. I take breaks when needed

If I don't understand something, I leave it for a while. Most of the time, when I return, it makes more sense.

Forcing yourself to "get it" when you're confused just leads to frustration. Sometimes your brain needs time to process.

Being Real With Your Learning Journey

I used to think learning fast meant you were smart. Now I think learning honestly is what really matters.

Anyone can rush. But staying consistent (even slowly) takes clarity.

So if you're learning something yourself, here's my simple reminder:

Go slow if you need to. Just don't stop.

Your pace doesn't define you. Your consistency does.

I'm still learning slowly. Still figuring things out. But I'm also still here.

What made you realize that slow and steady works better? I'd love to hear how other people approach their learning pace.

My Simple Workflow: Python Database UI

Sareena Rahim — Sun, 30 Nov 2025 03:57:07 +0000

I've been building projects for a few months now, and I noticed something: I always do things in the same order.

Not because someone taught me to. Not because I read it in a tutorial.

It just... happened naturally as I figured things out.

Python: Where Everything Starts

Every project I build starts the same way.A blank Python file and an idea.

No UI. No database. No structure.

Just me trying to make the core idea work.
I'll write a function. Test it. Print stuff to see what happens. Break it. Fix it. Add another function.

This stage is messy. Lots of print statements everywhere. Lots of "wait, why isn't this working?"

But I like starting here because I can focus on one thing: does the logic actually work?

Once I get the basic functionality down.Like, the thing actually does what it's supposed to do.I start thinking:

"Okay... but where do I save this?"

And that's when I move to the next part.

Database: Where Things Get Real

At some point, printing results to the terminal isn't enough anymore.

If I close the program and everything disappears, it doesn't feel like a real project.

That's when I add a database.

I use SQLite most of the time because it's simple. Just a file. No server setup or anything complicated.

This is where I learned SQL

How do I save a user's expense? SELECT and INSERT.
How do I show expenses by category? GROUP BY.
How do I connect related data? JOINs.

It all made sense because I was solving real problems in my own projects.

Once my data is stored safely and I can pull it back whenever I need it, the next question hits me:

"How do I make this actually usable?"

UI: When It Finally Feels Like a Project

This is the fun part.

After weeks of just code and databases, I finally get to see the project come to life visually.

Sometimes I use Tkinter. Sometimes Streamlit. Sometimes just a simple command-line interface.

But this stage makes everything feel... done.

Buttons that actually do things. Tables that show my data. Input fields that save to the database.

And here's the thing:

The UI is almost always the easiest part. Because by the time I get here, all the hard work is already done.

Python handles the logic. SQL stores the data. The UI just connects them together.

Why This Works for Me

I don't think about everything at once.

I don't try to build the UI while figuring out the logic. I don't worry about the database before I know what I'm storing.

One thing at a time.

Python first. Database second. UI last.

It keeps me from getting overwhelmed. And honestly, it's just how my brain naturally works through problems now.

Final Thoughts

I'm not saying this is the "right" way. I'm sure there are better workflows out there.

What's your workflow? Do you do things in a similar order, or completely different?

I'd love to know how other people approach building projects.Especially other beginners figuring this stuff out.

GitHub Finally Became a Part of My Coding Routine

Sareena Rahim — Sun, 23 Nov 2025 09:05:41 +0000

For the longest time, Git and GitHub were just words I kept hearing everywhere.In tutorials, on X/Twitter, in developer posts.

I wasn’t avoiding it.
I just didn’t see why I should push every small thing I wrote.

I was practicing Python, SQL, doing LeetCode… and everything lived quietly inside my laptop. It worked fine. Nothing felt “wrong.”

But at some point, I wanted more structure.

A place where my learning wouldn’t disappear into random folders.
Something that showed progress.

Not for others, but for myself.

That’s when GitHub started making sense.

You Don’t Need to Master Git to Start

One thing that surprised me
You can use GitHub with barely 3 commands:

git add .
git commit -m "your message"
git push

All the advanced things,rebasing, branching, merging.I’ll learn them eventually, but they weren’t required for me to start building a habit.

I just needed a simple workflow to keep my work organised and visible.

What Changed When I Started Pushing Regularly

1.My progress became easy to track

my GitHub shows what I’m learning and how often I’m practicing.

It’s like creating a small trail of your growth,not dramatic, just clear

2. Commit messages made me more thoughtful

Not perfect. Not fancy.
Just intentional.

Instead of writing “update”, I now write:

implemented delete expense
added basic error handling
updated README

It makes me see my work in smaller, meaningful steps.

3. GitHub became my proof of consistency

I’m not trying to impress anyone with gigantic projects.

I just want my work to exist somewhere other than my hard drive.

Now, when someone asks, “What are you learning?”
I can simply share the link.

Clean, simple, and updated.

And honestly? That feels good.

If You’re Still Keeping Everything in Local Folders…

Just try pushing one small project.

Not your biggest one.
Not the most impressive one.
Just something you wrote recently.

You don’t need to fully understand Git.
You don’t need perfect code.
You don’t need a “portfolio project.”

All you need is the first push.

Because GitHub isn’t about looking like a real developer.

It’s about building a space where your learning actually lives.

And over time, that space becomes something you can look back on and feel quietly proud of.

Learning SQL: The Language Behind Your Data

Sareena Rahim — Sun, 09 Nov 2025 09:47:12 +0000

Ever since I started getting interested in data and databases, SQL kept coming up everywhere. Job descriptions mentioned it, developers talked about it, and every data tutorial seemed to assume you knew it.

I knew I should learn it, but something about "writing queries" and "working with databases" sounded... technical. Intimidating, even.

What is SQL, anyway?

SQL stands for Structured Query Language, but that formal name doesn't really tell you much.

Here's what it actually is: it's how you ask questions to a database.

Want to know which customers signed up last month? There's a query for that.

Want to find your top-selling products? Another query.

Want to count how many users made a purchase today? Yep, SQL.

My first query was simple:

SELECT * FROM users;

I hit "Run" and... boom. A table full of data appeared on my screen.
I remember thinking, "Wait, that's literally it?"

It felt too easy. Like there had to be more to it. But nope,that simplicity is exactly what makes SQL so useful.

The concepts that actually stuck

SELECT and WHERE:

These two let me filter through data and grab exactly what I needed. Want all orders from last week? Done. Want users who haven't logged in for 30 days? Easy.

JOINs:

took me a minute to wrap my head around. But once I stopped overthinking and just visualized it as "matching pieces from two different puzzles," it clicked.

GROUP BY:

Instead of manually adding up numbers, I could group data by category and let SQL do the math.

ORDER BY and LIMIT:

sound boring, but they're incredibly handy when you just want the top 10 results or need things sorted a certain way.

The stuff that tripped me up

One thing that really confused me early on was HAVING. I'd use GROUP BY to summarize data, and then I'd try to filter those results... but WHERE wouldn't work. I kept getting errors and couldn't figure out why.

Turns out, you can't use WHERE after GROUP BY, you need HAVING instead. WHERE filters rows before grouping, and HAVING filters after grouping. It sounds simple now, but when you're starting out, these little differences are really confusing.

The only reason it finally clicked was because I kept practicing. I'd write queries, they'd fail, I'd search the error, understand why, and try again. That hands-on repetition made the logic sink in.

Debugging SQL queries as a beginner is... humbling. But each mistake taught me something.

What actually helped

Honestly? Just working with MySQL directly and trying things out.

Keeping learning and practice side-by-side was key. I never spent more than 10-15 minutes reading or watching without immediately trying something myself. That constant feedback loop made everything stick.

I'd watch a tutorial on JOINs, pause it, open MySQL, and write three different JOIN queries just to see what happened. Sometimes they worked. Sometimes they didn't. Either way, I learned.

My first real "aha" moment

One day, I wanted to see how much I'd spent in each category over the past few months. I wrote this:

SELECT category, SUM(amount) AS total_spent
FROM expenses
WHERE date >= '2025-01-01'
GROUP BY category
ORDER BY total_spent DESC;

And just like that, I had a clean summary

That's when it hit me: SQL isn't just a tool. It's a way to have conversations with your data

Where I'm at now

I'm still learning. There's a ton I don't know yet.Subqueries, window functions, performance optimization, all that.

I've realized something important: SQL is just a tool for asking questions. And I'm good at asking questions.

Final thoughts

Learning SQL as a beginner wasn't as scary as I thought it would be. The key was staying curious, making mistakes, and not being afraid to try things out.

How Small Problems in My App Led Me to Discover APIs

Sareena Rahim — Sun, 02 Nov 2025 13:01:24 +0000

After getting comfortable with Supabase and building my first expense tracker, I started hearing this word everywhere - API.

At first, it sounded like something only advanced developers used.
But the more I explored, the more I realized something simple yet powerful

So, What Exactly Is an API?

The full form of API is Application Programming Interface

Here’s how I understand it in simple terms:

Imagine your app as a restaurant.

The kitchen is your database (where the real work happens).
The waiter is the API.
The customer is your frontend app (or the user interface).

The customer never goes into the kitchen,they just tell the waiter what they want.
The waiter carries that message to the kitchen, brings back the right food, and delivers it neatly.

That’s exactly what an API does,it carries requests and responses between your app and the backend

Why Do We Need APIs?

When I built my first version of the expense tracker, my Python app was directly talking to Supabase.

It worked fine… but I started noticing a few small yet annoying problems:

🧠 My code was getting messy : everything (login, database logic, calculations) was inside one big Python file.
🔒 Security felt uncertain: anyone who saw my code could technically find my database keys.

That’s when I realized:

The API handles all the data requests and rules.
The frontend only asks for information and displays it.

⚙️ How It Actually Works

The app sends a request,like “Get all expenses for user 1.”
The API connects to the database.
The database sends back the data.
The API formats it (usually as JSON) and returns it to your app.

Why I Chose FastAPI

Fast and simple : I could create an API in just a few lines.
Automatic docs : it built a /docs page where I could test my API instantly.
Safe by design : it handled input validation automatically.
Easy to connect — it worked beautifully with my Supabase backend.

✨ What I Learned

APIs are bridges between your frontend and backend.
FastAPI makes building and testing them simple and fun.
Separating backend logic with APIs makes your project more professional and scalable.

💬 Over to You

If you’ve ever had small problems that led you to discover something big

like APIs,I’d love to hear your story.

What was your “Aha!” moment?

My First Experience with Supabase: Beginner-Friendly and Fun

Sareena Rahim — Sun, 26 Oct 2025 08:32:24 +0000

Ever since I started learning Python, I wanted to build something real and useful, not just follow tutorials. After practicing with small exercises and mini projects, I finally decided to take on my first desktop app: a simple expense tracker.

This project was exciting, challenging, and full of learning moments.
one of the most important lessons came from using Supabase, a cloud backend that made the impossible feel easy.

What is Supabase?

Supabase is basically a ready-to-use backend in the cloud. Think of it as a combination of:

A database (PostgreSQL)
Authentication for multiple users
Tools to access your data easily from code

And the best part? It’s beginner-friendly. You don’t need to install or configure a database on your computer. You can literally sign up, create a project, and start storing data in minutes.

Why I Chose Supabase

When I was building my expense tracker, I had a few goals:

Store user expenses securely
Allow multiple users to log in and manage their own data
Keep the data in the cloud so it’s accessible anywhere

My First Steps with Supabase

Signing up and creating a project was simple. I remember the first time I saw my empty database table.I felt both nervous and excited.

I created a table for expenses with just a few columns: amount, category, note, date, and a reference to the user. Suddenly, I had a real database in the cloud that my Python app could talk to.

What I Loved About Supabase

Using Supabase felt surprisingly simple and approachable. Even though I was a bit intimidated at first—questions like:

“How do I manage multiple users?”
“How do I keep my data secure?”

ran through my mind, it turned out to be much easier than I expected.

What I Learned

Cloud databases like PostgreSQL in Supabase make multi-user apps easy
Hands-on projects teach more than tutorials ever will
Small, simple apps are perfect for learning new tools and gaining confidence

Final Thoughts

Supabase gave me the confidence to actually build something real. Even as a beginner, I could store data securely, manage users, and interact with a cloud database directly from Python.

It’s amazing to see your app come to life with a real backend in the cloud, and it’s the perfect starting point for anyone wanting to go beyond local databases.

From Zero to Hello World: My Python Beginner Journey

Sareena Rahim — Sun, 19 Oct 2025 15:05:42 +0000

Ever since I became interested in the world of AI, I knew I had to learn a programming language. Python was the obvious choice-it’s beginner-friendly, widely used, and opens doors to AI, data science, web development, and more.

Starting this journey has been exciting, eye-opening, and sometimes… downright frustrating.But I’ve learned a lot about coding, problem-solving, and patience along the way.

Why I Chose Python

Beginner friendly:The syntax is clean and readable. Coming from math and English, Python felt like a soft landing into programming
AI Opportunities:Python is the language of choice for AI and machine learning, which was my primary interest.

My Struggles as a Beginner

1. Translating Logic to Code

When I first started, I knew logically what I wanted my program to do.But turning that into step-by-step code that a computer could understand was hard. Computers are strict; they need everything spelled out clearly.

2. Error Messages That Intimidate

Seeing a NameError, IndentationError, or TypeError for the first time can be terrifying. It feels like the computer is accusing you of a crime!

The Fix: Don’t panic. Read error messages from the bottom up.The last line usually tells you the type of error, and the line number is your best friend.

3. Indexing Confusion

In programming, counting starts at 0, not 1. I remember trying to access the 5th item in a list using my_list[5] and getting an IndexError because the indices go 0, 1, 2, 3, 4.

The Fix: Practice, practice, practice. Small repetitive exercises help you internalize zero-based indexing.

4. Choosing Between Loops

Understanding loops in theory is easy

Putting it into practice was confusing. I remember trying to create an input validation system where the program should keep asking the user for a number between 1 and 10 until they entered a valid one. I tried forcing a for loop and got stuck because I didn’t know in advance how many attempts the user would take

The Fix:The Fix: Strategic practice and a mental checklist helped

The ‘Counting vs. Condition’ Rule of Thumb:

Do I know how many times this loop needs to run? Use a for loop
Do I only know the condition, not the count? Use a while loop

Small Wins That Matter

Every program that runs successfully, no matter how small, feels like a victory:

Printing Hello World
Writing a program that takes user input
Looping through a list of items

These small wins are motivating.They remind you that progress is real, even if slow

Final Thoughts

Learning Python has been full of excitement, confusion, and little wins. Every day feels like a new puzzle.Sometimes frustrating, sometimes rewarding

Python has opened a door for me into the world of AI, and I’m excited to keep exploring, learning, and making mistakes along the way. It’s a journey, not a destination, and I’m enjoying every step of it.

Who knows? Your first “Hello World” could be the start of something amazing