Something big.

Something complicated.

Something I could put on GitHub and point to when someone asked what I had built.

It sounded logical.

It wasn’t.

My first large projects usually started with a burst of motivation. I would design the architecture, choose the libraries, create folders, write a README, and convince myself I was building something important.

Two weeks later, I was still working on authentication.

A few weeks after that, I was debugging an API integration I barely understood.

Eventually, the project would become too complicated to enjoy and too unfinished to show anyone.

Then I tried something different.

I started building small projects.

One automation script.

One API.

One PDF extractor.

One AI tool.

One data pipeline.

One command-line application.

The projects were nowhere near as impressive individually.

But after building ten of them, I noticed something strange.

I had learned more from those ten tiny projects than I had from months of working on one ambitious application.

Here’s why.

1. Small Projects Force You to Finish

This sounds obvious.

It isn’t.

There’s a huge difference between starting a project and finishing one.

When a project is large, it’s easy to spend weeks working without reaching a meaningful finish line.

You can always add another feature.

Authentication isn’t finished.

The database needs optimization.

The UI needs redesigning.

The API needs another endpoint.

The deployment isn’t ready.

There’s always something.

Small projects don’t give you that luxury.

If I decide to build a Python script that automatically organizes PDFs, the scope is clear.

Find PDFs
   ↓
Read filenames
   ↓
Categorize
   ↓
Move files

That’s something I can finish.

And finishing matters more than beginners realize.

Every completed project teaches you the entire development cycle:

Idea
 ↓
Design
 ↓
Code
 ↓
Debug
 ↓
Test
 ↓
Finish

If you only build one giant project, you might experience that cycle once.

Build ten small projects, and you experience it ten times.

That’s ten opportunities to get better.

2. You Encounter More Problems

This is probably the biggest advantage.

A large project tends to keep you inside one technical ecosystem for a long time.

You might spend three months building a web application using the same framework, database, and deployment setup.

You become good at that stack.

But you don’t necessarily become good at solving unfamiliar problems.

Small projects force you to switch contexts.

One week you might build:

Project 1: A web scraper.

Then:

Project 2: A REST API.

Then:

Project 3: A PDF parser.

Then:

Project 4: An AI document extractor.

Then:

Project 5: A CLI tool.

Each project introduces a slightly different problem.

And that’s where learning accelerates.

You start encountering questions like:

How should I handle API failures?

How do I validate this data?

Why is this request so slow?

How should I structure this project?

How do I process 10,000 files without loading everything into memory?

Those questions are much more valuable than memorizing another syntax rule.

3. Small Projects Make Experimentation Cheap

One of my favorite things about small projects is that failure doesn’t cost much.

Suppose I want to test a new Python library.

In a large application, introducing it can feel risky.

I have to consider dependencies.

Existing architecture.

Compatibility.

Tests.

Deployment.

Other parts of the application.

So I might never try it.

With a small project, I can simply create:

experiment/
    main.py
    requirements.txt

and start.

If the library is terrible?

Delete the folder.

If it’s useful?

Now I know something.

This is one reason I like small projects for learning new AI tools.

Instead of spending a month integrating a new model into an existing application, I can build a tiny prototype in a weekend.

For example:

PDF
 ↓
Extract text
 ↓
LLM
 ↓
Structured JSON

That’s enough to answer the important question:

Does this approach actually work?

You don’t need a production architecture to answer that.

4. You Learn to Work Without Tutorials

This is where things get interesting.

When you’re following a tutorial, the path is already decided.

Install this.

Create this file.

Write this function.

Run this command.

Fix this error.

Repeat.

You learn how to follow instructions.

Small projects eventually remove that safety net.

You have an empty directory.

No tutorial.

No step-by-step instructions.

Just a problem.

That’s uncomfortable.

It’s also where real programming begins.

I remember building small automation scripts where I knew roughly what I wanted but had no idea how to structure the code.

I searched documentation.

Read GitHub issues.

Tested small pieces.

Asked AI for explanations.

Deleted code.

Started again.

That process taught me much more than copying a finished implementation.

The goal isn’t to avoid tutorials.

They’re useful.

The goal is to eventually become comfortable when there isn’t one.

5. Ten Projects Give You Ten Chances to Practice Architecture

Architecture is difficult to learn from theory alone.

You understand it differently after making the same mistake several times.

My early projects had functions that did everything.

Something like:

def process_everything():
    # read files
    # call API
    # clean data
    # save database
    # send email
    # print report

It worked.

Until I needed to change one part.

Then I realized that everything depended on everything else.

After building several projects, I naturally started separating responsibilities.

Input
 ↓
Processing
 ↓
Business logic
 ↓
Storage
 ↓
Output

Then I started recognizing reusable patterns.

Configuration should be separate.

External API calls should be isolated.

Validation should happen near the boundary.

Business logic shouldn’t care about how data was retrieved.

You don’t necessarily learn those lessons by reading about architecture.

You learn them by breaking your own code.

Repeatedly.

6. Small Projects Give You a Portfolio With Evidence

There’s another benefit that doesn’t get discussed enough.

Ten small projects can tell a better story than one unfinished project.

Imagine two GitHub profiles.

Developer A

One enormous project:

“AI-powered productivity platform”

Repository contains 47 directories.

README says:

“Coming soon.”

Developer B

Ten small projects:

• PDF invoice extractor
• YouTube transcript summarizer
• CSV cleaning tool
• FastAPI service
• Web scraper
• AI document classifier
• File organizer
• CLI productivity tool
• Automated report generator
• Database-backed application

The second developer has demonstrated something important.

They finish things.

Even if none of the projects is revolutionary.

A portfolio doesn’t only demonstrate what you know.

It demonstrates what you can build.

7. You Start Connecting Projects

This is the part I didn’t expect.

Small projects don’t necessarily stay small.

Sometimes one becomes a component of another.

Imagine you build:

Project 1: PDF text extraction.

Then:

Project 2: AI classification.

Then:

Project 3: Structured data validation.

Then

Project 4: Database storage.

Eventually, you realize:

PDF
 ↓
Extraction
 ↓
AI classification
 ↓
Validation
 ↓
Database

You have accidentally built the foundation of a document-processing application.

That’s much easier than starting with:

“I’m going to build a complete AI document platform.”

The first approach lets complexity emerge naturally.

The second forces you to design everything before you understand the problem.

That’s an important distinction.

8. You Discover What You Actually Enjoy

This is another reason I recommend small projects to people who aren’t sure what area of programming they want to pursue.

You might think you want to become a frontend developer.

Then you build three frontend projects and realize you hate CSS.

That’s useful information.

Maybe you love databases.

Maybe APIs are your thing.

Maybe you enjoy automation.

Maybe you become obsessed with machine learning.

You don’t need to decide your entire career before experimenting.

Build.

Notice what keeps your attention.

Build something else.

Compare.

Your interests become much clearer when you’re actually doing the work.

9. Small Projects Make AI More Useful

AI coding assistants have changed the economics of experimentation.

A few years ago, trying a completely unfamiliar library could mean spending hours reading documentation before writing your first useful line.

Now I can ask an AI assistant questions like:

“Show me the smallest example that uses this library to extract text from a PDF.”

Then I can test it.

If it works, I build on it.

If it doesn’t, I investigate why.

This doesn’t mean AI should build the entire project for you.

Quite the opposite.

Small projects give you a perfect environment for using AI as a learning accelerator.

Instead of asking:

“Build this entire application.”

ask:

“Why does this API return this error?”

“Explain what this function is doing.”

“Give me two ways to structure this component.”

“What would break if I processed 100,000 files?”

That’s where AI becomes extremely useful.

10. You Build Momentum

This might be the least technical reason.

But it matters.

Finishing something feels good.

You run the script.

It works.

You push it to GitHub.

Done.

Then you start another one.

That creates momentum.

Compare that with spending three months on a project where the finish line keeps moving.

Eventually, programming starts feeling like an endless task.

Small projects create visible progress.

Project 1 ✓
Project 2 ✓
Project 3 ✓
Project 4 ✓
Project 5 ✓

After ten projects, you have evidence that you can build things.

More importantly, you have evidence that you can finish things.

That confidence carries into larger projects.

But Don’t Make Your Projects Too Small

There’s a catch.

If your project takes 15 minutes, you’re probably not learning enough.

The goal isn’t to build ten useless scripts.

The goal is to build small but complete projects.

A good project might take a weekend.

For example:

Too small

Write a Python function that reverses a string.

You already know the answer.

Better

Build a CLI tool that searches a folder and finds duplicate files.

Now you have to think about:

• File handling
• Hashing
• CLI arguments
• Error handling
• Performance
• User output

Even better

Build a tool that identifies duplicate files, lets the user review them, and safely moves duplicates into an archive.

Now you have a real engineering problem.

That’s the sweet spot.

Small enough to finish.

Large enough to struggle with.

The 10-Project Challenge I’d Actually Recommend

If you’re learning Python, don’t build ten random projects.

Build ten projects that progressively expose you to different problems.

For example:

Project 1 — File Organizer

Learn:

• pathlib
• File operations
• Exceptions

Project 2 — CSV Cleaner

Learn:

• pandas
• Data validation
• Data transformation

Project 3 — API Client

Learn:

• HTTP
• JSON
• Error handling

Project 4 — Web Scraper

Learn:

• HTTP requests
• HTML parsing
• Data extraction

Project 5 — PDF Extractor

Learn:

• PyMuPDF
• Document processing

Project 6 — AI Summarizer

Learn:

• LLM APIs
• Prompt design
• Structured outputs

Project 7 — FastAPI Service

Learn:

• REST APIs
• Request validation
• Application structure

Project 8 — Database Application

Learn:

• SQL
• SQLAlchemy
• Persistence

Project 9 — Automated Report Generator

Combine:

• Data processing
• APIs
• PDFs
• Templates

Project 10: Your Own Real Problem

This is the most important one.

Don’t copy something from a tutorial.

Find something you personally repeat.

Then automate it.

That’s where all the previous projects start connecting.

What Happened When I Started Doing This

The biggest change wasn’t that I suddenly knew ten times more Python.

It was that I became much faster at entering unfamiliar territory.

When I see a new library now, I don’t immediately try to learn everything it can do.

I ask:

What can I build with this in a weekend?

That question is surprisingly powerful.

It forces me to move from documentation to implementation.

And implementation reveals things documentation doesn’t.

You discover awkward APIs.

Unexpected edge cases.

Performance problems.

Missing features.

Better alternatives.

Those discoveries are where experience comes from.

Final Thoughts

I no longer believe that your biggest project is necessarily your best learning project.

A giant application can teach you a lot.

But ten small projects expose you to ten different sets of problems.

You learn to start.

You learn to debug.

You learn to read documentation.

You learn to work without tutorials.

You learn to make architectural decisions.

You learn to finish.

And eventually, something interesting happens.

The small projects stop being isolated experiments.

They become building blocks.

One teaches you APIs.

Another teaches you databases.

Another teaches you AI.

Another teaches you automation.

Then you combine them.

And suddenly, you’re ready to build the big project you originally wanted to build.

So if you’ve been stuck on one ambitious project for months, try something different.

Close it for a weekend.

Build something small.

Finish it.

Then build another.

You might be surprised by how quickly ten small wins turn into one very capable developer.

Why Building 10 Small Projects Beats Building One Big Project was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

I started because I was curious. Then I stayed because I realized something uncomfortable: most people don’t fail at Python. After all, it’s hard; they fail. After all, they build things that don’t solve anything real.

At some point, I stopped asking “What can I build with Python?” and started asking:

“What problem would someone actually pay me to solve?”

That shift changed everything.

In this article, I’m breaking down 5 Python projects I built that didn’t just sit in my GitHub they turned into actual income streams. Some became freelancing gigs. Some turned into automation tools I still use. One of them almost replaced a full-time workflow for a client.

No theory. Just systems, scripts, and outcomes.

1) AI Proposal Generator for Freelancers (That Writes Itself Better Than Most Humans)

The first thing I noticed while freelancing was simple: people don’t struggle with skill they struggle with writing proposals that sound convincing.

So I built a tool that takes:

• Job description
• Client name
• Past experience (markdown-based)

And outputs a tailored proposal in seconds.

The idea wasn’t “AI writing.” The idea was reducing friction between opportunity and application.

Here’s the core logic:

prompt = f"""
You are an expert freelance proposal writer. Rewrite the proposal to match the job description.
Focus on clarity, persuasion, and relevance.
Resume:
{resume_md}
Job:
{job_description}
Return a structured proposal.
"""

Then I plugged it into OpenAI’s API and wrapped it with a simple CLI.

What happened next surprised me:

• I used it for my own freelancing
• Then I sold it as a mini tool
• Then, clients started requesting custom versions

One client literally said:

“This sounds like me, but the confident version of me.”

That’s when I knew: automation doesn’t replace humans. It amplifies their best version.

2) YouTube Lecture Summarizer That Became an Affiliate Funnel

This started as a personal frustration.

I had 100+ YouTube videos saved and zero time to watch them.

So I built a Python script that:

• Extracts YouTube transcripts
• Summarizes them using GPT
• Saves key insights into markdown notes

from youtube_transcript_api import YouTubeTranscriptApi
video_id = "abc123xyz"
transcript = YouTubeTranscriptApi.get_transcript(video_id)
text = " ".join([t["text"] for t in transcript])

Then I added summarization:

summary_prompt = f"Summarize this in bullet points:\n{text}"

But here’s where it became interesting.

I started publishing summaries on a blog.

Then I added:

• Tool recommendations
• Course links
• Developer resources

And suddenly:

• Traffic turned into clicks
• Clicks turned into affiliate income

The tool didn’t just save time.

It accidentally became a content engine.

3) Resume Optimization Tool (Freelance Service in Disguise)

This one started as a joke.

I thought: What if resumes could adapt like algorithms?

So I built a system that rewrites resumes based on job descriptions.

It works in three steps:

Convert resume into markdown

Feed job description

Regenerate optimized resume

response = openai.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": prompt}]
)

The interesting part wasn’t the code.

It was the outcome.

People don’t want “better resumes.” They want better chances of getting hired.

I offered this as a microservice on freelancing platforms.

Within weeks:

• Recruiters started asking for bulk processing
• Job seekers wanted personalized versions
• I turned it into a paid automation service

This is where I learned something important:

“People don’t buy tools. They buy outcomes wrapped in tools.”

4) PDF Intelligence System for Small Businesses

This is the most underrated income stream I built.

Companies are sitting on thousands of PDFs:

• Reports
• Contracts
• Research documents

And no one actually reads them.

So I built a system that:

• Extracts text from PDFs
• Embeds them using sentence-transformers
• Allows semantic search

from sentence_transformers import SentenceTransformer
model = SentenceTransformer("all-MiniLM-L6-v2")
embeddings = model.encode(["document text here"])

Then I added clustering and search.

What changed everything was packaging it as:

“Ask your documents anything.”

Small firms started using it to:

• Find clauses in contracts
• Summarize reports
• Search internal knowledge

It turned into a consulting gig.

Not because the tech was complex.

But because information chaos is expensive for businesses.

5) Price Tracker Bot That Prints Money Quietly

This one started as pure curiosity.

I wanted to track product prices automatically.

So I built a scraper + alert system:

import requests
from bs4 import BeautifulSoup
page = requests.get(url)
soup = BeautifulSoup(page.text, "html.parser")
price = soup.find("span", class_="price").text

Then I added:

• Scheduled checks
• Email alerts
• Price drop detection

But here’s where it became interesting.

I extended it into:

• Amazon tracking
• Course discount alerts
• SaaS pricing monitoring

Then I realized something:

People don’t want data.

They want timing advantage.

I monetized it by:

• Offering it as a paid alert system
• Adding premium tracking features
• Bundling niche trackers for marketers

It became a micro-SaaS without me realizing it.

The Real Pattern Behind All 5 Projects

If you look closely, none of these ideas are “AI projects.”

They are automation systems wrapped in real-world painkillers.

That’s the difference.

I didn’t succeed because I wrote better Python.

I succeeded because I stopped building things that were “interesting” and started building things that were useful under pressure.

Final Thought

If there’s one thing I’ve learned after building and monetizing Python systems, it’s this:

“The fastest way to make money with code is to remove work someone already hates doing.”

Python is just the interface.

The real product is relief.

If you’re building right now, don’t ask what’s possible.

Ask what’s repetitive, boring, and already costing someone time or money.

Then automate that.

That’s where income starts.

— Arslan

5 Things I Built with Python That Turned Into Income Streams was originally published in Python in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

I used to think serious programmers only built serious projects.

You know the type of project I mean.

A fully autonomous AI SaaS platform.
A custom-trained LLM.
A productivity app with real-time collaboration, payment integration, analytics, and a dashboard so complicated it looked like a spaceship control panel.

So naturally, four years ago, I tried building one.

It failed in eleven days.

Not because I couldn’t code it. That’s the dangerous part. Most developers overestimate technical difficulty and underestimate psychological difficulty. Writing code is one thing. Continuing to write code after the excitement disappears is another.

That project taught me something I wish more Python developers understood earlier:

Small projects are not “beginner projects.”
They are often the fastest path to becoming dangerously good.

And ironically, most experienced developers ignore them.

The Trap of the “Big Project Mentality”

A lot of programmers secretly believe complexity equals intelligence.

So instead of building something useful in a weekend, they spend six months architecting a system nobody asked for.

I’ve done this myself.

At one point, I started building an AI automation platform that would summarize documents, generate reports, classify emails, automate spreadsheets, and schedule tasks.

Sounds impressive.

But after three weeks, I was still configuring folder structures and rewriting APIs I didn’t even need yet.

Meanwhile, one of my smallest projects quietly became one of the most useful things I’ve ever built.

It was a 70-line Python script.

That script automatically renamed messy downloaded files using AI-generated summaries.

That’s it.

No frontend.
No fancy database.
No “launch announcement” on LinkedIn.

But I used it every single day.

And that changed how I think about coding projects forever.

Small Projects Solve Real Problems Faster

Most developers start with technology.

“What can I build with AI?”
“What can I build with FastAPI?”
“What can I build with LangChain?”

But strong developers start somewhere else:

“What problem annoys me repeatedly?”

That one question changes everything.

Because once a project solves a real annoyance, motivation becomes automatic.

You stop coding for discipline.
You code because the problem is irritating enough to fix.

One of my favorite automation scripts started from pure laziness.

I was tired of manually organizing screenshots from research sessions. So I built a tiny Python workflow that:

• Watches a folder
• Reads image text with OCR
• Categorizes screenshots
• Moves them into topic-based folders automatically

The first version was ugly.

But ugly working software beats beautiful unfinished software every time.

Here’s a simplified version of the folder watcher:

from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler
import time
class Watcher(FileSystemEventHandler):
    def on_created(self, event):
        print(f"New file detected: {event.src_path}")
observer = Observer()
observer.schedule(Watcher(), path="./screenshots")
observer.start()
while True:
    time.sleep(1)

Simple project.
Massive daily impact.

That’s the kind of automation most developers underestimate.

“Take a quick pause and check out this ebook a friend of mine made. If you’ve been wanting to learn machine learning without feeling overwhelmed, this might be exactly what you need.”

Real World Machine Learning Projects - Ebook

Big Projects Hide Weaknesses

This is something nobody talks about enough.

Large projects make it easy to feel productive without actually improving.

You spend hours:

• configuring environments
• organizing folders
• tweaking UI details
• renaming variables
• watching tutorials

Meanwhile, your actual problem-solving skills barely move.

Small projects expose weaknesses immediately.

Can you:

• design a clean workflow?
• automate repetitive tasks?
• handle edge cases?
• make tools reliable?
• finish what you started?

That last one matters more than most people realize.

Because unfinished projects teach bad habits.

Finished projects teach engineering.

The Best Python Developers I Know Build Tiny Tools Constantly

This surprised me when I started working with more experienced developers.

The strongest Python programmers rarely obsess over giant applications.

Instead, they build tiny internal tools constantly.

Things like:

• log analyzers
• scraping scripts
• automation workflows
• local AI assistants
• report generators
• data cleanup tools
• file converters
• browser automation bots

These projects sound boring until you realize something important:

Boring projects often make the most money.

Companies don’t always need revolutionary AI systems.

Sometimes they just need a script that saves employees two hours every day.

And Python is ridiculously good at this.

A few months ago, I built a lightweight automation tool that summarized unread PDFs inside a folder every morning using an LLM API.

The funny part?

The hardest part wasn’t the AI.

It was handling broken filenames.

That’s real software engineering.

Small Projects Create Faster Feedback Loops

One reason beginners quit programming is because their projects take too long to feel rewarding.

Humans need visible progress.

Small projects compress the learning cycle:

• idea
• build
• break
• debug
• improve
• ship

You repeat this loop faster, and your skills compound aggressively.

I sometimes force myself to build projects with a strict 48-hour limit.

That time pressure changes your decisions instantly.

You stop overengineering.

You stop chasing perfection.

You stop adding features nobody needs.

You focus on shipping.

And honestly, that mindset alone will put you ahead of most developers.

“A good plan violently executed now is better than a perfect plan executed next week.”

That quote applies to software more than people realize.

Automation Is Where Small Projects Become Powerful

This is especially true with AI tools.

Right now, we’re living in a strange era where one Python developer can automate tasks that previously required entire teams.

But most people waste that power building demos instead of solving friction.

The best automation ideas usually sound almost too simple.

For example:

• automatically summarizing meeting notes
• cleaning CSV files
• generating reports
• organizing research papers
• filtering emails
• renaming files intelligently
• monitoring websites
• generating documentation

Individually, these sound tiny.

Collectively, they become insanely valuable.

One small script I built checks my project folders every evening and generates a Markdown summary of unfinished work.

It takes less than 10 seconds to run.

But psychologically, it feels like having a second brain.

Here’s a minimal example:

import os
for file in os.listdir("./projects"):
    print(f"Pending review: {file}")

Tiny code.
Real utility.

That combination is underrated.

The Hidden Advantage Nobody Mentions

Small projects make you fearless.

When a project only takes a weekend, experimentation becomes cheap.

You try weird ideas.
You test APIs faster.
You learn libraries naturally.
You stop being scared of failure.

That freedom is where real growth happens.

Ironically, some of my best programming lessons came from projects that completely failed.

One weekend, I tried building an AI system that categorized research papers automatically.

The clustering was terrible.

The embeddings were noisy.

The outputs barely made sense.

But during that project, I learned more about vector search, preprocessing, and data pipelines than I did from weeks of tutorials.

That’s the magic of small projects.

Even failed ones pay you back in skill.

What I’d Recommend to Every Python Developer

If you’ve been stuck planning a huge project for months, try this instead:

Build something painfully practical.

Something slightly annoying.
Something repetitive.
Something you personally want automated.

Then finish it fast.

Not in six months.
Not “when everything is perfect.”
Not after rewriting the architecture four times.

This weekend.

Because the developers improving the fastest right now are not necessarily the smartest ones.

They’re the ones building constantly.

Small project after small project.
Tiny automation after tiny automation.
Problem after problem.

And eventually, those “small” projects stack into something very big:
real expertise.

That’s when Python stops feeling like a programming language.

And starts feeling like a superpower.

Check out the products my friend created, not just for programmers, but for anyone trying to break into tech and learn useful skills along the way.

• Python Starter Guide for Non Programmers
• Real World Machine Learning Projects - Ebook
• Master Python Fast: The Only Cheat Sheet You'll Ever Need

Why Small Coding Projects Often Beat Big Ones was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few months ago, I opened one of my old Python projects and immediately realized something uncomfortable.

The code worked.

But I had no idea why I wrote half of it that way.

That moment bothered me more than any bug I had fixed that week.

Because for years, I thought improving as a programmer meant learning more syntax, watching more tutorials, and collecting more frameworks like Pokémon cards. Every few weeks, I’d jump into another “Complete Course” convinced this one would finally make me feel like an advanced developer.

It never did.

And if your coding skills feel stuck right now, there’s a good chance you’re trapped in the same cycle.

Not because you’re lazy.

Not because you’re bad at programming.

But because you’re learning programming the wrong way.

The strange part is that most developers don’t realize this until years later.

The Tutorial Trap Feels Productive

One of the most dangerous things in programming is fake progress.

You finish a 4-hour tutorial.

You clone a GitHub repository.

You build another to-do app.

Your brain rewards you like you accomplished something massive.

But then someone asks you to automate a real workflow from scratch and suddenly your mind goes blank.

I learned this the hard way during my second year working heavily with Python automation.

I could build APIs.

I understood decorators.

I knew asynchronous programming.

But when I tried automating a boring real-world task for myself, I froze for nearly an hour staring at an empty VS Code window.

That’s when I realized something important:

Knowing Python is not the same thing as solving problems with Python.

Those are two completely different skills.

And most developers accidentally spend years optimizing only the first one.

“Take a quick pause and check out this ebook a friend of mine made. If you’ve been wanting to learn machine learning without feeling overwhelmed, this might be exactly what you need.”

Real World Machine Learning Projects - Ebook

Real Growth Happens When You Remove Friction

The biggest leap in my coding ability happened when I stopped asking:

“How do I learn this technology?”

And started asking:

“What problem annoys me enough to automate?”

That single shift changed everything.

Instead of building random portfolio projects, I started building tiny systems that removed friction from my daily life.

One of the first examples was embarrassingly simple.

I was tired of manually renaming hundreds of downloaded research PDFs.

So I wrote a small Python script that automatically cleaned filenames, extracted keywords, and organized documents into folders.

The script itself wasn’t revolutionary.

But the thinking process behind it was.

For the first time, I wasn’t copying a tutorial.

I was designing logic.

That’s where real programming skill develops.

Not in passive learning.

Not in endless note-taking.

But in the uncomfortable space where you’re forced to make decisions yourself.

Most Developers Avoid the Hard Part

Here’s something nobody tells beginners:

The hardest part of coding is not writing code.

It’s thinking clearly.

Experienced developers aren’t faster because they memorize more functions.

They’re faster because they’ve trained themselves to break messy problems into smaller systems.

That’s why senior engineers can often solve problems with surprisingly little code.

They think before they type.

Beginners usually do the opposite.

I used to open my editor instantly and start coding random pieces hoping clarity would appear halfway through.

It rarely did.

Now my workflow looks completely different.

I spend more time designing workflows than writing actual Python.

Especially for automation projects.

For example, before building an AI-powered document summarizer, I mapped the entire pipeline first:

• Where does the data come from?
• What format is the input?
• Where can failures happen?
• Which part should AI handle?
• Which part should stay deterministic?

Only after answering those questions did I write code.

Ironically, this made development dramatically faster.

Automation Teaches You What Tutorials Can’t

Automation projects expose weaknesses brutally fast.

That’s why they’re so effective.

A weather app tutorial won’t teach you much about software thinking.

But automating something messy from your real life absolutely will.

Because real workflows are chaotic.

Files break.

APIs fail.

Data arrives incomplete.

Users do irrational things.

And suddenly your elegant little script turns into a battlefield.

That pressure forces growth.

A few years ago, I built a Python automation that generated summaries from long technical YouTube lectures so I could review them faster.

At first, the script worked perfectly.

Until it didn’t.

Some transcripts were malformed.

Others had weird timestamps.

One video returned empty text entirely.

The tutorial version of me would’ve quit there.

But solving those edge cases taught me more than 20 courses combined.

That’s the hidden value of automation projects:

They force you to think like an engineer instead of a student.

The Internet Lies About “Advanced” Coding

This might sound controversial, but most developers massively overestimate what advanced programming looks like.

They think advanced developers constantly write complex algorithms and impossible architectures.

In reality?

A huge amount of professional programming is just:

• moving data,
• cleaning data,
• automating repetitive tasks,
• connecting systems together,
• and reducing human effort.

That’s why Python became so dominant in automation and AI workflows.

Its real superpower is leverage.

A small amount of Python code can eliminate hours of manual work.

For example, this tiny script saved me ridiculous amounts of time while organizing datasets:

from pathlib import Path
for file in Path("downloads").glob("*.csv"):
    new_name = file.stem.lower().replace(" ", "_")
    file.rename(file.with_name(f"{new_name}.csv"))

Simple?

Very.

Useful?

Extremely.

That’s another thing beginners misunderstand:

Useful code beats clever code almost every time.

Your Brain Needs Struggle to Improve

One reason coding skills plateau is because developers avoid cognitive resistance.

They consume content instead of producing solutions.

Watching tutorials feels smooth.

Building alone feels frustrating.

But frustration is where skill formation actually happens.

I once spent an entire weekend debugging a multiprocessing issue in Python that turned out to be a tiny serialization mistake.

At the time, it felt painful.

Now I’m grateful for it.

Because difficult debugging sessions permanently improve how you think.

You start recognizing patterns faster.

You stop panicking when systems fail.

You learn how software behaves under stress.

That confidence cannot be downloaded from YouTube.

It has to be earned through repetition and failure.

As the old programming saying goes:

“Smooth seas do not make skillful sailors.”

The same applies to developers.

AI Changed the Rules — But Not the Fundamentals

Tools like OpenAI, Cursor, and GitHub Copilot dramatically accelerated development.

I use them constantly.

But they also exposed something interesting.

Developers who already understand systems became exponentially faster.

Developers who relied entirely on tutorials became dependent on AI-generated guesses.

Because AI can generate code.

But it cannot automatically give you engineering judgment.

You still need to:

• define the problem,
• structure the workflow,
• evaluate tradeoffs,
• and debug intelligently.

That’s why strong fundamentals matter more than ever now.

The future belongs to developers who can combine automation thinking with AI tools effectively.

Not developers who memorize syntax.

The Real Reason You Feel Stuck

Your coding skills probably aren’t stuck because you need another course.

They’re stuck because you’ve consumed more programming than you’ve created.

There’s a massive difference.

The developers improving the fastest right now are not necessarily the smartest people in the room.

They’re simply building more.

More experiments.

More automations.

More imperfect projects.

More systems that solve real annoyances.

That repetition compounds quietly.

Until one day you realize you’re no longer intimidated by blank screens.

You just start building.

And honestly, that’s when programming becomes fun again.

Check out the products my friend created, not just for programmers, but for anyone trying to break into tech and learn useful skills along the way.

• Real World Machine Learning Projects - Ebook
• Master Python Fast: The Only Cheat Sheet You'll Ever Need
• Python Starter Guide for Non Programmers

A message from our Founder

Hey, Sunil here. I wanted to take a moment to thank you for reading until the end and for being a part of this community. Did you know that our team run these publications as a volunteer effort to over 3.5m monthly readers? We don’t receive any funding, we do this to support the community.

If you want to show some love, please take a moment to follow me on LinkedIn, TikTok, Instagram. You can also subscribe to our weekly newsletter. And before you go, don’t forget to clap and follow the writer️!

The Real Reason Your Coding Skills Feel Stuck was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

I still remember the exact moment I realized I was learning Python the wrong way.

I had 17 browser tabs open. One YouTube tutorial was teaching loops. Another was teaching APIs. A third guy was building a weather app while casually skipping over half the code like everyone watching already had 10 years of experience.

Meanwhile, I was sitting there wondering why my program kept returning None.

That’s the strange thing about learning Python today. There are too many resources. Courses promise to turn you into a developer in 30 days. Bootcamps sell the dream of six-figure salaries. Every second creator claims they have the “ultimate roadmap.”

But after four years of writing Python almost daily, I’ve realized something important:

The best way to learn Python is not by collecting tutorials.

It’s by building things that annoy you enough to solve.

That shift completely changed how I learned programming.

And ironically, it saved me thousands of rupees in courses I never needed.

I Stopped Learning Python Like a Student

Most beginners treat programming like school.

Watch lesson → take notes → copy code → forget everything two days later.

I did that too.

For months, I knew Python syntax but couldn’t actually build anything.

Ask me what a list comprehension was? Easy.

Ask me to automate a boring task on my laptop? Total silence.

The turning point came when I got tired of doing repetitive work manually.

One day, I had around 40 PDF files scattered across different folders. Renaming them one by one felt painful. So instead of searching for another tutorial, I searched for one thing:

“How to rename files using Python.”

That tiny project taught me more than three weeks of tutorials combined.

Here’s the funny part: the script itself was ridiculously simple.

from pathlib import Path
folder = Path("documents")
for file in folder.iterdir():
    if file.is_file():
        new_name = f"python_{file.name}"
        file.rename(folder / new_name)

That’s it.

No advanced AI.
No fancy frameworks.
No complicated architecture.

But for the first time, Python felt useful instead of theoretical.

And usefulness is addictive.

I Learned Faster Once I Became Lazy

There’s a hidden superpower behind most good Python developers:

They hate repetitive tasks.

Seriously.

A lot of my learning came from trying to avoid boring work.

I built scripts to:

• Organize messy folders
• Convert CSV files automatically
• Scrape information from websites
• Rename hundreds of images
• Generate article outlines
• Clean datasets in seconds
• Automate screenshots
• Bulk-convert file formats

At some point, Python stopped feeling like a programming language.

It started feeling like a personal assistant.

That’s when automation becomes dangerous in a good way. Once you automate one annoying task, your brain starts spotting automation opportunities everywhere.

“Take a quick pause and check out this ebook a friend of mine made. If you’ve been wanting to learn machine learning without feeling overwhelmed, this might be exactly what you need.”

Real World Machine Learning Projects - Ebook

You stop asking:

“What project should I build?”

And start asking:

“What problem is wasting my time right now?”

That question is where real developers are created.

The Internet Already Has Everything You Need

This might sound controversial, but most beginner Python courses are teaching information you can already learn for free in better ways.

Here’s what actually taught me Python:

• Documentation
• Stack Overflow
• GitHub repositories
• YouTube debugging videos
• Reddit discussions
• Open-source projects
• Building broken projects and fixing them

Especially the last one.

Nothing teaches Python faster than debugging code that refuses to work.

I used to think experienced developers magically wrote perfect code.

Then I started reading GitHub issues.

Turns out even advanced programmers spend half their time staring at error messages like detectives solving crimes.

One of the biggest improvements in my learning came when I stopped fearing errors.

Now, when I see something terrifying like:

KeyError: 'username'

I don’t panic anymore.

I investigate.

That mindset shift matters more than any certification.

ChatGPT Changed How I Learn Python

A few years ago, getting stuck could ruin an entire day.

Now?

AI tools compress hours of frustration into minutes.

And no, I’m not talking about blindly copy-pasting code.

That’s the fastest way to become dependent without understanding anything.

What actually helped me was using AI like a senior developer sitting beside me.

Instead of asking:

“Write this project for me.”

I started asking:

• “Why does this function fail?”
• “Explain this error simply.”
• “What’s a cleaner way to structure this?”
• “Why is my loop inefficient?”
• “How would an experienced Python developer solve this?”

That difference is massive.

Because Python is not just about writing code.

It’s about learning how programmers think.

The Biggest Mistake Beginners Make

Most people start with giant projects too early.

They want to build:

• An AI assistant
• A trading bot
• A full SaaS product
• A clone of ChatGPT

…before they understand file handling.

I made that mistake too.

The problem with oversized projects is they create fake progress. You spend more time watching tutorials than building confidence.

Small projects win because they create momentum.

One weekend project can teach:

• loops
• functions
• APIs
• debugging
• file handling
• libraries
• problem-solving

All naturally.

That’s why I always recommend automation projects first.

They’re practical, addictive, and immediately rewarding.

The Project That Changed Everything for Me

The project that truly leveled up my Python skills was embarrassingly simple.

I built a script that summarized long articles automatically.

At first, it barely worked.

The formatting broke.
The summaries were terrible.
The script crashed randomly.

But while building it, I learned:

• API handling
• JSON parsing
• prompt engineering
• text processing
• environment variables
• error handling

Without realizing it, I had crossed from “learning Python” into actually using Python.

That’s an important distinction.

The best developers don’t memorize everything.

They know how to figure things out quickly.

Why Free Resources Worked Better for Me

Paid courses often teach programming in a clean, perfect environment.

Real coding is messy.

Your dependencies break.
Your API stops responding.
Your script works yesterday but not today.
Your indentation suddenly destroys reality.

Free resources prepared me for that chaos because they forced me to search, experiment, fail, and adapt constantly.

And honestly, that’s what software development really is.

Not perfection.

Iteration.

There’s a quote I wrote in my notes years ago:

“Programming is just problem-solving with extra frustration.”

Still true.

My Actual Python Learning Routine

People often expect some complicated roadmap when they ask how I learned Python.

The reality was surprisingly simple.

Every day, I tried to do one of these:

• Build something tiny
• Improve an old script
• Read someone else’s code
• Debug an error
• Learn one new library feature
• Automate one annoying task

That consistency mattered more than intensity.

Even 30 focused minutes daily compounds aggressively in programming.

Especially when you’re building instead of consuming endlessly.

Final Thoughts

Looking back, I’m glad I didn’t spend thousands on courses.

Because the internet already had the best teachers:

• real projects
• real bugs
• real developers
• real experimentation

Python became easier once I stopped trying to “master” it and started using it to solve actual problems.

That’s the secret most tutorials miss.

The fastest way to learn Python is not to study harder.

It’s to become curious enough to automate your own life.

And once that happens, you stop needing motivation.

Because every annoying task starts looking like your next project.

Check out the products my friend created, not just for programmers, but for anyone trying to break into tech and learn useful skills along the way.

• Real World Machine Learning Projects - Ebook
• Master Python Fast: The Only Cheat Sheet You'll Ever Need
• Python Starter Guide for Non Programmers
• 7 ChatGPT Prompts Pack - For Python Developers

How I Learned Python Without Paying for a Course was originally published in Top Python Libraries on Medium, where people are continuing the conversation by highlighting and responding to this story.

A year ago, I thought I was already moving fast as a Python developer.

Then I watched a junior developer build a working API integration, write tests, generate documentation, and deploy a Docker container before I had even finished setting up my virtual environment.

That was the moment I realized something uncomfortable:

The best programmers in 2026 are not the ones writing the most code.

They are the ones building systems that write, debug, optimize, and automate code for them.

And honestly, once you start using the right AI tools, going back feels like trying to dig a tunnel with a spoon after using an excavator.

Over the last few months, I tested dozens of AI tools while building automation scripts, APIs, dashboards, and machine learning utilities in Python. Some were overhyped. Some were basically autocomplete with marketing. But a few completely changed how I work as a programmer.

These are the tools that genuinely made me faster.

1. Cursor Completely Changed How I Write Python

At first, I thought Cursor was just another AI editor trying to compete with VS Code.

I was wrong.

Cursor feels less like an editor and more like a senior engineer sitting beside you while you code.

The first time it impressed me was during a debugging session. I had a messy Python automation script that scraped PDFs, extracted text, and organized files into folders. Somewhere in the pipeline, memory usage kept exploding.

Normally, this would mean 40 minutes of debugging.

Cursor found the issue in seconds.

It noticed I was loading entire PDF objects into memory instead of processing them lazily. The scary part was not that it fixed the issue. The scary part was how naturally it explained the problem.

That’s when I realized AI coding tools had crossed a line.

They were no longer just generating snippets.

They were starting to reason about architecture.

One feature I use constantly is AI refactoring. You can literally highlight ugly code and say:

“Make this more Pythonic and optimize performance.”

And the output is often surprisingly solid.

Here’s a small example.

numbers = [1,2,3,4,5]
squared = list(map(lambda x: x*x, numbers))
print(squared)

Cursor suggested:

numbers = [1, 2, 3, 4, 5]
squared = [x**2 for x in numbers]
print(squared)

Simple? Yes.

But across thousands of lines of code, these micro-improvements compound fast.

“Take a quick pause and check out this ebook a friend of mine made. If you’ve been wanting to learn machine learning without feeling overwhelmed, this might be exactly what you need.”

Real World Machine Learning Projects - Ebook

The thing is, AI-generated code becomes dramatically better when your variable names are clean. Bad naming confuses models more than most developers realize.

2. OpenAI APIs Made Automation Feel Illegal

There’s something dangerous about how easy AI APIs became in 2026.

A few years ago, building intelligent systems required deep ML knowledge.

Now?

You can build absurdly powerful automations with 20 lines of Python.

One weekend, I built a script that:

• Read client emails
• Extracted project requirements
• Generated proposals
• Organized everything into folders
• Drafted follow-up messages automatically

The weirdest part?

Most of the complexity wasn’t AI anymore.

It was just glue code.

That’s a huge shift happening right now in software development. The bottleneck is no longer intelligence. The bottleneck is workflow design.

Here’s a tiny example of how simple modern automation became:

from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
    model="gpt-4.1-mini",
    messages=[
        {"role": "user", "content": "Explain decorators in Python simply"}
    ]
)
print(response.choices[0].message.content)

That single API call can power tutoring systems, automation agents, research tools, customer support bots, or code reviewers.

And programmers who understand how to chain these systems together are becoming incredibly valuable.

3. Perplexity AI Quietly Replaced Half My Google Searches

I didn’t expect Perplexity to become part of my daily programming workflow.

Now I use it constantly.

The reason is simple:

Google gives links.

Perplexity gives synthesized answers.

When I’m debugging a weird FastAPI issue or researching async Python patterns, I don’t want to open 17 tabs and read Stack Overflow arguments from 2019.

I want context fast.

Perplexity became incredibly useful for:

• Understanding new frameworks
• Summarizing documentation
• Comparing libraries
• Researching architecture decisions
• Learning unfamiliar concepts quickly

One thing I especially like is how it cites sources directly inside answers. That sounds small until you spend years trying to verify AI hallucinations manually.

And honestly, this is becoming a real programming skill now:

Knowing when to trust AI output and when to verify it.

The developers who survive this AI wave won’t be the ones who reject AI.

They’ll be the ones who know how to supervise it intelligently.

4. GitHub Copilot Became Much Better Than People Realize

A lot of developers dismissed Copilot because early versions felt like autocomplete on caffeine.

But the newer versions are significantly smarter.

What impressed me most was not code generation.

It was pattern recognition.

I noticed Copilot learning how I structure APIs, how I name functions, and even how I organize utility files.

After a few weeks, suggestions became eerily aligned with my coding style.

One particularly useful workflow is generating boilerplate instantly.

For example, when building Flask APIs:

from flask import Flask
app = Flask(__name__)
@app.route("/")
def home():
    return {"message": "API running"}

Copilot can scaffold routes, models, validation logic, and tests almost immediately after you start typing.

Does it replace engineers?

Not even close.

But it absolutely removes repetitive work.

And repetitive work is where developer energy usually dies.

5. Anthropic Claude Helped Me Think Better About Systems

Most people use AI tools only for generating code.

That’s a mistake.

Some of the biggest productivity gains come from using AI for thinking.

Claude became one of my favorite tools for architectural reasoning.

I’ve used it to:

• Plan backend systems
• Break down large automation pipelines
• Compare database strategies
• Analyze performance bottlenecks
• Review security risks

One thing I noticed immediately is that Claude tends to produce calmer, more structured explanations than many coding assistants.

That matters more than people think.

Because programming is not only about writing syntax.

It’s about reducing cognitive load.

A confused brain writes terrible software.

A clear brain builds systems.

That distinction changed how I work.

6. Replit Made Rapid Prototyping Ridiculously Easy

There’s a dangerous trap many developers fall into:

They spend weeks designing projects they never actually build.

Replit removes a lot of that friction.

You open a browser, start coding instantly, connect AI assistance, and deploy prototypes fast.

I used it recently to test an AI-powered document summarizer.

Normally I would:

• Configure environments
• Create repositories
• Set up dependencies
• Configure deployment
• Waste an hour fixing package conflicts

Instead, I had a working prototype running in under 30 minutes.

That speed matters.

Because momentum matters.

One of the biggest lies programmers tell themselves is:

“I’ll start once everything is set up properly.”

Experienced developers know the opposite is true.

Start messy. Optimize later.

What Most Developers Still Don’t Understand About AI

The biggest shift happening right now is not that AI writes code.

It’s that AI reduces friction.

That sounds subtle, but it changes everything.

The programmers growing fastest in 2026 are the ones aggressively removing repetitive work from their workflow.

They automate testing.

They automate documentation.

They automate debugging assistance.

They automate research.

And ironically, this gives them more time to think deeply about actual engineering problems.

That’s the part many people miss.

AI is not replacing great programmers.

It is amplifying them.

The difference between an average developer and a strong developer used to be skill.

Now it’s becoming leverage.

And leverage compounds fast.

Final Thoughts

I’ve been writing Python for years, and I can confidently say this is the most exciting time I’ve ever seen for programmers.

Not because AI is perfect.

It absolutely isn’t.

It hallucinates.

It makes bizarre architectural decisions.

Sometimes it confidently destroys working code like a raccoon inside a server room.

But if you learn how to work with these tools properly, your productivity ceiling changes dramatically.

My advice?

Don’t obsess over mastering every new framework.

Instead, learn how to combine AI tools with real engineering fundamentals.

That combination is becoming incredibly powerful.

And the developers who learn it early are going to have a massive advantage over the next few years.

Check out the products my friend created, not just for programmers, but for anyone trying to break into tech and learn useful skills along the way.

• Real World Machine Learning Projects - Ebook
• Master Python Fast: The Only Cheat Sheet You'll Ever Need
• Python Starter Guide for Non Programmers
• 7 ChatGPT Prompts Pack - For Python Developers

Top AI Tools for Programmers in 2026 was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

I thought I had it figured out.

Four years into Python, you start believing “beginner projects” are beneath you. You skim them, maybe build one in an afternoon, and move on.

Then I tried eight of them back-to-back.

Same tools. Same weekend constraint. Same goal: build something useful.

Five of them wasted my time.

Three of them quietly changed how I think about automation.

This is what actually happened.

The Mistake I Didn’t Realize I Was Making

Every project I picked initially came from the same mindset:

“What can I build with this library?”

That sounds harmless. It’s not.

It leads you to build things that demonstrate knowledge instead of solving problems. The result? You end up with code that works… but never gets used again.

The three projects that actually mattered came from a different question:

“What problem is annoying enough that I’d use this every week?”

That single shift filtered out 5 out of 8 ideas.

The 5 That Looked Good But Failed in Practice

Let’s get these out of the way.

1. Random Password Generator

Took 15 minutes. Felt productive.

Never used it again.

Why? Because built-in tools already do this better. No leverage, no automation loop, no reason to revisit.

2. CLI To-Do App

Classic beginner project.

I built it. It worked. It was clean.

I still opened my browser and used a web app the next day.

This taught me something uncomfortable:
If your project replaces something you already use, it has to be better, not just “yours.”

3. Weather Script

Fetch API → print temperature.

That’s it.

The problem wasn’t technical. It was context. I don’t need weather data in my terminal. I need it on my phone when I’m leaving the house.

Automation without context is just decoration.

4. File Renamer

Bulk renaming files sounds useful.

Until you realize you only needed it once.

Good automation tools are repeatable. This wasn’t.

5. Basic Web Scraper

Scraped headlines from a site.

Ran it twice.

Forgot it existed.

The issue? No downstream use. Data without a workflow is just noise.

The 3 That Were Actually Worth It

These didn’t just “work.” They stayed.

I still use versions of these today.

1. Resume Tailoring Script (Beginner — But Powerful)

This one surprised me.

I didn’t build it to learn APIs. I built it because I was tired of rewriting the same resume for every application.

The key insight:

The problem wasn’t writing a resume. It was rewriting it repeatedly.

So I automated the variation, not the base.

Here’s the core idea:

def tailor_resume(base_resume, job_desc):
    prompt = f"Adapt this resume to match this job:\n{base_resume}\n\nJob:\n{job_desc}"
    return call_llm(prompt)

That’s it.

But the impact?

• Applications went from 30 minutes → 5 minutes
• Consistency improved
• I applied to more roles without burning out

Pro tip: The real power isn’t in generating content. It’s in standardizing repetition.

2. YouTube Summarizer (The One I Actually Use Weekly)

I had a “Watch Later” graveyard.

Hundreds of videos. Zero progress.

So I built something that watches them for me.

Not perfectly. But good enough.

The workflow:

1. Extract transcript
2. Clean it
3. Summarize key ideas

Simple pipeline:

def summarize_video(transcript):
    return call_llm(f"Summarize this into key insights:\n{transcript}")

The difference this made was subtle but powerful:

• I stopped “saving content for later.”
• I started processing content immediately

This is where automation shines:

It removes the gap between intention and action.

3. PDF Organizer (The One That Felt Like Magic)

This one started as frustration.

My desktop had ~100 PDFs. Research papers, notes, random downloads.

I wasn’t reading them because finding anything felt like work.

So I built a system that:

• Extracts text
• Converts it into embeddings
• Groups similar documents

Core idea:

embeddings = model.encode(list_of_texts)
clusters = KMeans(n_clusters=5).fit_predict(embeddings)

That’s not the impressive part.

The impressive part is what happened after:

• Papers auto-grouped into topics I didn’t explicitly define
• I discovered connections between documents I forgot existed
• Searching became unnecessary

It didn’t just organize files.

It organized thinking.

What Made These 3 Different?

After building all eight, the pattern became obvious.

The useful ones had three things in common:

1. They Solved a Repeating Problem

Not a one-time annoyance.

Something that kept coming back.

2. They Fit Into My Existing Workflow

I didn’t have to remember to use them.

They replaced something I was already doing.

3. They Reduced Cognitive Load

This is the big one.

Good automation doesn’t just save time.

It removes decisions.

A Rule I Follow Now

If I can’t answer this, I don’t build the project:

“Where will this run in my life after I finish it?”

If the answer is vague, the project is dead.

The Hidden Trap of “Beginner Projects”

Most beginner ideas are designed to teach syntax.

Not to create value.

That’s fine when you’re starting.

But if you’ve been writing Python for even a year, you need to shift:

• From learning tools → solving problems
• From building demos → building systems
• From writing code → removing friction

What I’d Do Differently (If I Started Again)

I wouldn’t start with ideas.

I’d start with annoyances.

Then I’d ask:

• What do I repeat every day?
• What do I procrastinate because it’s tedious?
• What do I wish “just handled itself”?

That’s where the real projects are hiding.

Final Thought

There’s a weird irony in learning Python.

The better you get, the less impressive your projects look.

Because the best ones don’t scream complexity.

They quietly remove problems from your life.

And once they do…

You stop noticing them entirely.

That’s when you know you built something worth keeping.

I Tried 8 “Beginner” Python Ideas — Only 3 Were Worth My Time was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

I used to believe the fastest way to grow as a developer was to learn more languages.

Python this week. JavaScript next week. Rust when I felt ambitious. Go when I watched one too many system design videos.

It felt productive. It looked impressive.

But if I’m being honest, most of that time was just… movement without progress.

After four years of writing code (and rewriting the same ideas in different syntaxes), I started noticing patterns. Not the kind you learn from tutorials, but the kind you earn by wasting time.

These are the 7 lessons that finally changed how I approach programming, and why I stopped chasing languages and started building systems.

Real World Machine Learning Projects - Ebook

1. You Don’t Learn Programming — You Learn Patterns

Here’s the uncomfortable truth:

Switching languages doesn’t make you smarter. It just makes you retype the same ideas differently.

Loops. Conditions. Data transformations. APIs. State.

Different syntax. Same thinking.

I remember rewriting a simple automation script, from Python to JavaScript, thinking I’d “level up.”

But midway through, I realized something:

I wasn’t learning anything new. I was just translating.

That’s when it clicked:

Programming is pattern recognition, not syntax memorization.

Once you understand patterns, languages become tools, not identities.

2. Depth Beats Variety (Every Single Time)

There’s a point where learning another language gives you diminishing returns.

I hit that point hard.

I could write basic scripts in 5+ languages, but couldn’t build a solid system in any of them.

That’s dangerous.

Because surface-level knowledge feels like progress.

But depth is what pays.

When I finally committed to Python for automation, everything changed:

• My scripts got faster
• My debugging improved
• My thinking became sharper

And most importantly, I started solving real problems, not just completing tutorials.

Pro tip: “One language deeply understood beats five languages loosely explored.”

3. Automation Exposes Your Weaknesses Faster Than Anything

When you switch languages, you can hide behind syntax.

When you build automation, you can’t.

Automation forces you to think about:

• Edge cases
• Data flow
• Failures
• Scalability

I once built a simple file organizer. It worked perfectly, until it didn’t.

A single unexpected file format broke everything.

That’s when I learned:

Automation punishes shallow thinking.

Here’s a simplified version of what that script looked like:

import os
for file in os.listdir("downloads"):
    if file.endswith(".pdf"):
        os.rename(file, f"pdfs/{file}")

Looks clean. Works fine.

Until:

• The folder doesn’t exist
• A file already exists with the same name
• Permissions fail

That’s where real engineering begins.

4. Switching Languages Is Often Just Productive Procrastination

This one hurt.

Every time things got hard, I switched languages.

Not because I needed to, but because it felt like progress.

Stuck on a backend bug?
“Maybe I should try Node.js instead.”

Confused about concurrency?
“Let’s learn Go.”

But deep down, I knew what I was doing.

Avoiding difficulty.

“If you keep changing tools, you’ll never sharpen one.”

Real growth starts when you stay with the problem long enough to understand it.

5. The Best Developers Think in Systems, Not Code

Early on, I thought writing better code meant learning more syntax.

Now I know:

Better developers think in systems.

When I started focusing on automation projects, my mindset shifted:

Instead of asking:

• “Which language should I use?”

I started asking:

• “What system am I building?”
• “What inputs and outputs exist?”
• “Where can this break?”
• “How can this run without me?”

That shift is everything.

Because automation is not about code, it’s about removing yourself from the process.

6. Rewriting the Same Project Teaches You More Than Starting New Ones

I used to chase new ideas constantly.

New project. New stack. New excitement.

But the real growth came when I did something boring:

I rebuilt the same project multiple times.

A YouTube summarizer.
A resume optimizer.
A file organizer.

Each time:

• Cleaner logic
• Better structure
• Fewer dependencies
• More automation

That’s when I stopped being a “learner” and started becoming a builder.

7. Mastery Feels Boring (But That’s a Good Sign)

This is something nobody tells you.

When you stop switching languages, things get… predictable.

You know how to:

• Structure your code
• Debug issues
• Design workflows

It’s less exciting.

But far more powerful.

Because now, instead of asking:
“What should I learn next?”

You start asking:
“What can I automate next?”

And that’s where real leverage comes in.

The Shift That Changed Everything

I stopped chasing languages.

I started chasing problems.

That single shift turned everything around.

Instead of:

• Learning syntax → I built systems
• Watching tutorials → I shipped tools
• Switching stacks → I automated workflows

And ironically, I became a better programmer without learning more languages.

Final Thought

If you’re constantly switching languages, ask yourself:

Are you learning…
or just avoiding depth?

Because the developers who win aren’t the ones who know the most languages.

They’re the ones who can take one language, and turn it into leverage.

Build systems. Automate aggressively. Stay longer with problems.

Everything else is noise.

• Python Starter Guide for Non Programmers
• Real World Machine Learning Projects - Ebook
• 20 Productivity Prompts to Outsource to ChatGPT

7 Lessons I Learned After Constantly Switching Programming Languages was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

I didn’t start this experiment to learn Python.

I started it because I was tired.

Tired of seeing the same “build this AI project” posts go viral. Tired of bookmarking them. Tired of telling myself, “I’ll try this someday.”

So one weekend, I did something different.

I copied five of those ideas.

Not to learn them.
To stress-test them.

And what I found surprised me, not because the ideas were bad, but because they were incomplete in a way most developers don’t realize.

Python Starter Guide for Non Programmers

The Mistake I Almost Made (And You Probably Are Too)

Most developers approach projects like this:

“How can I use this new tool?”

That’s how I used to think too. It feels productive, but it’s shallow.

After building all five projects, I realized something uncomfortable:

The project doesn’t matter. The friction does.

If your project removes friction from a real problem, it becomes useful.
If it doesn’t, it becomes a GitHub repo you never open again.

So instead of blindly copying, I asked:

“Where is this idea actually painful in real life?”

That changed everything.

1. Resume Optimizer — The First Time It Actually Saved Me Time

I’ve tailored resumes before. It’s not hard. It’s just… draining.

So I built a simple script that rewrites my resume based on a job description.

At first, it felt unnecessary. Why automate something I can already do?

Then I tested it properly.

I applied to 12 roles in one sitting.

Normally: 2–3 hours.
With the script: under 30 minutes.

That’s when it clicked.

This wasn’t about intelligence. It was about removing repetition.

Here’s the core idea:

def tailor_resume(resume, job_desc):
    prompt = f"Adapt this resume to this job: {job_desc}"
    return llm(prompt + resume)

Simple. Almost stupidly simple.

But here’s the deeper insight:

Most people think AI replaces thinking.
It doesn’t.

It replaces retyping the same thought in 10 slightly different ways.

Pro tip: If a task feels boring but necessary, it’s probably automatable.

2. YouTube Summarizer — The Project That Exposed My Real Problem

I told myself I needed this.

“I watch too many long lectures. I need summaries.”

So I built it.

It worked perfectly.

And then… I didn’t use it.

That’s when I realized the truth:

I wasn’t overwhelmed by content. I was avoiding it.

Still, the project taught me something powerful.

Instead of summarizing everything, I modified it to extract only:

• actionable insights
• tools mentioned
• timestamps worth revisiting

That made it useful.

def extract_insights(transcript):
    return llm("Give only actionable takeaways:\n" + transcript)

The shift was subtle but critical.

Don’t summarize content.

Filter for decisions.

3. PDF Organizer — Where Things Started Getting Real

My desktop looked like a crime scene.

Random PDFs. Research papers. Half-read docs.

So I built an auto-organizer.

At first, I expected magic.

What I got instead was… clusters.

Not folders like “Machine Learning” or “Web Dev.”

But weird groupings like:

• “optimization + neural nets”
• “frontend performance + UX”

And that’s when it hit me:

AI doesn’t organize like humans. It organizes like reality.

It groups based on meaning, not labels.

That made it far more useful than manual folders.

embeddings = model.encode(docs)
clusters = KMeans(n_clusters=5).fit_predict(embeddings)

The real win wasn’t cleanliness.

It was discovering connections I didn’t know existed.

4. Multimodal Search — The Project That Broke My Brain

This one started as curiosity.

“How do you search inside images?”

Turns out, you don’t.

You translate images and text into the same mathematical space… and compare them.

That idea alone is wild.

But implementing it revealed something deeper:

Search is no longer about keywords. It’s about meaning alignment.

When I queried:

“graph showing model accuracy over time”

It returned the exact chart buried inside a 40-page PDF.

No tags. No captions.

Just understanding.

score = cosine_similarity(query_vec, doc_vec)

Short code. Massive implications.

This is where I stopped thinking like a programmer…
and started thinking like a system designer.

5. Knowledge Base QA — The Only Project That Felt Like a Product

This one combined everything.

Search + context + response.

But the real challenge wasn’t building it.

It was deciding what not to include.

Because here’s the trap:

The more data you feed, the worse the answers can get.

Noise kills clarity.

So I limited the system to:

• top 3 relevant chunks
• strict context boundaries
• minimal prompt instructions

And suddenly, the answers got sharper.

def answer(query, context):
    return llm(f"Answer using only this:\n{context}\nQ:{query}")

This felt different.

Not like a project.

Like something someone would actually use.

What Actually Happened Next

I expected five projects.

What I got was a completely different way of thinking.

Here’s the uncomfortable truth:

Most viral project ideas are 70% complete.

They show you what to build.
They don’t show you what makes it valuable.

That last 30%?

• removing friction
• narrowing scope
• focusing on real usage
• cutting unnecessary features

That’s where the real learning is.

The Shift That Changed Everything

After this experiment, I stopped asking:

“Is this project impressive?”

And started asking:

“Would I use this twice?”

Because if the answer is no, it’s not a project.

It’s practice.

And practice is fine.

But don’t confuse it with progress.

Final Thought

There’s a reason these ideas go viral.

They’re good.

But they’re not finished.

Your job isn’t to copy them.

It’s to complete them.

“Amateurs build features. Professionals remove friction.”

If you take one thing from this article, let it be this:

Don’t chase complex projects.

Chase useful ones.

That’s where everything changes.

• Real World Machine Learning Projects - Ebook
• Master Python Fast: The Only Cheat Sheet You'll Ever Need
• Python Starter Guide for Non Programmers

I Copied 5 Viral Python Ideas — Here’s What Happened Next was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

I used to think getting better at Python meant learning more, more libraries, more frameworks, more syntax tricks.

Turns out, I was wrong.

The biggest jump in my coding ability didn’t come from learning something new. It came from changing a few small habits I repeated every single day. No fancy tools. No 10-hour tutorials. Just subtle shifts that quietly rewired how I think about code.

After 4+ years of writing Python almost daily, these are the five habits that actually made the difference, the kind that most developers ignore because they look too simple to matter.

Real World Machine Learning Projects - Ebook

1. I Stopped Writing Code First

For a long time, my workflow looked like this:

Open editor → start coding → get stuck → Google → repeat.

It felt productive. It wasn’t.

The real change happened when I forced myself to pause before writing a single line and answer one question:

What problem am I actually solving?

Not “what feature am I building,” but the real problem underneath.

For example, instead of jumping into building an automation script, I started defining the input and output clearly:

input_data = "raw messy data"
expected_output = "clean structured data"

That tiny step saved hours of debugging later.

Pro tip: “If you can’t explain the problem in one sentence, you’re not ready to code it.”

This habit alone made my code simpler, and ironically, faster to write.

2. I Automated the Boring Parts Aggressively

Most developers automate big things. I started automating the small, annoying ones.

Renaming files. Cleaning datasets. Formatting reports. Converting formats.

Individually, these tasks take minutes. Collectively, they drain hours.

So I built tiny scripts like this:

import os
for file in os.listdir():
    if file.endswith(".txt"):
        os.rename(file, file.replace(" ", "_").lower())

Nothing impressive. But I stopped doing repetitive work manually.

Here’s what most people miss: automation compounds.

Saving 10 minutes a day doesn’t feel like much, until it turns into 60+ hours a year.

And more importantly, it changes how you think. You stop asking, “Can I do this?” and start asking, “Why am I doing this manually?”

3. I Started Treating Scripts Like Products

Early in my journey, my scripts were disposable. One-time use. Messy. Functional.

Now, even my smallest scripts follow structure.

I write them like someone else will use them, even if they won’t.

That means:

• Clear function names
• Basic error handling
• Minimal but useful comments

For example:

def clean_data(data: list) -> list:
    """Removes empty values and trims whitespace."""
    return [item.strip() for item in data if item]

This habit sounds trivial. It’s not.

Because one day, you revisit your own code, and realize you don’t understand it.

That’s when you either refactor… or regret.

Quote: “Code is read more often than it is written.”

Writing cleaner code didn’t just help others. It helped future me, who is usually confused and slightly annoyed.

4. I Reduced My Dependency on Tutorials

There was a phase where I couldn’t build anything without watching someone else do it first.

That’s dangerous.

Tutorials create an illusion of competence. You feel productive, but you’re just following instructions.

So I made a rule:

Try first. Fail first. Then learn.

Even if I had no idea what I was doing, I would attempt the solution.

Then, and only then, I’d look things up.

The difference was massive.

Instead of copying code, I started understanding patterns.

For example, instead of searching:

“How to build a file sorter in Python”

I’d search:

“How to loop through files Python”

Smaller questions. Better learning.

This approach forced me to think like a problem-solver, not a code copier.

5. I Built Micro-Projects Instead of Big Ones

Big projects sound impressive. They also rarely get finished.

I shifted to something simpler: micro-projects with a clear outcome.

Not “build an AI system.”

But:

• “Summarize a text file automatically”
• “Organize my downloads folder”
• “Extract key points from articles”

Each project had one job. And I gave myself a deadline, usually a weekend.

Here’s a simple example of a text summarizer approach:

def summarize(text):
    sentences = text.split(".")
    return ".".join(sentences[:3])

Not perfect. But it works.

And that’s the point.

Because small projects:

• Ship faster
• Teach faster
• Build confidence faster

Over time, they stack into something bigger than any single “big project.”

What Changed After These Habits

Nothing dramatic happened overnight.

But over a few months:

• I started solving problems faster
• My code became easier to maintain
• I relied less on external help
• I built more projects than ever before

Most importantly, I stopped feeling stuck.

Because the real bottleneck in programming isn’t syntax.

It’s thinking.

Final Thought

Most developers are looking for the next big breakthrough.

A new framework. A new tool. A new course.

But progress usually comes from something less exciting:

Doing small things better, consistently.

If I had to summarize everything into one line, it would be this:

“Good Python developers write code. Great ones design how they’ll write it before they start.”

Start small. Automate aggressively. Think clearly.

The results won’t be instant, but they’ll be permanent.

• Python Starter Guide for Non Programmers
• Master Python Fast: The Only Cheat Sheet You'll Ever Need
• Real World Machine Learning Projects - Ebook

How 5 Small Python Habits Completely Changed the Way I Code was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.