At the start of 2026 I was sure I would keep writing my own code. One month later, I was not writing a single line.

It went step by step. First AI gave me suggestions, then it wrote the syntax, then it reviewed my code, then I gave it some functions. Then everything.

Now AI does the whole coding part. And I have one question the whole year:

how do I keep this under control?

Because there is no return back. And I can tell you, it comes with a cost.

So this is my experience so far. Or maybe I am writing it for my future self, as a checkpoint.

Let’s go!

I stopped reading the docs

Before AI, I read the docs every day. A new feature comes out on a platform, I google it, I read it, I learn it.

I check the syntax of a function. I read the discussions on Stack Overflow.

The good side: Why bother now? AI explains it instantly and does the research for me. I ask, I get the answer, I save the time.

The bad side: Reading docs sounds like the boring part of the job. But it is one of the main reasons I became an expert.

While researching one thing, I found ten other features by accident. That is how I built my overview of the platforms I work with.

Now I get the answer to my question, and nothing else.

I feel I lost something. I lost the overview.

Faster than me in everything

We cannot argue here. AI is fast, super fast.

It writes the syntax, the setup code every project needs, and it does the search I used to do. It builds three apps while I make my coffee. It debugs a whole pipeline in seconds, finds the root cause, and suggests three solutions with a recommendation.

It is faster than me in everything.

The good side: I have more time for architecture thinking. And I can test new ideas in no time, things I never dreamed of having time for.

AI does the boring tasks too: the tests, the metadata, the documentation, and removing the code nobody uses. And the ideas don’t wait in the backlog anymore, so I do more projects.

The bad side: You feel faster with AI. But feeling faster and being faster are two different things. You see it in every project after the first week.

Since when is speed the most important thing in a project? We never measured the best expert by lines of code per hour.

Maybe management does, but speed by itself has no value.

And yes, as long as I am in the loop, I slow the AI down somewhere. That is fine. That is exactly the part that keeps the result right.

It is all about accuracy.

The start is always perfect

Every AI project I start looks amazing in the first week. A few rounds of changes later, it explodes.

And I noticed, it is always the same story.

• The start is easy: Empty project, clear task, nothing to break. The AI knows everything, because there is nothing to know yet.

• Then the changes start: You ask for a feature, it does a quick fix. You report a bug, it does another quick fix on top of the first one. It never goes back and cleans up.

• Then it forgets: The project grows, and the AI knows less and less of it. It fixes the file in front of it and breaks the one next to it.

• And you stop reading the code: The start was so good that you trust it. Around the third round you stop looking. The break happens exactly there.

The first 70 percent takes an afternoon. The last 30 percent takes longer than everything before, and often it never arrives.

It looks finished. It runs. And a few weeks later nobody can fix it, not me and not the AI.

Who does what? The dilemma

One question haunted me the most: who writes, and who reviews?

There are a few options, and I tried them all.

• AI codes, I review: Impossible. I cannot review thousands of lines of code a day, nobody can. And if I do it, what did we win? AI is fast, I am the bottleneck again, and the speed is gone.

• I code, AI reviews: I feel like I am blocking the full potential of AI. Everything is slow, when I know AI could write it in seconds.

• AI codes, AI reviews: This is what people call vibe coding. Good luck with that. AI builds beautiful garbage at incredible speed. Give it a few weeks, and you throw the whole project in the garbage.

• AI codes, AI reviews, I review: This one I did for months, and it worked.

Until I lost the trust.

The review said all good. It was not.

More than once, I caught the AI doing things it never reported.

And when a test failed, it did not fix the code. It fixed the test.

So today I added one step, at the very beginning.

I write the rules. AI codes. AI reviews. And I review.

Let me explain it like this.

How I work with AI now

I am the expert. AI is a super fast developer with a lot of knowledge, and it lies.

How do I deal with such a developer? I cannot fire it, because then I do all the work myself again.

So I manage it. And managing developers is nothing new for me. Three things did not change.

We never reviewed every single line. Even before AI, we reviewed the core parts, the ones we knew were important, and we made sure they were protected.

We always shipped code we did not write. Every library, every package, every dependency in the project. We never read those line by line. We tested, we checked what matters, and we stayed responsible for what we merged.

We always wrote the rules. Standards and guidelines for the team, and everyone had to follow them.

Same thing for AI. So it looks like this:

1. I write the rules and the standards in files, like before. Including how big one change can be, because I cannot review a change of two thousand lines, and I will not. The AI is not allowed to change those files. Only me. It can read them as much as it needs.

2. I give it a memory. Every mistake it makes goes into the files it reads before it writes code, CLAUDE.md or AGENTS.md, and corrections.yaml. And when the same mistake comes twice, it becomes a rule, so it does not come back a third time. One rule is already there: it is not allowed to change a failing test. It fixes the code.

3. Following my rules and reading its memory, it writes the code.

4. It reviews its own work and reports it to me.

5. I review the review. And I review on my own, with zero trust, the things that matter: security leaks, the core transformations, the core functions, anything that deletes data or costs money, and the architecture.

The AI writes it. I sign it. If it breaks in production, that is on me, not on the tool.

I stop being the person who writes every line. I become the person who owns the context and proves the result is right.

What it still costs me

Even with the rules, the memory and the review, the lost overview stays. And three more things don’t go away.

• It is addictive: Once AI writes one transformation, you want it to write all of them.

• The risk of losing the skill: If I never code myself, the skill goes over time.

• I work more, not less: I thought AI would automate a lot of my work. But I found myself working more, because guiding the AI is real work, all day.

No setup fixes these.

AI does things I never asked for

You tell AI to change one thing. You expect one file to change.

It changes that file and creates three new ones. And this is only the start.

After reviewing AI work, I found it many times doing things that were never in the plan.

• It copies instead of reusing: I already have a function for that in the project. It writes a new one.

• It creates extra things: New files, new configs, new folders. Nobody asked for them.

• It changes files silently: It adjusts things that were never in the plan, and it does not tell you.

• It hides errors: Instead of fixing the bug, it makes the code stop failing. The bug is still there.

• It says done when it is not: It marks the task as finished. And when I ask, it defends the result.

Every task leaves some junk behind. Junk is easy to add and hard to remove. Once it is in, you are scared to delete it, because nobody knows what depends on it.

After a few weeks, you have a brand new project, and it already feels like legacy code.

This is how the project explodes.

AI codes, but it is not an engineer

AI does the job you tell it to do. Even when it does more, it is more of the task, never more for the project.

A real engineer sees the whole project. While working on a task, they notice what is wrong around it, even if it has nothing to do with the task.

And they don’t ask. They come with an opinion: this part will break in two months, these two pipelines should be one, here is how I would do it.

AI never does that. It never comes to you with an opinion on its own.

• It never consolidates: The same logic ends up in three places. An engineer sees it and brings it together into one. AI never does that on its own. Ask it, and it does it very well, but it will never suggest it.

• It never protects the project: Whether the project explodes next month is not part of its task. It closes the task.

• It never brings new ideas on its own: Nothing out of the box, no innovation. It cannot think like a senior yet.

You can push it so much. You can write it in the rules. Your AI agent will still just do the job, and never care about your project.

The project is not its problem. So it has to be yours.

AI cannot beat the expert yet

Now you might ask: it is faster than me in everything, so when does it beat me?

Here is the thing. AI learned coding from public projects and public data. But the real projects are never public.

No bank uploads its warehouse to GitHub. No car maker publishes its pipelines. What is public is mostly tutorials, demos and toy projects.

The expert learned the opposite way. I worked on more than ten industry projects. I built five warehouses and two lakehouses. Real requirements, real complexity, real people with different opinions.

AI never saw one real project from the inside. So when your project gets real, its suggestions stay at the tutorial level.

And I don’t see this gap closing soon, because two things would have to change.

Companies would have to let AI deep inside the real business. Most don’t, and won’t for years.

And the experts would have to write down what is in their heads: the decisions, the reasons, the lessons. Almost nobody does that.

It cannot learn what nobody ever wrote down.

Everyone sends me their AI code

That was my own code. But there is a second problem.

I used to review the work of a whole team. And many of my colleagues leading projects today spend their days reviewing pull requests.

They have the same issue. Many developers generate work in seconds and send it for review: code changes, dashboards, scripts. Most of it was never read by the person who sent it.

The juniors do it the most. And I understand them, the button is right there.

Someone sends a code change of thousands of lines for a small feature. Or a dashboard built in one afternoon, and when it breaks, nobody knows what is inside.

The senior became the bottleneck of the whole team, not only of their own project.

And the answer is not to review faster. Nobody can.

The answer is the same rule I give the AI: a change I cannot review goes back to the person who sent it.

And one question decides it: explain your change to me. If they cannot, it does not get merged.

Maybe your company does not allow it yet

Everything I wrote here, I can do because nobody blocks me. I have full access, and the AI can work on the whole project.

Many of you don’t. In banks, in insurance, in big corporations, AI agents are still blocked. Security, legal and procurement all have to say yes.

I know that world. A new tool needs a year to get approved.

Autocomplete, yes. An agent that reads your whole project and runs commands, no.

So if you read this and think, nice for you, my company blocks all of it, I understand. But it is coming to you too, in a year, maybe two.

Use that time. Build the habit at home, on your own projects, with your own rules. But never paste company code into your private AI account.

When it arrives at work, you are the one who knows how to keep it under control.

The rehab

And me? Of all the costs, one worries me the most: the risk of losing the coding skill.

Because I see how it starts. I open a file to write something myself, and my brain pushes back: why bother? The AI writes it in seconds.

Today I still win that argument. I can write my code.

But this is exactly how a skill dies. Not in one day. A little bit, every time you press the button instead of typing.

So what is the solution? Some people quit AI completely. Cold turkey.

I don’t believe in that. And you know it already: there is no return back.

My solution is smaller, and it works like magic. One full day of work, without AI.

Not one chat, not one prompt. Like the old days.

On this day, I code small things with my own hands. I walk through the project and read functions the AI wrote.

I run some tests myself, and I chase a few issues on my own. And when a question comes up, I google it and read with my own eyes.

One day is not much. But it keeps the muscle alive, and it wins me the argument with my brain.

One full day, no AI. It works like magic.

The junior trap

So far I talked about people who already have the job. But what about juniors and beginners?

Reading this, you might think: why should I learn to code, if the experts let AI do it? And every post out there says you don’t need coding anymore.

This is the trap.

The hiring problem

Companies don’t hire a data engineer who can only prompt AI to write Python.

They hire engineers who can write Python themselves, and use AI to speed up their work.

So if you skip the coding, you don’t get hired.

Gut feeling and judgment

I can let go of the coding because I did it for 17 years. If you are still learning, you cannot. Not yet.

If you jump to AI on day one and only copy, paste and run what it writes, you understand nothing.

You learn this job by getting it wrong a hundred times. If AI does the work for you, how do you ever build the gut feeling for what is wrong?

And later, how do you explain your own project, or understand why it is failing?

I am not saying ignore AI. The one who ignores it cannot write one single good prompt, and risks looking outdated.

So while you are learning:

• Struggle first: Turn to AI only when you have no ideas left.

• Let AI explain, not solve: Ask it to explain a concept, never to solve the task for you.

• Learn the fundamentals: You still need SQL and Python, so you can tell when AI is wrong.

You code. You struggle. And AI reviews.

So …

So yes, I gave up the coding, and there is no return back. The costs are real, but I got more time for more projects and innovations.

And the question of the year, how do I keep it under control? Rules it cannot touch, a memory of its mistakes, and I review what matters.

My recommendation: use AI every day. And keep your one day without it.

Don’t take yourself out of the project. Review what is important. Your rules and your tests cover the rest.

And if you are still learning, do the hard part yourself first. AI comes after.

Thanks for reading

Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap
📌 Data Science Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

Everyone is asking the same question right now:

“will AI replace me?”

And I see the fear in every comment on my channel. Everyone is panicking about it. I mean everyone: students, juniors, even experts.

I don’t know why, but I am totally happy that we have AI. So here are my thoughts. Sorry, this one is long, but I wanted to share it all with you.

Once we get past the fear, I am going to post more about AI and coding, and AI and data.

Let’s go :)

The question is wrong

“Will AI replace the data analyst?” I think the whole question is wrong.

The better question is not “will AI replace my title”, it is “what happens to each task I do”.

Because the question looks only at the title. But in real companies we never work under one title.

You might find a data analyst who is more like a process expert, helping the business and giving advice all day. Or an engineer who helps the whole department, because they find the data problems and give amazing advice about the architecture.

To be honest, in many projects I ended up doing both roles.

Titles are never designed perfectly. We all do so many things at companies.

So when someone asks “will AI replace the data analyst”, I’m going to say: first tell me what this analyst really does all day.

Btw Today I published Roadmap for AI Engineers and Forward Deployed Engineers based on 40.000 Job ads, I built machine to analyse the job market :)

The task list test

Here is a test that works for any job. You could be a doctor reading this, it is the same.

Step 1: Make a list of what you really do. Not your job description, the real tasks: going to meetings, talking to people, writing code, answering questions, whatever it is.

Step 2: Give each task one of three marks.

• AI alone: It does it without me.

• AI with me: I’m faster, but I still decide.

• Not AI: It needs me.

Step 3: Count. If every task is “AI alone”, then yes, your job is replaceable.

If it is half, and the rest needs deep understanding of your company or your client, then good news. It will not replace your job.

And look at which half it is. If AI takes the routine end of your job, you become more valuable, because now you have time for the expert end.

If it takes the expert end, that is the bad news.

And the “AI with me” tasks stay yours. You just do them faster.

Now you might say, okay, but how do I know which mark a task gets? Four questions:

• Do I have to talk to people to do it? Colleagues, clients, other teams. If yes, it is “Not AI”.

• Is everything it needs written down? If the knowledge is in people’s heads, AI cannot reach it. So if you want to fight AI, don’t write down your knowledge, keep it in your head 😅

• If it gets it wrong, will I notice? If a wrong result looks exactly like a right one, it is “AI with me” at best, never “AI alone”.

• Does someone have to answer for it? If a person has to put their name under the result, for the client, the auditor or the boss, it stays with a person. AI can write the report. It cannot sign it.

A quick example: my own job

Here is my own job as a data engineer, marked for today:

• AI alone: Nothing yet.

• AI with me: Writing the transformation code, building pipelines, tests and documentation, monitoring.

• Not AI: Talking to the source experts, agreeing on data contracts, consulting the consumers of our data, the architecture, the data modeling, and the big incidents. It is never only fixing code.

If you can only do coding and building pipelines, then yes, a big part of your work gets automated. But the last group is all about people, sources and decisions, and this is where we engineers spend most of our time.

So will AI take your job? It depends. And it depends on you.

What the job ads say

I checked almost 40,000 real job ads. Around 20% of the analyst ads mention AI, and around 25% of the engineer ads.

Still small, but it started.

And what do they ask? Look at the real sentences:

• “Use AI tools to accelerate analysis.”

• “Automate recurring reporting workflows.”

• “Build pipelines for retrieval-augmented generation.”

Nobody is asking you to build AI. They ask you to be faster with it, and to build the data for it.

The new jobs say the same. AI data engineer, AI data analyst: the companies took the data jobs and put AI in front of the name.

Same core: Python, SQL, pipelines, data modeling. On top of it, LLMs, RAG and AI agents.

AI sits on top of your job. It does not replace it. And companies started naming the tools: Claude, Claude Code, Copilot, Cursor.

If they ask analysts to use AI, they are not replacing analysts.

Nobody is going to fire you tomorrow because you don’t use AI. But the companies started writing it in the ads.

But the company needs fewer of us, right?

Now you might say, okay Baraa, if I am twice as fast with AI, then the company needs half of us.

Think about data teams. We are usually small, and we cover only a small part of the company’s data.

So once AI makes us faster, the company has three options:

• Reduce: Fewer people, the same small part of the data. You save cost, and nothing really improves.

• Keep: The same team, now fast, so it covers a larger part of the data.

• Expand: Grow the data team, because every AI project needs the data first.

What I saw is the second and the third. For years the data team was the “nice to have” at companies, with the smallest budget.

Then every AI project came and said: I can do the AI use case for you. But I need half a year just to get the data.

AI did not make us the extra. It made us the core.

Companies move very slowly

And you might still say: but my company is going to replace me with AI tomorrow anyway.

One thing you have to understand: it depends on the size. From what I see, mid-size to big companies are slow to adopt any new technique.

We don’t even need AI to see it:

• The tools: We have the best tools in the world for data. Tableau, Power BI, Databricks, Snowflake, dbt.

• The reality: Companies still use Excel for critical reports. Many don’t even have a clean data warehouse.

A company cannot change overnight and become AI-driven. It takes years: migrations, pipelines, governance, training.

So even though the tools exist, companies need years to really use them. With AI it is going to be the same.

Why companies cut people

But companies are cutting down. Yes, true, but look at why.

It is mostly not because a project turned completely to AI. Many companies are suffering financially right now, and they are going to use whatever reason to cut headcount.

Right now, that reason is AI.

And this is nothing new:

• Before ChatGPT: Layoffs happened before it, and they are going to happen after. Budget cuts, company pivots, bad leadership.

• Sam Altman: Even the CEO of OpenAI agreed that some companies blame AI for layoffs they would do anyway. Some real replacement too, he said, but a lot of it is just blame.

• Klarna: They went very far with AI in customer service. Later their CEO said what you end up having is lower quality, and they started bringing humans back.

Why they are not hiring

Partly it is the same reason as the cuts, money. But here there is something new: companies are speculating.

They think they don’t need new people, because all the new projects can be handled with AI by the experts who are still inside.

• Shopify made it a rule: “teams must demonstrate why they cannot get what they want done using AI.”

• Salesforce: Their CEO said they are not adding any software engineers in 2025, because AI made the teams more than 30% more productive.

About a year and a half later, the same CEO said about AI: “The model still cannot operate autonomously.”

What AI does not know

And here is the problem with that speculation. AI learned from public data, and it never saw the inside of a real company.

• The code: Real data projects live inside companies, never public. Search GitHub for a real lakehouse, and what you find are toys.

• The knowledge: Most of it is not in documents. It is in the minds of people.

From a lakehouse I built in one of those companies, I can tell you this. We spent about three years just connecting ten source systems, more than 1,200 tables, with years of business rules on top.

So AI never saw how a real company works from inside. Data systems hit a level of complexity that you cannot just build with a few prompts.

The real question is not “can AI write SQL”. The real question is: can AI understand the whole company?

What happens when the experts leave

So let’s say the speculation works, and the experts inside carry everything with AI. Then we have a bigger issue, and this is the one that worries me most.

What happens when those experts leave the company?

Do those companies have juniors who practiced alongside them? No.

Nobody became a senior by reading about it. We all started with the small tasks, and we got them wrong again and again.

You learn when data is lying by getting it wrong a hundred times.

Those small tasks are exactly the ones AI does with us today. So if AI does all of this, how does the next engineer build that gut?

And companies look at the same tasks and say: okay, now we hire only seniors. They now expect juniors to be seniors already.

So where are the seniors of tomorrow going to come from?

Why I think companies will come back

Well, I can only speculate here, I don’t know the future. But I think it is only a matter of time until companies go back to hiring juniors.

The Financial Times made a film about this. In it, the CEO of a hiring platform took law firms as his example.

With AI, he said, they can probably do maybe 80% of what the junior lawyers do. And then came the important part:

“The average age in this law firm is 55, and so if you don’t hire people right now, the company will cease to exist in 15 years.”

I think this is the same for every team. Seniors leave, and somebody has to be ready.

They are going to need them.

And it already started. Remember Salesforce, the company that stopped hiring engineers?

In April 2026 the same CEO wrote: “We’re hiring 1,000 new grads & interns right now to ride the AI exponential.”

And the headlines?

So that is what I saw inside companies. Now compare it with social media.

A new headline every day, and most of them want you to panic: “AI is taking over!” “Developers getting replaced!” “Tech layoffs everywhere!”

Most of that is just noise, designed to trigger fear and get clicks. Before I believe one, I run three checks.

Check 1: Who is talking, and what do they sell? Three groups, three stories:

• The sellers say you are fine if you use AI. Jensen Huang of Nvidia: most people will lose their job “to somebody who uses AI”, not to AI itself.

• The buyers say they need fewer people. Andy Jassy of Amazon: “We will need fewer people doing some of the jobs that are being done today.”

• The measurers say it is small so far. Two researchers found no measurable effect on pay or hours in Denmark in the first two years after ChatGPT.

Nvidia sells the chips. Amazon pays the salaries. The researchers sell nothing.

Check 2: Do they give you a date? I saw people saying AI replaces tech jobs in 2026, and I thought: okay, let’s see.

Well, the year is almost over, and we are all still here.

Check 3: Did they ever work inside a real company? Most of those people are either selling AI tools, or they never worked in one.

Inside, things are way more complex, and way slower.

Now to be fair, not everyone who warns is selling something. Geoffrey Hinton won the Turing Award for his work on AI, and he left Google with no product to sell.

He said: “We’re going to see it having the capabilities to replace many, many jobs.”

I take him seriously, and I am not going to tell you he is wrong about the technology. But the technology can be ready, and the company still is not.

Even Sam Altman said it in May 2026: “I’m delighted to be wrong about this. I thought there would have been more impact on entry-level white-collar jobs being eliminated by now than has actually happened.”

Over the years you develop a feeling for what is hype and what is real. Until then, the three checks do the job.

So …

So, will AI replace you? Most headlines say yes.

I say: it depends on you, and your company is slower than you think.

• Your job: Take your list and ask what happens to each task. Do it this week, and again next year, because the marks change. Monitoring, for example, I expect to move to “AI alone”.

• Your company: It is slow, and that gives you time. But don’t sit back, because if you stop learning, AI is going to take your job.

• Your team: Faster does not mean smaller. Every AI project needs the data first, and we are the ones who prepare it.

• Inside a company: Be the one who understands the domain, the business and the data, not the fastest one to write SQL. That knowledge is what AI does not have, and for a company it is gold.

• Not inside yet: Push harder. Build projects, and learn to think like a senior.

• A few years in: AI is going to make you fast, and it can make you forget. Keep doing the hard tasks yourself.

• Already a senior: Understand the whole company, and prove the data is right. That is the human job.

• The headlines: Run the three checks before you panic.

And for everyone: use AI every day. But understand what it gives you, don’t just copy and paste it.

Thanks for reading ❤️

Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap

📌 Data Science Roadmap

📌 Data Analyst Roadmap

📌 AI Engineering Roadmap

Hey friends,

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap
📌 Data Science Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

The data architect is the role I loved most in my whole career, and it’s the one I almost never see explained honestly.

There’s no roadmap for it, no course that makes you one, and most of what’s written about it online is a vendor selling a platform.

That why I went last week talking about it and tomorrow continue where I will show you how to create Data Architecture Live! 🕔 17:00 Berlin

Who Is the Data Architect?

Before a company builds anything big with data, someone has to make the plan.

That someone is the data architect, and the job works exactly like building a house:

• Listen: sit with the business and understand what they really need.

• Draw: turn those needs into a blueprint, on paper, nothing built yet.

• Hand over and stay: give the plan to the engineers and mentor them until it works.

That’s the job on paper. In reality you’ll do several jobs at once: I started at Mercedes-Benz as a solution architect and ended up designing, building, and leading projects at the same time.

The architect doesn’t build the house. But if the wrong house gets built, that’s the architect’s mistake.

Architect or Engineer?

Right now some of you are thinking: I’m a data engineer, I already design my own pipelines, so am I not doing this already?

Careful, because the usual answer (”the engineer builds, the architect decides”) is wrong. Engineers decide all day.

The real line is which decisions:

• The engineer makes a hundred decisions a day inside one pipeline.

• The architect owns the ten decisions a year that the company can’t easily undo: which platform, one copy of the data or many, batch or streaming, build or buy.

And here’s the test I want you to keep, my friend. It’s the cleanest one I know:

If reversing it needs a migration project, it was an architecture decision.

The job ads say the same thing. I put the architect ads and the engineer ads side by side, concept by concept:

Data pipelines is the number one concept in engineer ads at 62%, and in architect ads it falls to place thirteen at 25%. Data architecture runs the other way: 71% for architects, 23% for engineers.

Same data, different job. The architect isn’t a senior engineer with a nicer title.

What the Job Ads Say

I didn’t want to guess what companies expect, so I analyzed 14,600+ real job ads.

Only 364 of them were hiring data architects.

The skills are less exotic than you’d think:

The tasks are where the job really shows its face. Design the architecture is 83%, and then it turns into governance and people:

The experience is the wall. A median of 7 years, and out of all 364 ads, exactly 3 were junior:

To be honest with you: this is not a job you apply for. You grow into it, the same way you grow into being a manager.

Now you might tell me: “3 junior roles, so this is years away for me.”

Well, the title is years away. The thinking isn’t, and the last section of this post is about starting it this week.

The 10 Architects You Don’t Want to Be

I met a lot of architects in my career, and the ones who failed usually failed the same way:

• The tool guy: every discussion is Databricks vs Snowflake, never the actual problem. The company’s real pain never makes it into the room.

• The theory guy: they know every concept and never built one. You can’t plan a house you never helped build.

• The big spender: they plan like the company has endless money. The price reaches the manager, and the plan stops right there.

• The overkiller: they bring complexity because they like complexity. The company asked for a few reports and gets a data mesh.

• The talker: good ideas in every meeting, and not one of them on paper. A plan nobody can see is a plan nobody can follow.

• The diagram factory: 20 pictures, and they keep switching between them. Ask for the plan and you get a folder instead of an answer.

• The big banger: they design alone for weeks and reveal it at the end. That’s the meeting where the architecture dies, because everyone is seeing it for the first time with an audience.

• The baby defender: the design becomes theirs, so they defend it against the evidence. Changing it feels like losing.

• The stubborn one: the whole team struggles with the plan and they don’t move. Being right matters more to them than getting it built.

• The ghost: they present the plan and leave. The architect owns the plan until it’s built, and this one is already gone.

And the one that costs the most: the exception becomes the standard. Let one team skip the rules just this once and by Friday three other teams quote it as precedent.

Change the plan for everyone, or hold it for everyone. There’s no third door.

The Career Ladder

As a data engineer or analyst, you have three doors in front of you:

• Management: team lead, department lead, and up. High ceiling, but you trade the tech for politics and people problems.

• Expert: senior engineer, senior analyst. You keep the tech, but senior is usually the last stop.

• Architect: the third door. You keep the tech, you skip managing people, and the ceiling opens all the way up.

And the architect door has its own three levels:

• Casual: you’re still building, and you also design the thing you build. Some of the best architectures I’ve seen came from an engineer who stepped up. This was me at the start.

• Dedicated: out of the single team. You turn department needs into blueprints, sign off other teams’ designs, and stop two teams building the same thing twice.

• Principal: you turn the company’s data strategy into a target architecture, pick the platform, set the standards everyone reuses, and watch the total cost.

Before I left Mercedes-Benz for content, principal was exactly the role I was targeting.

Vendor Architecture vs Data Architecture

Google “data architecture” and you’ll get pages of diagrams packed with logos.

My friends, that’s not a data architecture. That’s a vendor architecture: a company selling you their tools.

Draw one of those at work and they’ll throw it back at you. You’re not solving the company’s problem, you’re just another guy selling Microsoft products.

A real data architecture answers real questions:

• Where does the data come from, and where does it go?

• What happens inside every box: full load or incremental? Batch or streaming? Which data model?

• Who owns it, who may see it, how long we keep it, and what it costs.

If your diagram only shows logos, it’s an ad, not an architecture.

How I’d Start in a New Company

If I got hired as a data architect tomorrow, this is exactly what I’d do.

Phase one, I change nothing. No tools, no proposals, no criticism, no timelines. I’m here to understand first.

Then I talk to everyone, in this order:

• The business first, IT second: what do they do, and why do they need data?

• The source owners: how is the data born, and who answers when it breaks?

• The engineers: what exists today, what are the pains, how long does a load take?

• The managers: where does the money come from?

Then I draw the current situation. The mess as it is, ugly and honest, on one page, plus the list of pain points.

That’s my first delivery, and it buys everything else, because most companies have never seen their own picture. Be careful here: no finger pointing, just the picture and the “because” behind every pain.

Then quick wins, small fixes that buy trust, and only then the target architecture.

Then I sell it before the meeting. Security alone first, then the loudest skeptic alone, then the sponsor last.

I’ve watched good architectures die in review, not because they were wrong, but because the security officer saw them for the first time with an audience.

Then I stay and mentor the engineers through it, and when reality disagrees, the drawing changes. Mine lived for 5 years and never stopped growing.

You listen first, you draw second, and you stay until it works.

The Questions You Carry

Every box in a good architecture is the answer to one of these questions:

• Where is the data born?

• How fresh does it really need to be? What breaks if it’s a day late?

• Who consumes it, and with what skills?

• How big is it, today and in two years?

• Does it already exist somewhere in the company?

The second one saves the most money. When the business says real time, never argue, just ask what they’d do differently if the number arrives at 9:05 instead of tomorrow at 8.

Silence means batch. A real answer, somebody gets paged, an order reroutes, means streaming, and now you also know what it’s worth.

And watch for requirements with a tool hiding inside them. “The data must be in a Kafka topic” is somebody’s favourite answer wearing a requirement’s clothes.

A requirement tells you what and how well. The moment it names a tool, someone else already did your job, badly.

Start Before the Title

You don’t need the role to start, and this is the part I really want you to take:

• Be the one who draws. In your next project, draw the picture nobody asked for: sources, layers, consumers. If a diagram already exists, draw your own anyway and bring it as a question, not a correction.

• Write down why. One page per decision: the options, your pick, the price, who agreed. The industry calls these decision records, and architect ads ask for them by name.

• Count the arrows. Every arrow between two teams is a promise: an owner on each end, a format, a timing, a bill, and a phone call at 3am when it stops flowing.

• Learn draw.io. Free, runs in the browser, and it’s what I saw companies actually use.

Juniors count boxes. Architects count arrows.

Diagrams show what you built. Decision records prove you can think. In the architect interview, they ask for your decisions, not your drawings.

So …

If you keep only a few lines from this one, keep these:

• If reversing it needs a migration project, it was an architecture decision. That’s the whole job.

• It’s not an entry job: median 7 years, and 3 junior ads out of 364.

• The path is wider, not higher. No authority, three yeses, paid for the mistakes you prevent.

• Half of this job is politely not building things, because every box costs money forever.

A data architect is the person who understands the business first, draws the plan second, and stays until it works.

Next time I’ll take you through the architectures themselves: the warehouse, the lake, the lakehouse, and why companies are now splitting everything into domains.

Hit reply and tell me which one you want first, I read everything.

Thanks for reading ❤️

Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

I’m super happy to invite you to our LIVE on YouTube tomorrow 🎉

Data Architecture

Data Architect is one of my favorite roles I’ve had in my career.

I did this job for years at Mercedes-Benz and other companies. Tomorrow, I’m going to share my experience with you, and we’re going to cover:

• What is Data Architecture?

• The role + the real numbers from 14,600+ job ads

• Technical and soft skills

• The mindset of an architect

• Cloud vs. System vs. Data Architects

• Data Architecture concepts

• My tips on how to become one

📅 Tuesday, August 18
🕔 17:00 Berlin | 20:30 India

Set the reminder here

If you ever wondered how to keep growing in data without becoming a manager, this session is for you.

Set the reminder, grab a coffee, and see you tomorrow 👋

Thanks for reading ❤️

Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

Databricks, Snowflake, and Microsoft Fabric.

Once you enter the data world, you hear these three names everywhere. Job posts. LinkedIn. Meetings. And if you are new, I totally understand that this topic is confusing.

What are these platforms? What is the difference between them? And which one should I learn?

Let’s go.

What is a data platform?

One central place where the whole data work happens:

• Store the data in the cloud

• Clean and transform it with pipelines

• Analyze it with reports, dashboards, and AI

Why companies pay for this? Because the alternative is chaos. Without one platform, every team buys its own tools. One for ETL, one for the database, one for orchestration, one for reporting. And good luck connecting all of that in one project. I have done exactly this more than seven times in different companies, and I can tell you, it was a nightmare. Data silos, repeated projects, shadow IT, and a very expensive way to work with data.

So this is the promise of all three: everyone in one place, one copy of the data, one source of truth.

The origins explain everything

• Snowflake (2012): database engineers from

  Oracle. People who love SQL and clean warehouses. So they rebuilt the data warehouse for the cloud. Simple, managed, SQL-first.

• Databricks (2013): the Berkeley researchers who created Apache Spark. People who love code and big data. A platform built by engineers, for engineers.

• Microsoft Fabric (end of 2023): the youngest one. Microsoft glued Power BI, Data Factory, and Synapse into one bundle, for companies that already live in the Microsoft world.

And nobody here is small. Databricks is around $7 billion a year, growing around 80%. Snowflake is over $5 billion, growing around 30%. Fabric passed $2 billion, growing around 60%. One more detail people miss: Snowflake and Databricks are independent companies. Fabric is not a company. It is a product from Microsoft.

Keep this in your head: Snowflake is the SQL people. Databricks is the engineering people. Fabric is the Microsoft world.

The differences

1. The cloud

Where the platform is allowed to run.

• Databricks: any cloud. Azure, AWS, or Google.

• Snowflake: any cloud too. You pick one when you create the account.

• Fabric: Azure only.

2. The storage

Where your data lives, and whether you can see the files.

• Databricks: real files in your own storage, in the open Delta format, and any tool can read them. On top of the files you still get tables and SQL. That is the lakehouse.

• Snowflake: everything in Snowflake’s storage, in its own closed format. You see tables, never files. The classic warehouse. But they adapted: Iceberg, the other open format, is now supported too.

• Fabric: the whole company in OneLake, like OneDrive but for data. And the files inside are Delta, the exact format Databricks created.

The pattern: everyone starts their own way, then adopts what works from the competitors.

3. The compute

All three split your

work across many machines in the cloud. The real question: who manages those machines?

• Databricks: the Spark engine, two ways to run it. Classic: machines in your own cloud account, you configure the clusters yourself (PaaS). Serverless: Databricks machines, few clicks, fully managed (SaaS). And serverless does not mean no servers. It means not your servers.

• Snowflake: their own SQL engine, built just for SQL. You pick a warehouse in t-shirt sizes and you never see a machine. Fully managed (SaaS).

• Fabric: not one engine, several: Spark, the Synapse SQL engine, and the Power BI engine, all on Microsoft machines. The most SaaS of the three.

4. The bill

How each one charges you

• Databricks: pay as you go. On the

  classic cluster you get two bills, one from Databricks and one from your cloud for the machines. On serverless, one bill for everything.

• Snowflake: pay as you go, same model. You pay while things run. You stop, you stop paying. One bill from Snowflake.

• Fabric: a fixed subscription. You buy one capacity, all teams share it, and the price stays the same whether you use it or not.

My opinion, after living with both models:

• Pay as you go sounds fair, but it opens the door for surprises. A warehouse running the whole day doing nothing. High-end compute on a tiny task.

• And budgeting is the real pain. Estimating the whole year for your managers? Good luck with that.

• The fixed model is way more friendly to plan. One price, no surprises.

5. Streaming

Loading live data as it arrives.

• Databricks: Spark Streaming and Delta Live Tables. The strongest of the three.

• Snowflake: Snowpipe and dynamic tables. A little bit simpler.

• Fabric: built-in event streams and the eventhouse.

6. Orchestration

How you schedule and run your pipelines.

• Databricks: pipelines and jobs, different ways inside the platform. Second place.

• Snowflake: tasks for scheduling. The weakest here, and in practice most teams bring Airflow or dbt from outside anyway.

• Fabric: a standalone tool for it, the famous Data Factory. The winner here.

7. Governance

Who can see what data, and where the data actually goes.

• Databricks: Unity Catalog, the strongest implementation. It is made for this.

• Snowflake: Horizon.

• Fabric: Purview.

8. Machine learning and AI

All three added it, and the personalities show again.

• Databricks: Mosaic AI. Build and train your own models, even AI agents. The strongest, no brainer.

• Snowflake: Cortex. AI directly inside your SQL, you ask your data questions right in the queries.

• Fabric: Copilot. The assistant everywhere in the Microsoft world.

9. Dashboards

How the business sees all of this.

• Databricks: somex built-in dashboards, but in real projects the business connects Power BI or Tableau on top.

• Snowflake: same story. Built-in components, and Power BI or Tableau for the real reporting.

• Fabric: the win. Power BI is the core of the family, there is nothing to connect.

Who actually picks each one

• Databricks: companies with heavy engineering, big pipelines, streaming, machine learning and AI. But honestly, it is an overkill if you are a data analyst who just wants to work with SQL.

• Snowflake: analytics-first companies. Teams that speak SQL and want speed at scale without the engineering deep end.

• Fabric: Microsoft shops. One subscription, everything included, and the business already trusts Power BI. The price: you live fully in the Microsoft world.

Okay, which one should YOU learn?

Companies choose by context. You choose by background. But first, my rules, in order:

• Foundations first. SQL and Python are the core of everything. Never start a platform before them. And the number one is SQL: as long as we have data, SQL will never die.

• Learn one, not three. Learning one platform makes the second one really easy. It is like programming languages, the second language is always faster.

• The job asks for a different one? Apply anyway. This happens all the time in tech. Nobody learns everything. Show them you understand the concepts, and the switch is fast.

And now the honest answer, by background:

• You come from Power BI? Go Fabric. You expand from a tool into a platform, inside the same world.

• You are a SQL person and you do not want to go deep into coding? Go Snowflake. You stay in your world.

• You want the engineering deep end, the pipelines, the ML and AI? Go Databricks.

And if you are at zero and you ask me what I would learn today? My heart goes with Databricks, and this one is a little bit personal. If time goes back and I am a student again, I would go with Databricks because of the free account. I can experiment and build a lot of projects without paying as I go. And the second reason: inside one platform, I can move between data analytics, data engineering, AI engineering, and data science without switching tools. Deep in one role, small things left and right. That is exactly what many jobs are asking for today. And of course, the growth: around 80% a year.

So …

The full picture in five lines:

• Behind the scenes, all three are the same heart: cloud, distributed engines, SQL and Python.

• The personalities never change: the SQL people, the engineering people, the Microsoft world.

• The real differences: who manages the machines, who sees the files, and how you pay.

• Foundations first. Then ONE platform, picked by your background.

• You are choosing your first platform, not your last one. The skills transfer.

Hit reply and tell me which one you are picking, I read everything. And if you are searching for a job right now, I really hope you land one soon.

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

Here is a pain almost every data project has calculations are everywhere!

Some logic lives in SQL. Some in the pipeline. Some in Power Query, some in DAX, and some in an Excel sheet nobody talks about. Every tool in the chain can calculate, so every tool does. Nobody planned it. Each calculation just landed in whatever tool was open at that moment.

And then a number looks wrong, and the hunt begins. Where is this thing even computed? You find it in three places. With three different formulas.

The fix is not a tool. It is one rule:

🎯 The golden rule: Calculate as early as you can, as close to the source as possible. And calculate on the fly only what must react to the user, as close to the report as possible.

Why early wins

#1: Reusability. Watch what happens to the same calculation as you push it back:

• In a visual, it serves one visual.

• In a measure, it serves one data model.

• In Power Query, it serves one file.

• In a SQL view, it serves every report, every tool, every team.

The further back you push it, the more people inherit it for free. Find a bug? You fix it once, and everything downstream gets the fix.

The earlier a calculation lives, the more people it serves.

#2: Stronger tools. To be honest, for heavy transformations, SQL and Python are simply stronger than Power Query and DAX. Full languages, easy to test, easy to reuse, and your whole team can read them.

#3: Performance. An early calculation runs once at refresh. A late calculation runs for every user, on every click, all day long. Why pay a thousand times for something you could pay for once?

#4: One version of the truth. Logic that lives inside one report gets reinvented in the next one. Two slightly different formulas, and the same KPI shows two different numbers. And when users see different numbers, they stop trusting the whole project. And then they go back to Excel.

In the lakehouse I led at Mercedes-Benz, this was the whole game. We built the business logic once, inside the platform, and more than 40 analytics and AI teams consumed it from there. Now imagine every team calculating revenue on their own. Forty teams, forty versions of revenue.

The magic of this rule

And here is the part I really love. Once you know this rule, you start seeing it everywhere, because half of the data world was invented just to follow it.

• Why do companies build data warehouses at all? This rule. Prepare the data once, in one central place, and every project consumes it.

• Why do lakehouses have silver and gold layers? Same rule. Clean once, build the business logic once, and everyone downstream inherits it.

• Materialized views, OLAP cubes, aggregation tables? All the same trick. Pay for the calculation once, early, instead of on every single query.

• Feature stores in machine learning? Calculate the features once, and every model consumes them.

So my Friends…

Prepare early, once, close to the source. React late, live, close to the user. That is the whole rule.

We just opened the DAX chapter of the Power BI course with exactly this idea, explained step by step with the sketches.

And if you made it this far, you’re already one of the good ones.

Thanks for reading ❤️

Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

I have been waiting to type these words for a while, and today is the day:

🎉 The full Data Modeling course for Power BI is now LIVE and 100% free! 🎉

Over 5 hours, from the very first “what is a data model” all the way to a full hands-on project. All on YouTube.

To Be Honest With You

While I was building this course, I could not find anything like it on YouTube. The few paid courses that come close to this quality are charging around $500.

And I understand why. Data modeling is not something you can just read about and then teach. It only comes from working on real projects in real companies.

I could have easily put a price on it. But I still remember how it felt to want to learn something and not be able to pay hundreds of dollars for it. So just like my SQL, Python and Power BI courses, this one is yours, for free.

This is the most important chapter in the whole Power BI. I got invited many times to save Power BI projects that were failing and giving wrong numbers, and almost every time it was the same mistake. They skipped the data modeling.

And if you know me, you know I teach visually. Every concept is drawn by hand so the ideas actually stick.

📖 What’s Inside

• Why Data Modeling matters

• Tables and Schemas: facts, dimensions, star, snowflake, galaxy

• Relationships: cardinality, filter direction, active vs inactive

• Special Dimensions: junk and role-playing

• Fact Tables: the grain, multiple facts, the bridge

• Row-Level Security (RLS)

• The Nightmare Project: a full hands-on rebuild, end to end

• Golden Rules recap

Two Tips From Me

1. Learn it well. Data modeling is one of the most asked topics in data interviews. Master this course and you can handle almost any modeling question they throw at you.

2. Do the final project. We take a messy 23-table model and rebuild it into a clean star schema, step by step, exactly like I do at real work. It is yours. Build it, and put it in your portfolio. If you share your success on LinkedIn, a little credit would be awesome. :

)

That is it for today. Go build something clean.

Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

Big news today:

🎉 My new Power BI Data Modeling Project is LIVE! 🎉

A complete data modeling project, built exactly like I do in my real projects. We take a nightmare dataset and turn it, step by step, into a clean star schema. Completely free.

And by the way, it happened to me again with this one. Somewhere in the middle, I forgot the camera completely and started talking to you like my colleague, fixing a real problem at a real company. Same story with the SQL data warehouse and the Tableau dashboards:

“For a while, I thought that I’m working at the company. I’m not recording a video and I’m talking to a colleague.”

Yes, I actually said that on camera. 😅

The nightmare dataset

I refused to hand you a clean tutorial dataset. Instead, I collected the ugly scenarios from my real projects and packed them all into one dataset:

• 23 tables dumped into a stage, and nothing else

• Bad shapes, bad relationships, a data model that looks like a spider web

• A test customer (999) somebody left behind in the data

• Customer data scattered across six different tables

• Duplicate products with different codes, quietly waiting to break your numbers

Why so mean? Because there is a high chance that when you join a company, you will open a Power BI project that looks exactly like this. This dataset is my way of preparing you for that moment.

And we clean all of it together. For each step, you pause the video, you do it at your end, and then we continue. From 23 chaotic tables to a healthy star schema. Honestly, with this many facts, it is more like a galaxy.

The skill everyone skips

In my previous roles, I was involved in many Power BI projects that struggled badly. Slow refreshes. Slow reports. And worst of all, wrong numbers.

And after investigating, it was almost never the dashboard. Almost each time, it was the bad model underneath the reports.

The thing is, most people skip data modeling completely. They connect the tables somehow, jump straight to the visuals, and hope for the best. It works for the demo. Then the project grows, the numbers stop matching, and people stop trusting the whole thing. I have seen projects die exactly like this.

Across all my years in data, I met only a few people who can turn a chaos model into a clean one. That is why this skill is going to make you stand out of the crowd.

The rules I want you to keep

The project is full of lessons, but if you only remember five things:

• Never connect two facts directly, always put a shared dimension between them.

• Protect the number. Put your total sales in a card and know it by heart. Everything you merge into the fact must land on exactly that same number. Mine jumped in the middle of the project (duplicate products), and I caught it in minutes instead of shipping wrong numbers for months.

• Every column must earn its place. One single point of truth for each info. In one project we dropped the hash keys from every table and saved around 20% of the dataset. Never be the person who leaves things “just in case”.

• Don’t trust until you test. We lock the model with row-level security, then open the report as Nora and check she only sees North America.

So …

If you build this model with me until the end, make it your portfolio project. Share it in LinkedIn, and tag me if you want. And when you get interviewed, talk about this project. This skill is rare.

The next time a spider web data model is staring back at you, you will not panic. You are going to look at it and smile.

Thanks for reading ❤️

Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

Let me be honest with you. Most people are stuck in the first phase of AI. You open Claude or ChatGPT, ask a question, get an answer, and that is it.

And the moment you try to go one step deeper, you hit a wall of scary words.

AI agents. Sub-agents. LLM. MCP. Context engineering. Loop engineering. Skills. ReAct.

These words scare people. They stop them from ever reaching the real power of AI.

I am going to take one boring thing I do every morning and hand it to the AI, one step at a time. Every step needs one new idea, and that idea is the scary word. So the buzzwords are not the topic. Each one is just the tool that unlocked one more step.

The task: my morning emails, all by hand

Every morning after making my coffee, I open my inbox and hunt for sponsor offers. I am a content creator now, and this is real money for the channel.

But not every offer is real. I get a lot of fake AI sponsors from websites created like last week. So before I reply, I run the same little investigation every time:

• Read the offer.

• Check if the company is even real, and look at their website.

• Check if my name is spelled right.

• Look up the person on LinkedIn.

• Then decide, reply or skip. If it is real, write a clean reply and send.

Then the next one, and again, and again. At the start I got two or three a day. Now I get around 200 emails a day, and this eats about half an hour every morning.

And here is the thing. It is really boring. Some days I skip it, and then I either drown the next day, or I miss a real sponsor and lose it.

If you repeat the same judgment every morning, that is exactly the task to hand to AI.

Let the AI write the reply

So I pick the easiest step first, the writing.

I copy the sponsor email, drop it into Claude, and ask for a reply. Behind that chat window is an LLM, a large language model. It read a massive amount of public text, books, websites, code, to do one thing: predict the next word. That is why it is so good at a first draft.

But the draft is never perfect. So I push back, make it shorter, friendlier, then copy it back into Gmail, do the last touch, and send. One step is off my plate, but I am still the middleman copying between two windows.

A chatbot can write for you. It cannot yet work for you.

AI is reshaping analytics engineering, but organizations continue to face challenges around trust, governance, and cost management. Drawing on insights from hundreds of analytics and data professionals, this report examines the trends, priorities, and practices defining the next generation of data teams. Read the dbt Labs report

The research that eats my morning

The real time sink is not the writing. It is the research. Googling the company, checking LinkedIn, opening their website.

So I ask the AI instead. Do you know this company? Are they legit? For an old, well known company I get a good answer. But for one that started two weeks ago, the AI answers with full confidence and it is completely wrong. You google it yourself, get a different story, and this is the moment people say the AI is lying.

But it is not lying. This is a hallucination, when the AI sounds completely confident but is wrong. It has no intent, it just fills the gap with a guess. And there is a reason for the gap. Every model has a knowledge cutoff, it only learned up to a certain date, so a website made last week does not exist for it.

So how do we fix this? We give the model tools. A tool lets the AI do something outside its own head, and the famous one is web search. Now it has hands.

• Without tools, the AI guesses from old memory.

• With tools, it reads the real website, checks the domain age, and comes back with facts.

The AI is not smarter because it sounds confident. It is smarter when it can go and check.

Let it into my inbox

Now the AI can write and research. But I am still the delivery person, carrying text between Gmail and the chat, one email at a time. With hundreds of emails, that is painful.

So I give it real access to my inbox. And this is exactly where people freeze. No way. I am not letting AI walk into my emails. It might send junk in my name, or delete something important.

I understand that fear completely. But it is not as scary as you think, because of one word: control.

The AI connects to your apps through MCP, the Model Context Protocol. Think of it like USB-C for AI, one safe standard connector. And here is the part that matters. The model never touches your inbox. It only sends a request, and your app decides if that request is allowed:

• Read only if you are nervous.

• Read and draft, but never send.

• Block delete completely.

• Keep the final Send button for yourself.

If the model tries to delete and you only allowed reading, Google says no. Once it is connected, I hand it the whole routine in one prompt: open the latest emails, keep the sponsors, research each one, summarize, draft a reply, next. That fixed list of steps has a name, a workflow. No decisions yet, just a recipe it runs end to end.

Connecting AI to your apps is not giving up control. It is defining control clearly.

The moment it becomes an agent

Now the workflow gives me a summary and a draft for every email. But with 100 emails, I get 100 drafts, and I still read them one by one and decide. So the decision is still on me.

So now I hand over the judgment itself. This is the important jump, because this is the moment the chatbot turns into an agent.

To do it, I build a skill. A skill is just my know-how written down once, my rules, my style, saved so the model can read it. Like explaining to a new person exactly how you decide. Now the AI runs the same checks I do by hand, and decides my way every time.

Put it all together, the LLM, the tools, the workflow, and the skill that decides like me. That is an AI agent. The moment the model can choose, skip, decide, and act on its own, it becomes an agent. Its loop has a fancy name, ReAct: it thinks, does it, looks at the result, and thinks again, until the job is done.

Not a robot with feelings. Just a model in a loop, using tools, following your rules, choosing the next step.

A chatbot answers. A workflow follows. An agent decides what to do next.

Make it sound like me

Now the agent decides like me. But the replies still do not sound like me. Too polished, too generic. So I need a second skill, this time for my voice.

But I do not write this one by hand. I tell the AI to read hundreds of my old sent emails and learn how I open, how I close, my tone, the words I use. Then it bundles all of that into a skill on its own. Now I have two skills, one for the judgment and one for my voice.

And one warning. More skills means more context, and more is not always better. Overload the AI and it gets distracted. Giving it exactly the right context and no junk, that is context engineering.

But there is still a problem. Over time the AI drifts and stops following my voice. So I tell it to reread the skill, it apologizes, fixes it, and I am back to babysitting. That is exhausting.

The fix is a self-check loop, what people call loop engineering. Instead of handing me the draft, the agent rereads its own draft against my voice skill first. If something is off, it rewrites, then checks again, until it truly sounds like me. Only then does it reach me. In Claude you just type /loop to get this.

The real unlock is not an AI that writes. It is an AI that checks its own work before you ever see it.

From one worker to a team

By now the whole system works. But with hundreds of emails, one agent going through them one by one takes about half an hour. I want this in one or two minutes.

So I stop using one agent and build a team. I promote that one agent to be a manager. And like any real manager, it does not do the work itself. It slices the inbox and hands each slice to a helper, a sub-agent.

Each sub-agent is a full agent. It reads, researches, and drafts, but only for its own slice, with no idea about the others. So they all run in parallel, report back, and the manager combines everything into one answer for me.

Nothing here got smarter. It just got faster. Half an hour becomes two minutes. When I was testing Fable 5, I launched around 200 agents at once to optimize my website. Very expensive, but honestly very cool.

The AI did not get smarter here. It just got faster, because the work could be split.

And now it runs without me

The last touch is simple. Right now I still open my Mac every morning and tell it to start. But I do this every day, so why start it by hand?

So I add a schedule inside Claude, a trigger that runs at the same time every day. It checks the inbox, researches, decides, writes like me, checks its own work, and prepares everything in the background. My PC does not even have to be on.

And here is my one line. I automated everything except the last step. I kept Send for myself. Sometimes I just do not feel like working with a certain sponsor, or I want the final look. Automation does not mean removing every human decision. That last call stays with me.

Automating the boring part is the goal. The final judgment is the part worth keeping.

So …

I took one boring routine and handed it over, one step at a time. And every buzzword that used to scare me was just the tool that unlocked the next step.

• LLM let it write the first draft.

• Tools and web search stopped the hallucinations with fresh facts past its knowledge cutoff.

• MCP connected it to my inbox safely, on my rules, and the workflow gave it the steps.

• A skill taught it to decide like me, and that is when it became an agent running its ReAct loop.

• A second skill made it sound like me, and loop engineering made it check its own work.

• Sub-agents turned one worker into a team, half an hour down to two minutes.

• A schedule made it run on its own.

But one thing never changed. I stayed the judge. The AI reads, researches, decides, writes like me, and checks itself, and I still keep the final Send. You stop being the one doing every repetitive step, and become the one who designs the process and judges the result.

AI did not take my skill away. It moved my skill into the rules, the checks, and the final call.

So here is my one move for you. Do not start with the buzzwords. Start with one boring task you repeat every day. Write down the steps, automate the easiest one, then add one upgrade at a time. That is how the scary words stop being scary.

If you want the full story with all the sketches and animations, the video is on YouTube.

Thanks for reading ❤️

Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

There’s one question I keep getting everywhere.

Should I learn Excel, Power BI, SQL, or Python? And now with AI, do I even need any of them?

And honestly, this is the wrong question.

If you feel lost between all these tools, don’t worry. I just published a new animated-sketch video that walks through the whole thing as one story, and this is the short version.

Because here is the thing nobody tells you. These tools never replaced each other. Each one solves a real pain, and then quietly hands you a bigger one.

Let me walk you through the story.

Excel: the whole job on one laptop

It always starts the same way. A manager has a question, the data sits in some application, and you pull it into Excel. You explore it, clean it, write a few formulas, build a chart, drop it into PowerPoint, and present the answer. Question in the morning, answer by lunch. And honestly, in almost every company there is that one Excel file that quietly runs the whole business, and everyone is scared to touch it.

Why everyone starts here

• No setup, no database, no code. Just you and a laptop.

• The fastest way to answer a small, quick question.

• Anyone can do it, which is why everyone starts here.

Where it falls apart

• The file grows until it takes minutes to open, and Excel caps out around a million rows.

• “Can I get this every week?” turns the whole thing into a manual routine.

• You split the file to survive, and now you have sales_final, sales_final_v2, and sales_final_OLD_DO_NOT_USE. Someone is always using the wrong one.

• I met people who got stuck for years doing one thing, fighting Excel until it refreshes.

• The file grows until it takes minutes to open, and Excel caps out around a million rows.

• “Can I get this every week?” turns the whole thing into a manual routine.

• You split the file to survive, and now you have sales_final, sales_final_v2, and sales_final_OLD_DO_NOT_USE. Someone is always using the wrong one.

• I met people who got stuck for years doing one thing, fighting Excel until it refreshes.

Excel does the whole job alone, but it collapses the moment the data grows.

Power BI: automate it and share it

So you move to Power BI. This time you connect straight to the source instead of exporting files. Your cleaning becomes a recipe in Power Query, your calculations become DAX, and on top you get a live dashboard people can click around. You publish it once, it refreshes by itself, and you just share a link.

Why analysts love it

• Connect once, refresh automatically, no more weekly nightmare.

• The home of dashboards and interactive reports.

• All of it without writing a single line of code.

Where it cracks

• As the data grows, the refresh crawls from a few minutes to over an hour, and Power Query is a black box you can’t really tune.

• Every team builds its own report, and the same revenue comes out different in Finance, Sales, and Marketing.

• Three numbers in one meeting, and nobody knows which one is real.

Power BI automates the work, but it was never built to be the single source of truth.

SQL: the king of working with data

That truth needs to live in one place, a database, the data warehouse. And the language you use to talk to it is SQL. Here is the thing about SQL, it was built for exactly one job, working with data, and that is why it is so good at it. You write your logic once as clean tables and views, organized in layers like bronze, silver, and gold. Power BI stays on top, light, and just reads the final layer. Now everyone walks into the meeting with the same number.

Why it's the king

• The best tool for working directly with data. SQL was built for this one job, so it is the simplest and fastest way to transform, reshape, and prepare it.

• One shared source of truth, written once and reused by every report and team.

• The heavy work runs where the data lives, and you finally have real tools to make it fast, like indexes, better joins, and partitioning.

• Want to investigate something? A few lines of SQL and you have the answer, way faster than clicking around in Power BI.

Its one weakness

• SQL lives inside the walls of the database. It can’t call an API or listen to a stream.

• Modern sources keep moving to APIs and streams that SQL can’t reach.

• Debugging stored procedures is honestly a nightmare.

SQL is the king inside the database, but the job keeps moving outside its walls.

Python: everything around SQL

And that is where Python comes in. First, let me kill the biggest fear. Python does not replace SQL. Your SQL keeps doing the heavy lifting. Python just wraps around it and handles everything outside the database, connecting to any source, logging, quality checks, and messy data like JSON. That Excel file a colleague just emailed you? One line of Python, and it sits right next to your database data.

Why it's so powerful

• Connect to anything, APIs, streams, files, all in one script.

• Automate the full pipeline and add real logging and quality checks.

• pandas makes tables easy, and if you already know SQL it feels like home (a groupby is just GROUP BY).

• It opens the door to advanced things like forecasting and machine learning.

The trap

• Everything now goes through you. Every new task is new code you write and maintain.

• The sources keep growing, and you and your team become the bottleneck.

• Your day turns into maintaining pipelines instead of talking to the data.

Python crosses every wall, but now you are the wall.

AI: write the code, go faster

So the manager says we have AI now, let’s use it. And it feels like magic. You describe what you want and the AI writes the SQL and the Python in seconds. The boring stuff, documentation, reviews, repeated code, just gets done. It speaks all of them and sits on top of everything you built.

But here is the most dangerous part of the whole story, and you can’t see it.

When normal code is wrong, it crashes. The error is loud. But a wrong SQL query doesn’t crash. It runs fine, everything turns green, and it hands you a confident, wrong number. One missing filter or one wrong join can quietly drop half your rows, and the job still finishes with no warning, nothing red.

Why it feels like magic

• Writes the SQL and Python for you in seconds.

• Handles the boring, repeated work, and even debugs your errors and explains that old script nobody understands.

• The first tool that speaks all the others at once.

The silent danger

• Wrong data fails silently. No crash, no red, just a wrong number in a real decision.

• Your whole platform runs on trust, and once people stop trusting the numbers, it is very hard to win them back.

• Looks right and is right are two very different things.

AI gives you speed, but it can’t tell you if the answer is actually true.

So …

Step back and look at the whole thing, and two things become clear.

First, nothing here ever died. Each tool is still the best at one job.

• Excel for a small, quick question.

• Power BI for dashboards and sharing.

• SQL for the one truth underneath.

• Python for everything around the table.

• AI for speed on top of all of them.

Second, the pattern. Every tool solved the pain in front of you and then handed you a bigger one. Excel buried you in manual work, Power BI split the truth, SQL got stuck inside its walls, Python made you the bottleneck, and AI made everything fast but hard to trust. This has been going on for decades. AI is just the newest link, not the end of it.

And in every single chapter, there was one person who knew if the number was right. With AI writing everything in seconds, that person matters more than ever.

AI didn’t make these skills useless. It made you the judge.

So if you’re starting today, don’t try to learn five things at once. Start with SQL, it is the heart. Then add Python for everything around it. Excel and Power BI you’ll pick up on the way. Then put AI on top, to go faster, while you stay the judge.

The tools change. The pattern doesn’t.

If you want the full story with all the sketches and animations, the video is on YouTube.

Thanks for reading ❤️

Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

Two, three years ago, when I started hearing about AI engineering, my first reaction was:

“Sounds like a different world. Not for me.”

I was wrong about that. And after seeing how it played out in my own projects, I think a lot of you are sitting in the same spot I was sitting in back then.

Let me walk you through how I figured it out.

How it crept into my own projects

It didn’t happen in one big moment. It happened slowly.

I can tell you from my projects, over time, I started catching myself adding small AI components here and there. A little embedding step. A small retrieval thing. Nothing fancy at first.

And then customers started asking for it. They had real data platforms already, working, in production, and now they were saying:

“Hey, can you extend this with our AI use cases?”

So I found my data platform turning into a data and AI platform. Without me planning it. Without a big strategic decision. Project by project, it just kept happening.

And once I noticed it, I went and looked at the numbers.

This is not the future. It is already happening.

There was a survey from MIT and Snowflake. They asked around four hundred senior data and tech leaders how much time their teams were spending on AI work.

Back in 2023, it was around 19%.

Today it is around 37%.

And in two years, they expect more than 60%.

So no, my friends, this is not the future. This is already happening to us.

The job didn’t get replaced. The job grew a new layer.

And once you understand that, the question is not “do I need to care about AI engineering?”. The question becomes “how do I fit it into what I already do?”

The two-worlds confusion

I get this a lot from messages and comments. People line up the two sides like this.

On the data engineering side, we have what we have always done. ETL, data modeling, storage, pipelines, scheduling, data quality, DevOps. The stuff we do every day at work.

On the AI engineering side, suddenly different words. RAG, embeddings, vector databases, prompt engineering, fine-tuning, agents, LLMOps. All shiny, all new, all confusing.

And if you sit back and just look at this split, you say:

“Okay, two different worlds. Nothing to do with me.”

That was my reaction too. But once you look closer, you see something else.

Look closer. Same pattern.

You know how a classical data engineering project flows. Sources (databases, files, APIs), pipeline, warehouse or lakehouse, BI tools and dashboards. You have built it a hundred times.

Sources → Pipeline → Storage → Consumption.

Now look at the AI side. RAG, retrieval-augmented generation, sounds fancy. But the story is the same.

The sources are different. This time it is documents, PDFs, emails, tickets, web pages. The pipeline cleans them, splits them into chunks, and turns them into embeddings. So instead of aggregating, we transform text into numbers. The storage is different too. Instead of a warehouse, we use a vector database. And at the end, the data gets consumed by AI agents and LLMs, that go read it to answer questions with the right context.

Now put both side by side.

Same layering. Different transformations.

That is the moment it clicked for me. AI engineering is not a parallel universe. It is another use case sitting on top of the same skeleton we have been building for years.

Companies don’t build two ecosystems

Now the big practical question. Are companies building two separate platforms? One for data, one for AI?

The honest answer is no.

Most of the companies I work with already have solid data engineering projects. They are not going to throw that away and start from scratch. So what they do is they extend the existing platform.

• New sources come in. Documents, PDFs, emails, tickets, web pages.

• The pipeline grows to handle them, with cleaning, chunking, embedding.

• The storage layer gets a new component, the vector database, sitting next to the warehouse and the lakehouse.

• And in the consumption layer, AI agents plug in.

So we treat AI use cases like any other data engineering requirement. New sources, new pipelines, new storage, new consumers.

And here is where it gets really good. The AI agent doesn’t only have access to the vector database. It can also reach into the whole lakehouse. All your data is right there.

More data, more context, more use cases.

This is exactly why AI engineering is so close to us. Because the data layer we have been building for years is exactly what AI needs.

So where do AI engineers fit?

Good question, and I get it a lot.

If data engineers can do the whole AI pipeline, why do we even need AI engineers?

Same reason we have data analysts, data scientists, BI developers. We data engineers don’t do the full thing end to end. We pick the source systems, we process the data, we store it in a shape that is easy to consume. And then we stop.

We don’t decide if the users should use Power BI or Tableau. We don’t sit with stakeholders to define business metrics. We don’t go and design the dashboards. That is not our part.

Same with AI. We will not pick which LLM model to use for which use case. We will not design the chatbot interface. We will not build the APIs that the business application calls. All those decisions live on the consumer side.

We own the data processing part. We always did.

Same job. Different consumers.

And honestly, this isn’t the first time we’ve gone through this kind of shift.

ETL → Big Data → Cloud → AI

When I started in this industry, we were called ETL developers. Then the world shifted, and suddenly we were big data engineers, working with Hadoop, MapReduce, all that stuff.

Then the cloud came. Azure, AWS, Databricks, Snowflake. We became modern data engineers.

And now we are in another shift. AI use cases. New sources. New components. New consumers.

But in the heart of the job, my friend, nothing changed.

We move data from A to B. We process it on the way. We make it easy to consume for the next person.

That is what we do. That is what we will keep doing.

So what should you actually do?

You have three options.

Option 1: switch completely. Drop data engineering and become a full AI engineer end to end.

Option 2: ignore the whole thing. Stay where you are, do what you do, hope nobody asks.

Option 3 (this is the one I recommend): stay as a data engineer and add the new AI engineering pieces to your skill set. Combine the two worlds.

And honestly, this is not that hard. You don’t need to become an LLM expert. You just need to learn a few things:

• How to connect documents as a source.

• How to split text into chunks.

• How to turn it into embeddings.

• How to store it in a vector database.

• How to query a vector database.

That is the RAG pipeline. And it is exactly the kind of work we already know how to think about. Just new components on top of patterns we have used for years.

Put one project like this on your portfolio, and you are already ahead of most data engineers in the market right now.

So …

AI engineering is not a different world. It is the next layer of data engineering.

If you are a data engineer, you are already much closer to it than you think. You just need to extend.

And honestly, I’ll tell you where I think this is going. In two or three years, the job titles will look different. The work will look the same. The people who get hired will be the ones who already extended.

So don’t see AI as a threat. See it as the next chapter of the same job you have been doing all along.

Thanks for reading ❤️

Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

Let’s talk about the most skipped step in data work: data modeling.

No hype, no shiny tool, nobody makes content about it. And honestly? It’s the number one reason data projects fail. Not just Power BI reports. Pipelines, warehouses, lakehouses, all of it.

People connect the data, run some transformations, and jump straight to building. The model? Skipped.

Weak model = weak project.

So I just started what I think is the most important chapter in the whole Power BI course. Like always, we build it the right way, step by step, with the sketches.

The Trap: One Big Flat Table

Someone asks for a report. You connect the source, grab the columns you need, and dump everything into one big flat table. Add a few DAX measures, build the report, share it. One or two weeks of work.

And honestly? It feels great. You’re fast, you’re flexible, the report works, the user is happy.

But here’s the trap:

One big table is not a data model.

It’s fine for one small report. But Power BI projects never stay small. The data grows, the users grow, the requests keep coming. And that one table starts breaking things everywhere.

Here is why:

#1: The file gets huge. With 10,000 rows you won’t feel a thing. But push it to a million, ten million rows, and the same information repeats on every single row, over and over. You’re storing the same text thousands of times instead of once. The file blows up for no good reason.

#2: Refresh gets painful. Once the file is huge, the refresh follows. What used to take a few minutes turns into 30 minutes, an hour, more. Now just getting fresh data into Power BI is a daily fight, and every fix takes longer to test.

#3: Reports get slow. Every time a user clicks a slicer, Power BI has to scan that giant table to build the visual. So the report drags. And in real projects users aren’t patient. If it doesn’t open in two or three seconds, they don’t say “the model needs work,” they say “Power BI is slow,” or worse, “this project is bad.”

#4: DAX gets ugly. Most people think they’re bad at DAX. They’re not. The one big table is forcing them into complicated formulas. A measure that should be one line becomes ten, because you’re twisting things just to get the right number.

Bad data model = complicated DAX.

How a Real Model Fixes It

The fix isn’t complicated. Stop forcing everything into one table. Split the data into separate, meaningful tables and connect them with relationships.

Now each piece of information is stored once, in its own table, instead of repeating on every row. The big table only keeps what it actually needs.

That one change fixes the whole chain. The file gets small. The refresh gets fast. The reports get fast, because a slicer now reads a small table instead of scanning millions of rows. And the DAX gets simple, because the relationships do the heavy work for you.

The model and the relationships do half the work before you write a single measure.

The Bigger Danger: One Table for Every Report

The technical problems are painful. But there’s a bigger one.

When you skip data modeling, you fall into a pattern. A user asks for a report, you build a table for that report. Another user asks for another report, you build another table. Another dashboard comes in, you do it again.

Over time every report has its own logic, its own transformations, its own version of the truth.

One report, one table. This is the beginning of the end.

Maintenance Becomes a Nightmare

Say you find a mistake in the transformation logic. With one shared model, you fix it in one place. With one table per report, you open file after file and repeat the same fix everywhere, trying to keep them in sync.

That’s a lost battle. One day someone forgets a file. One measure changes in one place but not the other. Now the reports don’t match.

One report says 1.2 million. Another says 1.4 million. Same question, different answer. And when users see different numbers, they don’t care why. They just see Power BI giving them different numbers.

When the numbers don’t match, users stop trusting the whole project. And then they go back to Excel.

Build Around the Business, Not One Report

This is the real shift.

A flat table is built around one report. A data model is built around the business. Instead of asking “what columns do I need for this one report?”, you ask “what does the business actually need to answer?”

Then you build a model that can answer many questions, not just one dashboard request. One model serves many reports. Fix a calculation once, every report using it stays correct.

That’s where consistency comes from. And consistency is what builds trust.

But Should Everything Use One Giant Model?

No. This is where people go to the other extreme.

They hear “shared model” and build one giant model for the whole company. Everything depends on it, so changing one measure feels terrifying because it can hit dozens of reports at once.

So the answer is the middle:

Not one table per report. Not one model for the whole company. One shared model per domain.

One model per domain, each serving a group of related reports. You get the reuse without turning the whole company into one fragile model.

Quick Recap

Bad data models create technical problems:

• Large Power BI files

• Slow refresh

• Slow reports

• Complicated DAX

And project problems:

• Repeated work

• Hard maintenance

• Different KPI numbers

• Users losing trust

Data modeling takes time. But skipping it is more expensive. Your report might work today with one big table. Over time, that shortcut becomes the reason the project fails.

If the model is weak, the project is weak.

In the next videos we go deeper. What data modeling actually means, the different model types, and how to build clean, fast Power BI models, step by step with the sketches.

Watch the new chapter here: [VIDEO LINK]

Thanks for reading ❤️

Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

There’s one question I keep getting everywhere.

“Will AI replace us?”

And honestly… I get it. Especially if you’re still learning, this question can sit in your head all day.

Now if you ask me directly, my answer is a bit annoying.

It depends.

I know… not the answer you want. But I’m not trying to avoid it. The problem is, this question is not simple, and most of the discussions online are missing something very important.

They ignore how things actually work inside real companies. So instead of giving you a short answer, let me walk you through how I think about this.

The reality inside companies

What you see online vs what actually exists

Most AI demos you see are built on very clean setups. A few tables, nice structure, everything documented perfectly. In that world, AI looks insanely powerful.

But real projects don’t look like that at all. They’re messy, huge, and everything is connected to everything.

I worked on a lakehouse project where we spent years just connecting systems. Data was coming from APIs, Kafka streams, databases, files… and we ended up with more than a thousand tables. And honestly, that was just the starting point. On top of that, there was business logic built layer by layer over time.

So when someone says “AI can build this with a few prompts”… yeah, it sounds nice.
But it skips the hardest part.

The hard part is not writing code.
It’s understanding everything behind the code.

Companies move slower than technology

Another thing people underestimate.
Technology moves fast. Companies don’t.
If you watch what’s happening in the media, it feels like everything is already AI-driven. Like every company has figured it out and we’re already there.

But the moment you step inside a real company, you see a completely different reality.
You still find Excel running critical reports. You see systems that have been there for years and no one wants to touch them. And there’s always a big chunk of data that isn’t even integrated yet.

And changing all of this… it’s not quick.

You need to migrate systems, build pipelines, set up governance and security, and at the same time train people so they actually understand what’s going on. And all of this has to move together.

So when I hear someone saying that jobs will disappear very soon, I usually just pause for a second and think… yeah, let’s see 🙂

Not because AI is weak. But because companies don’t change overnight.

How AI changes data teams

Now let’s talk about data teams.
Most companies have a lot of data, but small teams. So they only process a small portion of it.
Then AI comes in and makes those teams faster. And this creates a real decision.

Do you reduce the team, keep the team, or expand?

If you reduce the team, you save cost… but nothing really improves. You’re still processing the same small portion of data, and you might even hurt quality because the team was already stretched.

If you keep the team, you start doing more. More data sources, more pipelines, more insights. This is what I see most often. It works well, but only to a certain point. Eventually, you hit a new limit.

If you expand the team, you treat AI as a growth opportunity. You invest more, improve data quality, and use a much bigger portion of your data. It costs more, but the value is much higher.

And from what I’ve seen… most companies are not rushing to reduce data teams. They either scale what they already have or start investing more.

Because in the end, AI doesn’t reduce the need for data work.
It actually increases it.

What I think about the job roles

Instead of asking “Will AI replace data analysts or engineers?”, I prefer to break the job into parts. Because not everything is equal.
Let’s start with data analysts.

Will AI Replace Data Analysts?

SQL
is the first thing everyone talks about. And yes, AI is already very good here. You describe what you want, and it gives you a query. For simple things, it works great.
But once things get messy, multiple joins, unclear schemas, relationships… you start to see the limits. It doesn’t really understand your data, it just predicts.
Still, if I’m honest, this part will mostly be automated.

Dashboards:
AI can generate charts, but real dashboards are not just visuals. They include business logic, multiple datasets, filters, edge cases… and most importantly, trust.
At the end, someone still needs to look at the numbers and say, “this is correct.”
Then there’s something people don’t talk about enough.

Finding the right data:
In real companies, this is not obvious at all. You might have multiple tables that look the same, different systems storing similar data, and no clear documentation.
So what do you rely on? Experience. Context. Conversations.
This is where analysts actually spend a lot of their time, and this is where AI struggles the most.

Understanding the business:
Not just what people ask… but what they actually mean. Sitting with stakeholders, asking better questions, translating vague ideas into something measurable.
This is not about tools anymore. This is about thinking.
And here, AI is not even close.

Now to be fair, there is one part that will disappear.
The repetitive stuff. The small requests, the same questions again and again, the quick checks.
And honestly… that’s a good thing.
So when people ask me if AI will replace data analysts, my answer is always the same.
If your work is mostly writing queries and building simple dashboards, then yes, a big part can be automated.
But if you understand the business, work closely with people, and build things others rely on, then you’re not being replaced.

Will AI Replace Data Engineers?

Now let’s look at data engineers.

Coding:
AI is already very strong here. It can generate SQL, Python, and Spark code quickly. And this will only improve.

Build data pipelines:
AI can already create simple ones, and in the future, it will likely handle much more. Still, someone needs to review before anything goes to production.

Architecture:
Designing how systems are structured. Choosing between lakehouse or warehouse. Defining layers. Handling performance and scalability.
This requires deep understanding of both the technical side and the business context. It’s not something you can fully automate.

Data Modeling:
This is one of the hardest parts. You need to understand how different data sources connect, how data will be used, and which modeling approach makes sense.
Even experienced engineers find this challenging.
I don’t see AI replacing this anytime soon.

Operations:
Operational tasks like monitoring pipelines can be automated. AI can detect issues, suggest fixes, and possibly resolve them.

So again, the same pattern appears.
If someone is only coding and building pipelines, their work can be automated.
But if they understand systems, architecture, and data modeling, they become extremely valuable.

The role of data in the AI world

There is one important idea that didn’t change.

Before AI, we already knew:

Bad data leads to bad analysis.

Now with AI, it’s exactly the same.

Bad data leads to bad results.

So someone still needs to prepare that data properly. And this is why data roles are not disappearing. They are evolving.

So …

AI is not replacing jobs in a simple way.
It’s replacing parts of jobs.

• The repetitive parts.

• The mechanical parts.

• The parts that don’t require deep thinking.

But the more you move toward understanding, decision-making, and communication, the harder it becomes to replace you.

If you’re thinking about your future, don’t try to compete with AI. Work with it.
Learn how it fits into your field. Use it to move faster, but don’t let it replace your understanding.

For me, AI is not something to fear. It’s something that removes the boring parts of the job and lets you focus on what actually matters.

And over time, you’ll start to see clearly what is real and what is just noise.
If you’re still here, I appreciate it.

Much love,
— Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

Today we’re going to do something a bit different.

Instead of talking about how to become a data engineer, I want to focus on the mistakes that might be stopping you from getting hired.

Over the last few years, I’ve seen many people move into data engineering. They learn Python, SQL, build projects, follow roadmaps… and still don’t land a job.

Yes, AI made things more competitive.

But companies are still hiring data engineers, even juniors. I see it from your messages, LinkedIn, and inside teams.

So the real question is not whether it’s possible.

“Why do some people succeed while others stay stuck?”

After years in the industry, I can tell you it’s not random. The same mistakes keep repeating.

So in this article, I’ll walk you through the biggest ones, and if you avoid them, things become much easier.

Mistake 1: Trying to Learn Every Tool in the Industry

Trying to learn every tool in the industry. I see this all the time.

Someone decides to become a data engineer and makes a big list of tools to learn.

Kafka, Airflow, Spark, Snowflake, Databricks, AWS, Azure, dbt…

At the end, the roadmap looks like a technology supermarket.

This is a mistake.

If you try to learn everything at the same time, you end up knowing a little about everything, but nothing deeply.

And companies don’t hire you for that. They hire you based on your project experience.

In real projects, you don’t use all those tools. You use a specific stack, like SQL, Python, Spark, Databricks.

And in interviews, they go deep. They expect you to understand the architecture, the components, and how things work.

“If you try to learn everything, you end up mastering nothing.”

So instead of learning 20 tools on the surface, focus on one stack and go deep.

Mistake 2: Focusing Only on Tools

Focusing only on tools and forgetting about the real data engineering skills.

I can tell you from my own experience. Back in 2013, I built my first data warehouse using Talend, then moved to IBM DataStage. Later at Mercedes-Benz, I worked with Azure Data Factory, Synapse, and eventually Databricks.

Different tools, same problems.

That’s the key.

Tools keep changing, but the core concepts stay the same.

If you only learn tools, it becomes very hard to move from one tool to another.

That’s why you need to spend some time understanding the fundamentals.

Things like:

• What is a data warehouse, data lake, lakehouse

• ETL vs ELT

• Batch vs streaming

• Data modeling (star schema, snowflake, Data Vault)

You don’t need to master everything, but you should understand what they are and when to use them.

Because companies ask about this.

“Tools change, but concepts stay.”

So yes, learn tools, but also take time to understand how data engineering actually works.

Mistake 3: Ignoring SQL

Ignoring SQL. This one really surprises me.

I’ve seen many engineers who are good with Python and Spark, but they struggle with very simple SQL queries, even basic joins.

A lot of people jump directly into big data tools because they want to work on the “cool” stuff.

But they skip one of the most important skills.

SQL.

And sometimes I hear things like: SQL is dead, it’s not cool, it’s only for beginners.

But this is not true.

In real projects, a huge part of your work still happens in SQL.

Because almost every platform like Databricks, Snowflake, and even tools around Kafka, allow you to use SQL to work with data.

You will use SQL to:

• explore data

• debug issues

• build transformations

• apply business logic

For example, in the Silver layer, you might use PySpark, but very often you also use SQL.

In the Gold layer, you will use SQL heavily for business rules.

“If your SQL is weak, your daily work becomes harder.”

So don’t skip SQL. Start with it, get comfortable, then move to Python and Spark.

Mistake 4: Building Toy Projects

Building toy projects.

Projects are very important today. Sometimes they matter more than certificates because they show what you can actually build.

But most of the projects I see are very small. If you look closely, many of them are just loading one CSV file, cleaning it, and exporting another CSV.

Yes, technically it’s a pipeline, but this is not how real data engineering projects look.

In real scenarios, you work with multiple data sources. Data can come from APIs, databases, files, or even streams. And your job is not only to move data from A to B, but also to handle errors, manage retries, validate data quality, and monitor what is happening in the pipeline.

You also need to show how you think in terms of architecture. For example, building a lakehouse with Bronze, Silver, and Gold layers, and explaining the role of each one.

You can also make your project more realistic by adding bad data, testing with larger datasets, and checking how your pipeline performs under pressure.

“Small projects show effort, but real projects show how you think.”

So don’t build many small projects. Build one serious project that looks like a real system.

Mistake 5: Learning Outdated Technologies

Learning outdated technologies.

I’ve seen people follow roadmaps or courses that are already 8 to 10 years old. They spend a lot of time learning things like managing Hadoop clusters, manually configuring Spark, or working heavily with on-premise ETL tools.

Now don’t get me wrong, these things were very important in the past.

But the data ecosystem has changed a lot.

Today, many companies don’t want engineers spending their time managing infrastructure. They want them to focus on building pipelines, working with data, and delivering value.

That’s why many teams are using platforms like Databricks or Snowflake, where most of the infrastructure is handled for you.

So instead of spending months going deep into cluster management and legacy systems, it’s better to focus on how modern data platforms work and how to build real solutions on top of them.

“If you prepare for the past, you might miss where the industry is going.”

Of course, it’s good to understand the basics of older systems, but don’t go too deep into them. Focus on the direction the industry is moving today.

Mistake 6: Going to Extremes with AI

Going to extremes with AI.

Right now, I see two types of people trying to become data engineers.

The first group relies completely on AI. They open a tool, generate a data pipeline, copy the code, run it, and move on without really understanding what is happening.

This becomes a problem very quickly.

In real projects, things are more complex. You deal with multiple data sources, messy data, and unexpected issues. And when something breaks, you need to understand what is going on to fix it.

The same thing happens in interviews. If someone asks you why you designed something in a certain way or how you would debug a failure, it becomes difficult to answer if you were only copying code.

On the other side, there are people who completely ignore AI. They don’t use it at all, don’t know how to write prompts, and don’t take advantage of it.

This is also a mistake.

Today, companies expect engineers to know how to use AI to speed up their work, whether it’s debugging, generating ideas, or improving solutions.

“AI should support your thinking, not replace it.”

So the goal is balance. Use AI as a tool to help you, but make sure you understand what you are building.

So …

These are the mistakes I keep seeing again and again from people who feel stuck and struggle to get hired.

The good part is, none of them are permanent. You can fix all of them.

You don’t need more tools, and you don’t need more random courses.

You need to focus, go deeper, and actually understand what you are building.

If you fix these things, you’ll already be ahead of many others.

“Getting hired is not about doing more, it’s about doing the right things well.”

And if you’re currently searching for a job, I really hope you land one soon.

You’re probably closer than you think.

The first video is already out, and many more are coming.

Much love,
— Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

I just published the first video in a new series where I’ll be sharing everything I know about Databricks!! 🎉

For the past 5 years, I’ve been building data projects almost entirely on one platform: Databricks. And honestly, it worked like magic.

So now I want to share everything I’ve learned from those years of building real projects.

But if you know my style, you know I don’t like jumping straight into a tool or platform… I like to start with the foundations.

The big questions: What is it? Why does it exist? Who is it actually for?

The interesting thing is that this platform is not only for data engineers anymore.

Today it’s used by data analysts, data scientists, ML engineers, and even AI engineers.

let’s start with the story.

The Single Machine Era

In the beginning, everything ran on a single machine.

Companies stored their data on one server and analysts or engineers ran SQL queries or Python scripts to analyze it. For small datasets this worked perfectly. The machine had enough CPU, memory, and storage to process everything.

But as companies digitized more of their business, data volumes exploded. Websites started generating event logs. Applications produced telemetry. Businesses began storing historical records for years.

Suddenly data grew from gigabytes to terabytes.

One machine was no longer enough. Queries took hours. Systems crashed under heavy workloads. And if that single machine failed, the entire analytics process stopped.

One computer works for small data, but it collapses when data becomes massive.

The Hadoop Era

To solve this scaling problem, Hadoop introduced distributed computing.

Instead of relying on one powerful computer, Hadoop used many smaller machines working together in a cluster. Data was split across those machines, and each machine processed its piece in parallel.

This approach allowed companies to process massive datasets that were impossible to handle before.

But Hadoop had a big drawback.

Every computation required reading data from disk, processing it, and writing it back to disk again.

Disk operations are slow compared to memory. As datasets grew larger, Hadoop jobs could take hours or even days to complete.

Hadoop solved the scaling problem, but processing data from disk made everything slow.

The Spark Era

Spark was created to solve the speed problem.

It kept the distributed system idea from Hadoop but changed how computations happened.

Instead of constantly reading and writing to disk, Spark processed data in memory whenever possible.

Memory operations are dramatically faster than disk operations. This made Spark many times faster for most workloads.

Companies quickly adopted Spark as the new standard for big data processing.

But there was another issue.

Early Spark development required knowledge of Scala or Java, which limited who could use it. Most analysts and data scientists were not comfortable with those languages.

Spark made big data fast, but it was still difficult for many data professionals to use.

The PySpark Era

At the same time, Python was becoming the dominant language for data science.

Libraries like Pandas, NumPy, and Scikit-learn made Python extremely popular for data analysis and machine learning.

To connect these worlds, PySpark was introduced.

PySpark allowed developers to write Spark programs using Python while still benefiting from distributed computing.

This opened big data processing to a much larger audience.

However, running Spark at scale was still complicated. Engineers had to configure clusters, manage resources, monitor failures, and handle infrastructure issues.

Before even writing data pipelines, teams often spent weeks setting up the environment.

PySpark made big data accessible, but managing the infrastructure remained painful.

Databricks as a Big Data (Managed Spark) Tool

To remove this operational burden, the creators of Spark founded Databricks.

The idea was to provide Spark as a fully managed platform.

Instead of configuring clusters manually, teams could run workloads on a platform where infrastructure, scaling, and environment setup were handled automatically.

This allowed engineers and analysts to focus on building data pipelines, running analysis, and developing models.

But a new problem appeared.

Because storage became cheap and easy, companies began dumping huge amounts of raw data into data lakes.

Over time, many of these lakes became messy. Schemas changed, data quality dropped, and teams lost trust in the datasets.

People started calling them data swamps.

Managed platforms simplified infrastructure, but uncontrolled data lakes created chaos.

Databricks as Data Platform ( Data Lakehouse & SQL)

To fix the chaos of data lakes, Databricks introduced the Lakehouse architecture.

The goal was to combine the best parts of two worlds:

Data lakes for scalability and flexibility.
Data warehouses for reliability and structured analytics.

Using technologies like Delta Lake, data lakes gained important capabilities such as transactions, schema enforcement, and versioning.

At the same time, Databricks introduced powerful SQL capabilities, allowing analysts to query the same data layer using familiar tools.

This meant engineers, analysts, and data scientists could all collaborate on the same platform and the same data.

However, as organizations grew larger, another challenge emerged. Data governance.

The Lakehouse unified the data stack, but large organizations needed strong governance.

The Unity Catalog Era

In enterprise environments, managing data access is critical.

Companies must control who can see which datasets, track how data flows across systems, and ensure compliance with regulations.

Without governance, data platforms quickly become risky and unmanageable.

To address this, Databricks introduced Unity Catalog.

Unity Catalog centralizes governance across the platform. It manages catalogs, schemas, tables, permissions, and lineage in one place.

This allows organizations to maintain security, transparency, and compliance while still enabling collaboration.

As data platforms scale across organizations, governance becomes essential.

Databricks as Data & AI platform

The industry is now shifting again, this time because of AI.

Companies want to build intelligent systems using their data. But in many organizations a new problem appeared.

The data lived in the data platform, while AI engineers were building systems somewhere else.

To create AI applications, teams had to build separate infrastructure for model training, LLM integration, and deployment. This created another fragmented architecture.

To solve this, Databricks extended the platform with Mosaic AI.

Mosaic AI allows teams to build, train, and deploy AI systems directly inside the platform, using the same data and infrastructure.

This means data pipelines, analytics, machine learning, and AI applications can now live in one place.

Databricks evolved once again.

Not just into a data platform, but into a Data + AI platform.

The future of data platforms is bringing AI development directly where the data lives.

So …

If we step back and look at this entire journey, we can see something interesting.

Every generation of technology solved one major problem.

• Single machines worked for small datasets.

• Hadoop made it possible to scale to massive data.

• Spark made big data processing fast.

• PySpark opened the door for Python users.

• Databricks removed the complexity of managing infrastructure.

• The Lakehouse unified data lakes and data warehouses.

• Unity Catalog introduced governance for enterprise environments.

• And today the platform continues evolving into a Data + AI platform.

Databricks is a unified platform where data engineering, analytics, machine learning, and AI development happen in one place.

If you want to understand how modern data platforms actually work, join me on YouTube. I’ll be sharing much more content like this in the coming weeks.

The first video is already out, and many more are coming.

Much love,
— Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

The waiting is finally over. I’ve waited more than a year to write these words… and today is the day.

🎉 My full 13-hour Python course, taking you from absolute beginner to confident Python developer, is officially LIVE! 🎉

Let’s go.

Why You Should Learn Python in 2026?

Look around at what is shaping technology today.

AI assistants. Data platforms. Smart automation. Cloud systems.
Behind almost all of it, there is Python.

It has quietly become the language that powers modern innovation.

If you want to step into AI, data engineering, analytics, backend development, or simply become more efficient in your current job, Python opens that door. It connects tools, systems, and ideas together.

And if you are new to coding, you might think this world is not for you. But here is the truth: Python was designed to be readable, logical, and approachable. You do not need a computer science degree to start. You just need curiosity and consistency.

For data analysts especially, Python is a game changer. It transforms you from someone who works inside tools… to someone who can build solutions beyond them.

Python is not just a skill. It is a language of leverage.

Quick Guide to Content

1️⃣ Free The Core Content

👉 Watch on YouTube
The complete 13-hour Python course, available for free:

• All lessons and chapters

• All built-in challenges

2️⃣ The Handbook & Code Bundle

👉 Get the Handbook
A structured reference system that supports the full course:

• Complete Python Handbook (PDF)

• All sketches organized with clean notes

• Best practices & real industry insights

• Structured Python source code and solutions for all challenges & projects.

3️⃣ Data Academy: The Full Package

👉 Enroll in the Full Program
A guided learning platform that includes everything in one structured system:

• Structured curriculum with progress tracking

• Python Handbook PDF & Codes

• Quizzes & Exercises

• 3 real-world Python Projects

• Certificate of completion

• Lifetime access & future updates

If you are a student with financial limitations and want access to the full program with certificate, comment “Python” under my LinkedIn post and I will send you Free Access Link (Limited for 100 Enrollments)

A Year in the Making

For more than a year, I worked on this course during weekends, late nights, and early mornings next to my full time job. It was not rushed. It was built slowly and intentionally, with one clear goal in mind

.

Not just to teach Python, but to help you think in Python.

I didn’t want this to be just another screen recording where you watch someone type for hours and try to keep up. That kind of learning feels productive in the moment, but a week later most of it fades.

If you know me, you know that’s not my style.

I wanted you to understand what really happens behind the scenes. What a variable actually is. How memory works. Why a loop behaves the way it does. What truly happens when you call a function.

That is why I hand drew every single visual myself on my iPad using Procreate. Every diagram, every flow, every explanation was created manually. I broke down each concept into simple visual animations, because when you can see the logic, it becomes clear.

And once you see it clearly, you do not just write code. You write it with confidence and understanding.

What’s Inside the Course?

Link to Mindmap

1️⃣ Python Foundations

• What Python is and how it works
• Installation and setup
• Comments and output
• Variables and user input
• Core data types

2️⃣ Working with Strings

• String fundamentals and transformations
• Indexing and slicing
• Searching, validation, and formatting

3️⃣ Working with Numbers

• Integers and floats
• Mathematical operations
• Rounding, randomness, and validation

4️⃣ Logic and Operators

• Boolean values
• Comparison and logical operators
• Membership and identity

5️⃣ Conditional Statements

• If, elif, else
• Nested conditions
• Inline if and match case

6️⃣ Loops

• For loops
• While loops
• Break, continue, pass
• Nested loops and for-else

7️⃣ Data Structures

• Lists with deep dive into tools.
• Tuples
• Sets
• Dictionaries

8️⃣ Functions

• Writing and structuring functions
• Parameters and return values
• Different types of functions
• Clean and reusable design

❤️ If You Appreciate It, Help Me Spread It

This course is free. No ads. No sponsors. Just me, sharing my knowledge
So if you find it helpful, please consider helping me spread the word:

👍 Like
💬 Comment
📢 Share with friends
📩 Send it to that one person who needs to learn Python
📺 Subscribe on YouTube

It helps the YouTube algorithm show this content to other amazing learners like you.

Thanks for being part of this journey.
Now go dive in and explore Python like never before.
Let’s make learning fun again 🚀

Much love,
— Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

Over the years, life taught me lessons the hard way about time, work, money, relationships, and myself. This post is not advice or a formula to follow. These are simply the rules I live by today, shaped by experience and mistakes.

Take what resonates with you. Leave the rest.

Rule 01 – Everything Takes Time

Nothing real grows fast:

• Your body changes slowly
• Your skills compound slowly
• Your money grows slowly

Modern life sells speed. Fast results. Instant change. Those shortcuts always charge interest later.

Time will pass anyway. Build things that last.

“The long path is the real shortcut.”

Rule 02 – It Is Never Too Late

Being “too late” is usually just fear in disguise.

I’ve seen capable people stop themselves because they compare timelines and assume they missed their chance. Time doesn’t care. It keeps moving whether you act or not.

Every meaningful thing in my life started later than I thought it should. Starting anyway changed everything.

It is never too late. Time will move forward with or without you.

Rule 03 – Don’t Talk About Your Plans

Talking creates a fake sense of progress.

When you explain your plans in detail, your brain feels rewarded before the work is done. Encouragement replaces execution. Energy leaks into words instead of action.

Share direction if you must. Keep details to yourself. Work quietly.

“Execute first, Show results later, Celebrate after!”

Rule 04 – Don’t Compare Yourself With Others

Comparison never tells the full story.

Everyone starts from a different place. Different backgrounds, support, timing, and luck. Timelines are not comparable.

You only see the wins. You don’t see the sacrifices, the struggles, or the failures behind them. That’s why copying someone else’s path never works.

“Run your own race. Comparison leads nowhere”

Rule 05 – My Life. My Rules

Everyone has an opinion about how you should live. Family. Culture. Social media. The system.

If you let those voices decide for you, you slowly lose control.

I listen to advice. I think about it. But I keep the final decision. This is my life, and I live with the consequences.

“Live your own life, or you will end up living someone else’s.”

Rule 06 – Take Ownership of Your Life

Blame feels comforting, but it keeps you powerless.

Life is unfair. Complaining and blaming only focus your energy on what you can’t control.

Change the question. Stop asking “Why is this happening to me?” and start asking
“What can I do about it?” There is almost always something.

Ownership gives you control back.

“Take ownership, or stay stuck.”

Rule 07 – Be Careful What You Consume

Most content is designed to trigger you.

Fear. Urgency. Anxiety. Different platforms, same game. Click now. You’re late. You’ll regret it.

News sells fear. Social media sells perfect lives. After a while, you start thinking something is wrong with you.

Nothing is wrong with you. Real life is quieter, slower, and more normal.

“Protect your mind. Most content is designed to trigger, not to help.”

Rule 08 – No One Is Coming to Save You

When life gets hard, it’s easy to wait. For help. For luck. For someone to fix things.

Support may come, but no one can fix your life for you. That responsibility never leaves your hands.

Waiting keeps you stuck. Showing up for yourself moves you forward.

“Only you can fix your life.”

Rule 09 – Protect Your Relationship

Your partner is often the longest relationship in your life.

• Parents grow older and leave us.

• Children grow up and move on.

• Friends get busy with work and family.

A relationship is not a competition. There is no winning an argument. If one person loses, both lose.

Protect it, especially when things get hard.

“Protect your relationship. It is the longest one you will ever have.”

Rule 10 – Forgive to Move On

This one is hard.

Forgive your parents. They are not perfect. They made mistakes, often without bad intentions. They come from a different generation, with different tools. You cannot change that anymore. Forgiveness frees your energy.

Stay in touch. Call them. A short call is enough. Time moves faster than you think, and one day you will wish you had more of it.

Forgive yourself too. You will make mistakes. Learn, adjust, and move forward.

“Forgiveness makes you lighter. Lighter people move faster.”

Rule 11 – Review & Redesign Your Habits

Once a year, I take time to redesign my life.

I sit down alone, without distractions, and draw a simple timeline with three versions of myself: my younger self, my current self, and my future self.

I ask:

• “What did I do well? What mistakes did I make?”

• “Who do I want to become next?”

To answer that, I use a simple framework with five columns:

• Keep – habits that already work
• Start – habits I want to add
• Stop – habits that hurt me
• More – good habits I want more of
• Less – things I need to reduce

“Small habit changes, reviewed regularly, shape a better version of you each year..”

Rule 12 – Daily 30-Minute Walks

Walking clears my mind better than anything else.

Almost every day, I walk for 30 minutes. No phone. No music. No podcasts. Just walking.

Big decisions become smaller when you walk. Problems simplify. Sleep improves. Clarity follows.

It costs nothing, but over time, it changes everything.

“It costs nothing! Walk daily. Clarity follows.”

Rule 13 – Divide Your Day Based on Energy

I don’t manage my time. I manage my energy.

I split my day into three phases.

• Mornings are for deep work. This is when my energy is highest. Writing, planning, solving hard problems. I protect this time.

• Midday is for communication. Meetings, emails, conversations. Useful work, but not deep work.

• Evenings are for life. Family, movement, rest. No big decisions. No hard problems.

I am not productive all day, and that’s fine. I am productive when it matters.

“Understand your energy, then plan your day around it.”

Rule 14 – Three Levels of Learning

Learning something new happens in three levels.

I split my day into three phases.

Level 1: Consuming
You watch videos, read books, listen to podcasts. You understand the idea, but watching someone else do something does not mean you can do it. This level only opens the door.

Level 2: Practicing
This is where learning becomes real. You try, you get stuck, you make mistakes, and you move slowly. The struggle is not a problem. It is how knowledge is built in your brain.

Level 3: Teaching
This is the hidden level. When you explain something to others, you discover what you don’t fully understand. Teaching forces clarity, structure, and fills the gaps.

“You don’t really learn until you practice, and you don’t fully understand until you teach.”

Rule 15 – Learn Financial Literacy

I never understood why the most important life skill, how money works, is not taught in school.

Financial literacy is not about getting rich fast. It is about avoiding expensive mistakes and protecting yourself. Without it, decisions are based on guessing and trends, and that usually ends in loss.

A few simple rules I follow:

• Live below your means

• If you can’t explain where your money goes, you’re not in control

• Always keep an emergency buffer

• Don’t rely on one income source

• Get-rich-fast is a scam

• Don’t try to time the market

“Learn how money works before money teaches you the hard way.”

Rule 16 – Stability First, Freedom Later

This is the money model that worked for me.

Step 1: Get a stable job.
Nothing fancy. Work, get paid. This phase gives stability and a strong base.

Step 2: Invest what’s left.
Even a small amount. Over time, money and time work quietly in the background.

Most people stop here, and that’s okay. But you still depend on one job.

Step 3: Build side projects.
Something you enjoy. Something that takes time. It may fail, and that’s fine. You gain skills. Or it grows and creates freedom. That’s what happened to me.

“Stability first. Freedom later. No shortcuts.”

Rule 17 – Play the Long Game

I invest simply and consistently.

No daily tracking. No news watching. No stress. I invest regularly and leave it alone.

Yes, some people got rich fast with things like Bitcoin. Many more lost money just as fast, and those stories rarely make it to the media. That’s not my style.

I don’t chase luck. I build slowly.

“Simple, consistent, and long-term beats stress and guessing.”

Rule 18 – Complaining Is a Career Killer

Every job has problems. That’s normal. The mistake is dealing with them by constantly complaining.

Repeated complaining drains the energy of motivated people and adds weight to those who are already struggling. Over time, you get labeled as negative, people avoid you, and you slowly damage the team culture.

There are only three healthy ways to deal with problems at work:

• Ignore it if it’s out of your control
• Fix it by bringing a solution, not just a complaint
• Leave if it truly matters and nothing changes

“Fix it, ignore it, or leave. Complaining kills careers..”

Rule 19 – Know When to Stay and When to Leave

If your ideas are always ignored and nothing changes, it’s time to leave.

I don’t leave just because work gets hard. Pressure and disagreements exist everywhere. But I never stay where there is no respect. Once an environment becomes toxic, that is a clear signal.

The other danger is staying too long. Comfort can stop growth. When learning stops, risk starts.

My rules:
• Don’t leave because it’s hard
• Don’t stay without respect
• Don’t stay too long without learning

Rule 20 – Don’t Burn Out. Don’t Check Out

At work, I’ve seen two extremes:

The Burnout Trap
Long hours. No rest. No life outside work. Health and relationships get sacrificed with the hope that the job will take care of you. Most of the time, it doesn’t.

The Checked-Out Trap
Doing the bare minimum. Avoiding responsibility. Waiting for the day to end. Work already takes part of your life. Hiding from it gives nothing back.

Both extremes lead to the same place.

“Give your best without burning out. Stay engaged without losing your life.”

Rule 21 – Colleagues Are Not Friends

People at work can be friendly, but work is still work. When you forget that, you overshare, and it often comes back to hurt you.

“Be kind. Be respectful. Be professional.”

Rule 22 – Communicate Your Work

I’ve seen many great people do great work that no one knows about. Not because it isn’t valuable, but because no one is tracking it.

People are busy. If you stay silent, your value stays invisible.

If you’ve built something useful, share it. Write about it. Present it to your team. Talk about it. This is not bragging. Someone out there needs what you built and doesn’t know it exists.

Clear communication helps others, and it helps you. Your work gets recognized, your impact becomes visible, and opportunities follow.

“Good work unseen is good work wasted.”

So my friends,

These are the rules I live by today. I’m somewhere in the middle of my life, and I know I’ll still make mistakes. But I’m committed to learning from them.

If I had to reduce everything to a few foundations, it would be this:

• I play the long game. I don’t rush.

• I don’t take things personally, because most things aren’t about me.

• I don’t live my life based on other people’s expectations.

• I never lose sight of what matters most.

• My health. My family. Everything else comes after.

You don’t have to follow my rules. We all walk different paths and face different realities. Take what resonates with you. Leave the rest.

If this helped you pause, reflect, or adjust even one small thing, then it served its purpose. I wish you peace, clarity, and a life you’re proud to look back on.

Have a wonderful day ❤️
Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

I just wanted to take a moment to say thank you for being a member and for supporting my work. It truly means a lot to me.

Your support, messages, and encouragement mean more than you know. This newsletter started as a simple way to share knowledge, and now it has become a community of motivated people who genuinely want to grow in dat…

Read more

You’re invited to join our 𝗗𝗮𝘁𝗮 𝗟𝗶𝘃𝗲 𝗦𝘁𝗿𝗲𝗮𝗺 𝘄𝗶𝘁𝗵 𝗺𝗲 & 𝗦𝗶𝗺𝗼𝗻!

We worked together for over three years on a real enterprise data project at Mercedes-Benz.

I’ve noticed that many real experts are actually hidden! Most of them simply don’t have the time to be active on social media or share their knowledge publicly.
That’s exactly why I want to bring these gems into the spotlight!

We’re having an open, relaxed conversation about real data projects, and lessons learned.
Join us live and drop your questions in the chat. We’ll answer as many as we can.

See you there 👋

Have a wonderful day ❤️
Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now

I was looking at a bunch of “data analyst roadmaps” the other day, and I noticed something. Most of them are super tool-based. They basically say: learn SQL, Excel, Power BI, Python… and that’s it.

But tools are only one piece of the job. The bigger skill is learning how to think like an analyst: how to break down messy questions, understand the business, and turn data into decisions.

So I built my own roadmap. I’ll take you slowly through every phase, starting from total beginner, all the way to getting hired, then what to focus on after you get the job, and how to grow into senior and lead roles.

This roadmap is based on my 17 years working in real data teams, and what companies actually expect in the market today.

Here are the resources 👇

• I explained the full roadmap step by step in this video → LINK

• And I shared the Notion template with all phases, resources, and a clear step by step guide → LINK

#1 The Hiring Journey

This journey is about building the right skills to get you ready for your first data analyst role.

Phase 0 - Absolute Beginner 🧭

This phase is about understanding what data analytics really is and deciding whether this career is right for you.

🎯 Mindset: Mindset: Is data analytics the right career for me?

Just spend like few days reading watching about it and make then decision

• Understand the Role: You clearly understand what a data analyst actually does before investing time and effort.

• Check 10 Job Posting: Scan job postings to see what companies actually ask for and to align your learning with the market.

• Make Decision: Decide if data engineering is the right long-term career for you.

Remember: Ask yourself: “Would I enjoy this work every week?” Be honest with yourself. This phase saves you years later.

Phase 1 - Core Technical Skills 🌱

This phase is about getting you ready by focusing on core skills one by one, so working with data and code starts to feel natural before you even think about data engineering.

🎯 Mindset: I can work with Data

How to Learn: Learn Theory, Basics and Deep dive into Advanced Topics, Do Projects

• Data & Analytics Terminology: Learn core terms like metrics, KPIs, BI, and data quality.

• SQL: Explore, clean, and join data to answer real business questions.

• EDA Project: Analyze a real dataset to find patterns, trends, and issues.

• Power BI / Tableau: Build dashboards that clearly communicate insights.

• Dashboard Project: Create an end-to-end dashboard using real data to show your skills.

Remember: Practice more than you consume content

• Learn one skill at a time

• Focus on understanding, not memorizing, Always ask “why” before “how”

• Use AI only to explain concepts, not to write code for you

Phase 2 - Data Analytics Skills 🧠

This phase is about how analysts think, not which tools they use. You move beyond writing queries and dashboards and start focusing on reasoning, interpretation, and decision-making.

🎯 Mindset: I can think like an analyst!

How to Learn: Just read about it no need to deep dive

• Statistics: Understand distributions, variability, and relationships. Focus on meaning, not formulas.

• Communication (Storytelling): Turn analysis into clear insights non-technical people understand.

• Analytical Thinking and Problem Solving: Break vague questions into measurable problems and challenge assumptions.

• Data Modeling and Metrics Design: Build meaningful metrics that reflect real business logic, not vanity numbers.

Remember: Clear thinking beats fancy dashboards

• Your main task is to answer business questions, not only to write queries or build charts

• You work with non-technical people, so clarity matters more than complexity

• Numbers are useless without context, assumptions, and impact

Phase 3 - Stand Out Go Beyond the Basics 🧳

This phase is about differentiation, not requirements. You already have what you need to get hired. These skills help you stand out, work faster, and handle more complex data, but they are not required for a data analyst role.

🎯 Mindset: I add extra value without losing sight of the core role.

How to Learn it: Learn the core concepts first, then practice only the basics. Avoid deep dives. Depth comes later on the job.

🛑Important Note: These are large topics. Do not get lost in tools or delay job applications. This phase is optional and exists only to help you stand out, not to block your progress.

• Python (Pandas, Numpy, Plotly): Use Python to explore data and automate repetitive work.

• Databricks For Data Analytics: Learn how analysts explore large datasets on modern platforms.

• AI Prompt Engineering: Use AI to speed up analysis, SQL, and documentation.

• AI Models (High-Level): Understand what AI models do, their limits, and how analysts use them.

Phase 4 - Prepare & Get Hired 💼

At this point, you won’t know 100% of data engineering, and that’s completely normal. The good news is you already have around 70% of the skills needed to start applying. There’s no reason to wait anymore. Now it’s time to prepare yourself, put your profile together, and start applying for jobs.

🎯 Mindset: I am ready to enter the market!

• Get Certified: Validate skills with relevant certifications. You increase trust and visibility in the market.

• Build Clean Resume: Present skills and projects clearly. Recruiters quickly understand your value.

• Optimize LinkedIn Profile: Make your profile searchable and attractive. Recruiters can find and contact you.

• Build Portfolio: Showcase real projects publicly. You stand out beyond certificates and courses.

• Start Applying for Jobs: Apply consistently and interview actively. You gain interview experience and land offers.

• Improve & Learn: Fix gaps while applying and interviewing. You continuously improve until you get hired.

Remember: You don’t need 100% to start applying.

• Apply before you feel fully ready

• Rejections are part of the process

• Treat interviews as learning sessions

• Focus on explaining, not impressing

• Keep improving while applying

• Do not compare yourself to seniors

End of The Hiring Journey🎉

If you got a job, congratulations. I’m really proud of you and happy for you.

From here, I’ll guide you on how to grow as a data analyst and build real experience on the job.

If you’re still searching, don’t worry. You will get one. Just keep pushing.

In the meantime, you can already start looking at the next skills, and if you have time, pick a few to strengthen your profile while you keep applying.

#2 The Growth Journey

This journey is about what happens after you get hired: learning on the job, making mistakes, and growing into a strong data analyst.

Phase 5 - Junior Data Analyst 🧑‍💻

At this stage, you are officially working as a data analyst, but you will not know everything and that is completely normal. Most of your real learning happens on the job. You will ask questions, make mistakes, fix them, and slowly start connecting the dots.

🎯 Mindset: I am learning by doing

• Understand the business and stakeholders: Understand how the company makes money and who uses your work.

• Explore and Understand Data (EDA): Explore data, ask questions, and build intuition.

• Build Domain Knowledge: Learn the business domain to add context to your analysis

• Maintain and Improve Existing Reports: Maintain existing reports and improve clarity and metrics.

Remember: Making mistakes is part of the job.

• Ask questions early

• Focus on reliability over clever solutions

• Quality is always better than speed

• Learn company data and business context

• Take feedback seriously, not personally

Phase 6 - Senior/Lead Data Analyst 🧠

At this stage, you are no longer just executing tasks. You are trusted with complex business problems, ambiguous questions, and high-impact decisions. You influence stakeholders, shape metrics, and guide others.

A senior or lead data analyst focuses less on producing reports and more on driving clarity, alignment, and decisions across the business.

🎯 Mindset: I take ownership of complex problems and help others see the full picture.

• Mentor Juniors: Review work, give clear feedback, and help juniors improve their thinking.

• Impact Thinking: Move from “what was asked” to “what really matters.” Prioritize work based on impact, not volume.

• Improve data quality and governance: Ensure trusted, consistent metrics across teams.

• Advanced Data Modeling: Build scalable metrics for long-term decisions.

• System-Level Analytics Architecture: Understand how data flows across analytics systems.

Remember: Delegate simple tasks and focus on complex, high-impact problems.

• Let juniors handle repetitive analysis and reporting

• Own the hardest business questions

• Review work to raise the overall analytics quality

• Balance insight quality, speed, and trust

• Help stakeholders make better decisions, not just faster ones

So my friends,

You can start this path with no degree and no prior experience. I have seen it happen many times. The roadmap is simple. Learn the core skills, build real projects, create proof of your work, and keep improving while you apply. It takes time and patience, but it works.

If you want a clear structure to follow, you can use the full Notion Data Engineering Roadmap here → LINK
It includes all phases, resources, and guidance to help you move step by step.

Thank you for taking the time to read this. I hope it brought you clarity and helped you feel more confident about your next move.

Have a wonderful day ❤️
Baraa

Also, here are 4 complete roadmap videos if you’re figuring out where to start:

📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap

Hey friends —

Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.

Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.

Visit My Youtube Channel

Subscribe now