By Toria · Published May 6, 2025
Data Explorer · Systems Thinker · Writer in Progress

Photo by Jessica Lewis 🦋 thepaintedsquare: from Pexels

The Setup

One of the main languages you’re expected to know as a Data Engineer is Python. I’d dabbled with it during a uni course, but I’d never truly used it — not in a real, hands-on, break-it-and-fix-it kind of way.

So when a piece of work came up involving Python and the Faker library to build test data and personas, I thought:

Great — here’s my chance.

More Than Just Code

Python isn’t SQL. If we’re going for technical terms, it’s an imperative language, not a declarative one. But it wasn’t just the syntax that threw me — it was the idea of libraries.

At first, I just followed my boss’s code: from faker Import Faker, etc.

Simple enough… until I got an error.

No module named 'Faker'.

I thought I understood what libraries were: reusable blocks of code — like tools someone else made to save time. But this error made it clear: There’s a difference between knowing of something, and really understanding how it works.

The Plug That Didn’t Fit

What was the issue?

I had the right code… but the environment didn’t know what to do with it.
It’s like buying a hand mixer from Amazon, only to find out it comes with an American plug. I’m in the UK. Of course it doesn’t fit.

The code was technically correct — but it wasn’t compatible with the environment I was working in. So I needed an adapter.

Once I installed the right packages and set up the environment properly, it worked. And that little win meant more than I expected. Because in my world, understanding why something works is just as important as getting it to work.

Photo by Bob Jenkin from Pexels

Slowing Down to Go Deeper

The next step was amending a partially written, Stack Overflow–copied, AI-generated script to fit my own data model. I knew it outputted a CSV — but I didn’t know why it worked, or which parts I could safely change.

So I slowed down.

I read the code line by line, function by function, trying to follow how it all connected — until I realised I had to work backwards. Python is modular, but it still follows a sequence.

The closest comparison I can make is setting up a board game. You can’t just roll the dice. First, you place the board. Then the pieces. Then the cards. It’s the setup that gives structure to what happens next.

Real Growth from Fake Data

What started as a quick task to generate some fake data ended up taking me through a deeper understanding of Python itself.

I began recognising how functions passed data, how the environment played a role in setup, and how modular thinking can make code both flexible and complex.

Instead of rushing to finish the task, I let myself sit in the discomfort of not knowing — and then worked my way through it.

That shift in mindset — from "get it done" to "truly understand it" — became a turning point.

Because confidence doesn’t always come from knowing upfront. It often comes from figuring it out anyway.

And that’s what I love about this work — the small bugs that lead to big understanding. Even fake data can teach you something real.

Written by Toria

Data Constellations — For layered thinkers, quiet disruptors, and curious minds.
Keep exploring the patterns others don’t always see.

Retrace your steps ←