The Best Way to Learn Python Is to Build Something You'd Actually Use

Tutorials didn’t teach me Python. Not really. The basics would stick for a week — enough to build a to-do app nobody asked for — and then fade because there was no reason to reach for them again. The knowledge had nowhere to go.

What actually worked was building something real. Something with a purpose beyond “learn Python.” That distinction matters more than most people realize.

The tutorial trap

There’s nothing wrong with tutorials. They teach syntax, introduce concepts, give you a mental model of how a language works. But they have a blind spot: they only show you problems that have already been solved.

A tutorial walks you through a clean path from A to B. Real projects don’t have a clean path. Real projects have a moment at 11pm where you realize your entire architecture doesn’t support the thing you need it to do next, and you have to decide whether to hack around it or rewrite. No tutorial prepares you for that decision — and that decision is where most of the actual learning happens.

Not a programming background

My study was Business Management. The most technical thing on my resume before my first job was nested Excel formulas, which felt pretty advanced at the time. First data tools: Alteryx, Tableau, SQL — visual tools where you could see what was happening to your data at every step.

Moving to Python meant gaining flexibility but losing that visibility. You’d write a chain of transformations and have no idea what your data looked like until the whole thing ran. Coming from Alteryx, that felt like flying blind.

That frustration eventually turned into a question: how hard would it be to build something that gave you the visual clarity of Alteryx but let you stay in Python?

The answer: much harder than expected. But that’s also where the learning started.

What building teaches you that tutorials don’t

When Flowfile started, my assumption was that a few years of professional Python experience was enough. Writing functions, working with libraries, structuring a project — all fine. What was missing was everything that sits between “can write code” and “can build something.”

Here’s what that looks like in practice.

Architecture lessons come from things breaking. The first version was one big Python application. It worked fine until it didn’t — Polars was eating all my RAM just rendering preview data. The fix was splitting the backend into two services: one for orchestration, one for heavy computation. No tutorial covers this, because no tutorial gives you a project complex enough to need it.

Tradeoffs only make sense when you have to choose. At some point the project needed a frontend. Staying pure Python with something like Streamlit would’ve been faster to build, but it wouldn’t give the interactive experience the tool needed. So Vue it was. That decision added months and taught more about software development than any Python course.

The project tells you what to learn next. This one’s underrated. Building something specific gives you a sense for which rabbit holes are worth going down. Mastering every Python design pattern? Not necessary. Understanding how FastAPI handles async requests and how Pydantic validates data models? Essential. The project decides the curriculum — you never have to guess.

Reading source code beats watching tutorials. When you’re stuck on a real problem, the answer is usually in the source code of libraries you admire. That habit — reading real code written by experienced developers — teaches more about Python conventions, project structure, and clean architecture than any course material. It’s a masterclass that nobody charges for.

I liked this approach enough that I wrote one — a multi-week walkthrough of pyfloe, a ~6,000-line Python dataframe engine that teaches the architecture behind Polars and Spark in a codebase small enough to actually finish reading.

The one-month project that took a year

The deadline was one month. Build an Alteryx alternative. Very reasonable.

Eleven months later, there was a working tool. And the timeline isn’t embarrassing, because every extra month existed for the same reason: something new came up that changed the plan.

Month two: Python alone couldn’t deliver a smooth UI, so Vue entered the picture. Month four: Polars needed to run in a separate process to stop crashing the laptop. Month seven: saving flows as YAML instead of binary made version control possible.

Each of those was a lesson that only shows up when you’re building at that scale. You don’t learn about service architecture from a tutorial about service architecture. You learn it when your single-service application starts falling over and you need to fix it by Friday.

Still bad at plenty

This part matters because “build something” advice can get romanticized. A project doesn’t make you an expert in everything. It makes you an expert in the things your project needed.

My CSS is functional at best. My understanding of JavaScript build tools is held together with duct tape and optimism. There are Python patterns that never came up because the project never asked for them. And that’s fine — the gaps are visible now, and they’re findable when the time comes.

The project gave me a map of my own knowledge. Not filled in, but at least the borders are drawn.

The actual advice

If you want to learn Python — or any language — find a problem you already care about. Not a textbook problem. A real one. Something from work, something that annoys you daily, or something you’re just curious enough to chase.

It doesn’t have to be ambitious. The first goal for Flowfile was literally “show an Excel file on screen.” That’s it. Everything else grew from there.

The project will teach you what you need to learn, in the order you need to learn it. You’ll hit walls, and the walls will tell you what to study next. That feedback loop — build, break, learn, rebuild — is worth more than any structured curriculum, because the motivation is built in. You’re not learning Python to learn Python. You’re learning Python because your thing doesn’t work yet, and you want it to.

That’s a much better reason to stay up until 2am reading documentation.

One more thing

The project that started all this is called Flowfile — an open-source visual ETL tool built on Polars. But this post isn’t really about Flowfile. It’s about the fact that building it taught more than the previous three years of writing Python professionally.

If you’re thinking about starting something similar: do it. Set a deadline you know you’ll miss. Build the version that barely works. Then make it work better. The learning lives in the gap between “barely works” and “actually works.”

And if a year from now you’re still working on your one-month project — you’re doing it right.