It was a map of Spain. Every block, 0.1% of the population.

The follower count moved too. From the outside, it looked like something had happened.

118,712 impressions. 124 new followers.

I sat with those two numbers for a while.

…

Read more

Feeling behind? You’re not.
Today’s issue compresses the essentials (what matters, what doesn’t) into a buildable path.

Minimal theory, maximum leverage.

Following my Transformers cheat sheets (architecture, encoder, decoder), today we go end-to-end:

1. What to learn

2. What to build first

3. How to avoid the rabbit holes.

⚠️

Read more

Almost every reply picked out the same word.

Is SQL still worth learning in 2026?

I get where the question comes from. SQL is what you learn in week two of a bootcamp. No release cycle, no conference, no version number anyone argues about. It looks finished.

So p…

Read more

She could build an end-to-end scikit-learn Pipeline in her sleep.

Six months into her first job, she’d used it exactly once.

“I feel like I forgot everything.”

She hadn’t forgotten anything. The stack just changed the moment she stopped interviewing.

The Python libraries you learn for intervie…

Read more

Today we go one layer up. Not stitching tables together, but organizing the whole query so it reads like structured code instead of a wall of nested logic.

Here’s this week’s cheatsheet 👇🏻

Ever inherited a SQL query from someone who left three months ago?

Nothing lines up. The same metric is calculated three different…

Read more

I have a bunch of projects on GitHub. Is that my portfolio?

Short answer: no.

A GitHub is a repository. A portfolio is a story.

Two different objects. Two different audiences. Two different jobs.

GitHub is for the person who wants to read your code. That’s a tiny audience. Usually another engineer. Usually al…

Read more

Today we go one layer deeper: the joins themselves.

Merging tables is where SQL gets real. And where most people get stuck.

LEFT, RIGHT, INNER, FULL.

Which one when?

What happens to unmatched rows?

Here’s the full cheatsheet 👇🏻

The Magic of SQL Joins

In the world of databases, data often resides in sepa…

Read more

Eight weeks ago, I hit publish on the first post of the databites reset.

I didn’t know if anyone would read it.
I didn’t know if I’d keep going.
I didn’t know if the format would hold up.

Eight Tuesdays later, we’re still here.

You opened the emails. You replied. You clicked. You stayed.

That means more than you probably realise. Eight weeks was the priva…

Read more

In this issue, we’ll break down the essentials of using APIs for data…

Read more

Not writer’s block. Something worse.

The feeling that whatever I wrote wouldn’t be worth anyone’s time.

I published anyway. You’re reading it now.

That’s what seven weeks of showing up actually looks like from the inside. Not a streak. Not momentum. A decision you make again every week, usually under so…

Read more

Transformers.

Here’s what’s coming your way:

✅ Week 1: Understanding the Transformers architecture → Link
✅ Week 2: The Encoder → Link
✅ Week 3: The Decoder → Link

Subscribe now

Understanding the Decoder - Part III

The decoder’s primary role …

Read more

My instinct was to separate everything cleanly. One client on Monday and Tuesday. Another on Wednesday and Thursday. Fridays for admin, proposals, the business side of things.

Three clients. Five days. Neat boxes.

It worked for about a month.

Then a client needed something on a Thursday. An…

Read more

Transformers

Here’s what’s coming your way:

✅ Week 1: Understanding the Transformers architecture → Link
✅ Week 2: The Encoder → Link
✅ Week 3: The Decoder → Link

Understanding the Encoder - Part II

The encoder is a fundamental component …

Read more

I had never taught at a university before.

No formal teaching experience. No academic track record.

Just the diagrams.

They’d seen the work, decided I understood something worth teaching, and reached out.

I said yes. Went all in. And it became one of the…

Read more

Transformers.

Here’s what’s coming your way:

✅ Week 1: Understanding the Transformers architecture
✅ Week 2: The Encoder → Link
✅ Week 3: The Decoder → Link

Subscribe now

The Transformers Architecture - Part I

With GPT-3.5 gaining 1 million users in a w…

Read more

Nobody asked about the model.

They asked: “What does this mean for us next quarter?”

I didn’t have that answer ready.

That’s not a modeling problem.

That’s a communication problem.

Most data education teaches you to build correctly.

Almost none of it teaches you to explain what you bui…

Read more

With one table, that’s easy to hold in your head. Add a JOIN, and one question trips up almost everyone: when you combine two tables and then filter them, what runs first?

The JOIN. It builds the combined table before any filter touches a row, and missing that is the source of most multi-table bugs.

So today we trace it step by step, on one real query.

The order, with a JOIN in it

FROM / JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT

JOINs don’t add a new step. They live inside step one. Everything after that runs on the joined result, not on your original tables.

The query

Two tables. employees has each person’s name and field. employee_company_data has their salary and experience.

The goal: find the field with the highest average salary, among employees with 5+ years of experience.

SELECT
      e.Field,
      AVG(ed.Salary) AS Avg_salary,
      COUNT(e.ID)    AS num_answers
FROM employees AS e
LEFT JOIN employee_company_data AS ed
  ON e.ID = ed.ID
WHERE ed.Experience_years > 5
GROUP BY e.Field
HAVING COUNT(e.ID) >= 5
ORDER BY Avg_salary DESC
LIMIT 1

Here's the order SQL actually runs it in.

#1 FROM - Defining the Base Table(s)

This is where SQL starts everything. It determines which table(s) we’re working with.

➡️ If we’re using JOINs, SQL processes them here before doing any filtering!

FROM employees AS e
LEFT JOIN employee_company_data AS ed
  ON e.ID = ed.ID

At this point, SQL combines the tables based on the JOIN condition. The type of JOIN (INNER, LEFT, RIGHT, FULL) affects which rows stay in the result set.

#2 WHERE - Filtering Rows

Now that we have a combined dataset, SQL filters individual rows before aggregation.

If you filter before the JOIN, you might accidentally remove rows you actually need.

WHERE ed.Experience_years > 5

#3 GROUP BY - Aggregating Data

Once SQL has the right rows, it groups similar data into categories.

This is especially useful when calculating averages, totals, or counts per category.

GROUP BY e.Field

#4 HAVING - Filtering Groups

HAVING is like WHERE’s big sibling, but for grouped data.

➡️ It filters after GROUP BY, meaning it only works with aggregated values.

HAVING COUNT(e.ID) >= 5

This keeps only fields with 5 employees or more, enough for the average to mean something.

#5 SELECT - Picking the Columns

Now SQL decides what to show in the final output.

You can only select columns that are in GROUP BY or are aggregated values.

SELECT
Field,
AVG(ed.Salary)  AS Avg_salary,
COUNT(e.ID)     AS num_answers

#6 ORDER BY - Sorting the Output

Now that we have our final dataset, SQL sorts the results based on our preferences.

ORDER BY Avg_salary DESC

This arranges fields from highest to lowest average salary.

#7 LIMIT - Keeping it Concise 🔢

If we only want to see a single result, we limit the number of rows returned.

LIMIT 1

And we land on the answer: Engineering, the field with the highest average salary.

Same query, a completely different order from the one on the page, with every step running on what the one before it produced. That is execution order in action.

Once you can picture that flow, the JOIN mistakes that trip most people up become easy to spot before they happen. Here are three.

Three mistakes this prevents

1. Filtering before you picture the join. A JOIN can add or drop rows. Build the combined table in your head first, then reason about WHERE.

2. Using WHERE for grouped data. Any condition on COUNT, SUM, or AVG belongs in HAVING. WHERE runs before the aggregate exists.

3. Selecting ungrouped columns. After GROUP BY, every column in SELECT must be in the GROUP BY or wrapped in an aggregate.

Build the joined table first, then filter, group, and filter the groups. Hold that order and multi-table queries stop surprising you.

Here's this week's cheatsheet 👇🏻

—Josep

Are you still here? 🧐

👉🏻 I want this newsletter to be useful, so please let me know your feedback!

Before you go, tap the 💚 button at the bottom of this email to show your support—it really helps and means a lot!

Any doubt? Let’s start a conversation! 👇🏻

Leave a comment

Want to get more of my content? 🙋🏻‍♂️

Reach me on:

• LinkedIn and X (Twitter) to get daily posts about Data Science.

• My Medium Blog to learn more about Data Science, Machine Learning, and AI.

• Just email me at rfeers@gmail.com for any inquiries or to ask for help! 🤓

Watched the videos. Did the math. Understood the intuition behind every update step.

Then I sat in front of a real dataset. Messy, incomplete, and half-documented.

I had no idea what to do first.

That’s the gap nobody talks about.

Learning data science is something you can measure.

Courses completed. Concep…

Read more

The one you wrote. And the one your database actually uses to run it.

That’s it. Strip away the syntax, and that’s what’s happening underneath: the clauses you typed top to bottom get quietly reshuffled into a completely different sequence before a single row is touched.

Most people learn to write SQL. Almost n…

Read more

A new research project.

A new side concept I never shipped.

A new approach to content I mapped out in a notebook and never opened again.

Each one felt like momentum. Each one was actually a reset.

This is what happens without a system: you don’t stop working.

You just keep star…

Read more