Who Am I? (And How the Bricks Came First)

No, really, who the heck is this guy?

This article is a bit special for me. It's my way of opening the curtain and letting you peek at the person behind the posts. By the end, you'll have a better sense of where I come from and what shaped me.

I'm not here to convince you to read it, but if you'd like to build a bit of an emotional connection and let me earn some credibility in your eyes, then stick around.

Anyway, where do we start… 1 million years ago? No? Okay, let's pick a more realistic point.

Born and raised in a lovely Ukrainian family, I spent much of my early life building things, quite literally. LEGO bricks were my world long before Databricks entered the picture.

Over those years, I developed a quiet diligence: I could sit for hours, focused, piecing together LEGO sets, puzzles, or bead patterns, long after other kids would give up in frustration. Looking back, it feels like the early training ground for the patience and persistence I'd later need in engineering.

Huge credit to my parents, who kept fueling that spark, always bringing me new sets, keeping my little creative fire alive.

At one point, I even told people I'd grow up to be a construction worker. Not as flashy as "astronaut", maybe, but I guess I still ended up building things… just with a slightly different set of bricks.

Around the same time, our family got a computer for my older brother. To me, it was a magic box, mostly because it let me play strategy games for hours. My top picks?

• Command & Conquer: Generals
• Command & Conquer: Red Alert 3
• The Lord of the Rings: The Battle for Middle-earth II
• StarCraft II

Pure blessing.

I was a 21st-century kid growing up in the middle of the personal computer and internet boom.

Time passed, and I did pretty well in school, especially in math and physics.

In late mid-school, informatics classes came along. At first, it was just general "computer stuff", but then programming entered the scene, and that's when things got interesting.

My first programming language? It was Object Pascal, with Lazarus as the visual IDE.

It wasn't exactly the friendliest starting point: most of my classmates could barely finish the homework. But I managed to get the hang of it, complete the assignments, and even help others.

Around this time, I also took full ownership of a school programming contest called "Space. Man. Spirituality." Nobody else wanted to participate, but the idea of building my own game was too exciting to pass up. With zero game-dev experience, I taught myself how to use the Construct engine, poured most of my free time into the project, and submitted a playable educational game about our solar system.

The result? I won at the regional stage simply because I was the only one who actually built a game. Sometimes, taking on what no one else wants to do is the easiest way to stand out.

I returned the next year with an even more ambitious project: a Mario-style space adventure combined with my first game's planet-exploration feature. It was harder, messier, and came with a classic "coding till 4 AM before the deadline" moment, but it paid off with a win at the higher-level stage.

Those projects subconsciously taught me early on: when you take ownership, you might fail, but you might also create something nobody else can.

As a result, I expressed my wish to study a programming-related major, and my parents fully supported me.

I applied to WIT Academy in the beautiful capital of Poland, Warsaw, and ended up moving exactly 918 kilometers and 325 meters from my parents' house to a dorm.

(Yes, it's the shortest path, and no, I'm not telling you how I measured it. Some habits die hard)

I arrived with mediocre language skills, no family or relatives nearby, and zero experience cooking even a basic porridge.

(Spoiler alert: over time, I fell in love with cooking and baking)

It was a totally foreign environment for me.

"What doesn't kill you makes you stronger", that's how I'd sum up this period. I could write about it longer than a Spark job stuck in shuffle hell, but that's not why you came here.

One thing worth mentioning: my approach to studies.

At the start, that blank-slate environment left me with one clear option — study. My university also had a scholarship ladder: the better your grades, the bigger your "student salary".

My grades quickly placed me on that podium, and I realized:

"I'm getting paid to learn, while my peers are spending this time working side jobs… why not double down?"

So I did.

Fun fact: I got so focused on learning and grades that I ranked #1 by GPA in my final academic year.

Anyway, bragging over, moving on.

Over those years, I built a solid foundation in programming, math, algorithms, and other tough as hell promising curriculum topics I don't directly use in my day-to-day job, but still value deeply.

I tried almost everything under the sun: C, C++, C#, Java, JavaScript, Python, SQL, even a dash of Assembler, but Python stuck with me and carved out a special place in my heart.

Python was the only language I started learning on my own before related classes began. It started with a 3-day webinar where I built a simple desktop messenger app.

Motivated to keep going, I decided to turn that into my first pet project.

Tip: Pet projects are the way to go for learning. Especially if you're a student, seriously, why are you still reading this? Go build something for yourself!

I worked on it for about 5 months, and in that time I learned how to:

• Architect an entire app from scratch.
• Organize code cleanly.
• Nail the Python basics.
• Write tests.
• Prepare a readable README and proper documentation.
• Even use Markdown effectively.

It felt like a small-scale simulation of a real-world project.

I learned by doing, hitting problems head-on, and puzzling them out.

OMG, I still remember spending a whole day chasing a UI button bug. The cause? I hadn't defined an argument for a lambda, so it kept using the outer scope variable. When I finally figured it out and fixed it… pure superhuman feeling.

After that, I built a few more pet projects during my university years, all living on my GitHub.

Then came 3 intense months of job hunting… and I finally landed my first role: Python Intern at Addepto.

During my first three years in the industry, I worked across a wide spectrum of projects: NLP-powered chatbots, desktop applications, full-stack web apps, analytical platforms, and LLM-powered chatbots.

Funny thing: on my very first project I built a custom NLP chatbot long before LLMs became trendy and took over everyone's feed.

Anyway, the point is, I tried different stacks and roles, and looking back, I felt a bit stuck on where to go next.

You see…

I remember checking an example Python Software Engineer roadmap and thinking:

"Is this it? Django, Django, Django, FastAPI, Django…"

I already knew most of it, and the only way forward seemed to be accumulating more of the same experience.

I was missing a spark, a direction that felt like growth.

I wanted more ownership. Not just features, but systems.

I started considering a shift.

You might say, "What about Data Science?"

For me, it was out of the question. I wanted to spend most of my time coding and building systems, not training models or diving deep into statistical beauty. And I'd already collaborated with talented Data Scientists at Addepto on AI-backed projects, which helped me see that it wasn't something I'd enjoy doing daily.

On the other side, I kept bumping into colleagues working on Data Engineering projects and found myself wondering: "What the heck are they doing there? Are they plumbers dealing with broken pipelines?"

As I explored further, Data Engineering felt like a sweet spot. It combined the coding, system design, and automation mindset I loved from Software Engineering with the mission of making data reliable, discoverable, and actually usable by others.

One brutal truth stood in the way: I was terrified of working with data.

No, really. It all felt so fragile, like one wrong move could mess up storage or downstream consumers.

You know what people do when they're afraid of something? Avoid it?

True.

You know what I did? Avoided it?

No, no, no — embraced it!

I still had uncertainty (Is this the right choice? Can I really make it?), but I'm grateful that fear didn't stop me.

So what do we have in our equation?

A black box that sparked curiosity, uncertainty about the unknown, and (the final missing piece) my willingness to dig in.

That's where my first steps into Data Engineering began.

At the beginning, I did my homework: scraped the internet for a bunch of DE roadmaps and content → stitched it together to pinpoint my weak areas that I needed to focus on.

By the end of my research, I had a rough idea of what to learn, but I still wanted to validate it. So I reached out to my colleague and shared my findings.

We had a great discussion where he helped me structure a practical and efficient learning plan. One line he said really stuck with me; I even wrote it down to keep in mind:

Vadim, I'd prefer if after work you spent time on things that bring you joy, rather than stuffing your head with pure theory that you'll rarely use.

One of his key suggestions was to avoid diving deep into theory, books or lengthy courses at the beginning. Instead, he recommended starting with a high-level overview of tools and technologies, exploring trends on platforms like Medium and Reddit, and subscribing to relevant Substack newsletters.

It was all about understanding the field broadly, building knowledge channels to become a good consultant, so that I don't shuffle tasks blindly, but join the discussion and have an impact.

Once the learning plan was set, I began executing it:

• Broadened my knowledge by creating a high-level overview of Data Warehouses, Extraction, and Orchestration tools.
• Completed a few Databricks courses to solidify my understanding of cloud-based data platforms.
• Experimented with technologies like Airflow and Benthos (now known as Redpanda Connect), just exploring and playing around.

It was all about exploring tools and getting broad hands-on experience.

(By the way, I also wrote another article about this growth phase for the Addepto blog. If you'd like a more structured perspective on this journey, check it out here)

Did I accomplish that goal of doing things that bring me joy?

Yeah… not really.

Reality check: life isn't always shiny and bright, but it's more about how you face it.

Wait, but do I regret it?

Hell no.

I had to show up regularly outside my normal work hours and keep pushing. I made my choice, and that choice made me.

Time passed by. After weeks and months of self-learning, I eventually got my chance to dive into a real Data Engineering project.

The mission? Building an event mesh data platform for multiple modes of transportation, with Databricks at its core. (Yeah, the "bricks" finally entered the game)

Reality caught up quickly, highlighting the inevitable gap between self-study and real-world work. I started at the very inception of the project. In fact, I literally kicked off the entire development; prior to that, it was mostly just a concept with lots of unknowns waiting to be clarified along the way.

It took some effort to switch my brain fully to data-oriented thinking and actually apply everything I'd learned. Like every developer, I faced the usual path of trials, errors, and plenty of head-scratching. Still, with guidance from more experienced colleagues, I steadily worked my way through these early challenges.

Initially, I worked closely with my colleague. Having him around was great. I could validate my ideas quickly and confidently take ownership of technical decisions. Gradually, though, as the platform matured, I started relying on him less and less, eventually taking full technical ownership in our small team.

One of my favorite periods was at the very start, during the two-month Proof-of-Concept phase. I enjoyed collaborating closely with a key stakeholder from our client's side. It felt motivating, exciting, and genuinely rewarding. Transforming raw ideas into tangible results was energizing.

Time passed by again. The platform matured, and so did my skills. I solidified my position as a Data Engineer, prepared thoroughly, and successfully passed the Databricks DE Associate certification. It was incredibly rewarding to study something for the exam and immediately apply it on a real-world project. Talk about instant gratification! And of course, countless other experiences happened behind the scenes.

Gradually, colleague's involvement decreased further until he eventually stepped away completely. At that point, I officially took over full technical ownership for our four-person team.

You're never fully ready: embrace ownership early.

I know, I know. "It depends", you might say. Or maybe you'll argue, "I don't have such opportunities on my project", or "", and you'd probably be right.

But look, everything starts with how you see things, right? If you assume it's going to be bad, no surprise, it probably will. But if you take that small leap of faith and step up earlier than you're fully comfortable, good things can happen. You'll feel more fulfilled at work, gain credibility in your team's eyes, or maybe even get that raise you deserve.

Of course, there's a risk of failure. But hey, do I really need to remind you how overrated safety is? The internet's already full of motivational clichés, so I'll spare you.

My point is: start small. No dramatic leaps required. Don't overhaul your entire architecture with shiny new tech overnight just because someone told you to "take ownership".

Instead, pick something simple but meaningful. For me, it started with proactively setting up project risk documentation and alerting mechanisms before things broke. It evolved into defining data-quality standards and leading CI/CD initiatives. It didn't always feel easy, but it shaped me into a better engineer quicker than I'd imagined.

If you're still here, thanks for sticking around! Reflecting and writing this intro has been genuinely fun for me, but now let's shift our focus forward.

In this blog, I'll be documenting what I learn from my day-to-day work building real Databricks systems: working blueprints, architecture decisions, and the practical details that tutorials leave out.

The purpose here is simple: share what I know, make daily engineering a bit easier, and connect with like-minded people. I'll document my learning journey openly, invite real conversation, and turn experience into practical value.

Welcome to my little island on the internet!