DEV Community: Franciele Stefani da Costa

Code is the execution. Thinking is the strategy.

Franciele Stefani da Costa — Tue, 10 Feb 2026 19:08:40 +0000

💡 The Smart Student’s Epiphany

Recently, while studying, I realized something that completely changed the way I look at SQL.

In one class, I watched the instructor building complex queries and thought:

“He doesn’t start with SQL… he starts with THINKING.”

And that’s when it clicked.

We spend a lot of time learning syntax, but we almost never learn how to think before coding.

And that makes all the difference.

🎯 The problem: why do we freeze?

If you study SQL, you’ve probably been here:

You receive a complex problem
You open the SQL editor
You type SELECT * FROM...
Freeze. “Now what?”
You start trying some JOINs
You get confused
You feel frustrated
You end up on Stack Overflow

Result: messy code, wrong results, and wasted time.

For a long time, I thought this was:

lack of practice
or lack of technical knowledge

But it wasn’t.

The problem was before SQL.

👉 In the next post, I’ll share the analogy that finally organized this way of thinking —

and why jumping straight into code is often exactly what slows us down the most.

#ThinkBeforeYouCode #SQL #RealLearning #DataEngineering #Data

🚀 How I Learned That Thinking “Small” Can Save Hours of SQL Headaches

Franciele Stefani da Costa — Tue, 30 Sep 2025 19:16:44 +0000

The day I realized building a query is like playing with Lego

Professors always said: “build and test, build and test.”

And I thought I was already doing that. But honestly, I wasn’t.

My mindset was linear: I wanted to write the entire query at once, hit run, and only then check if it worked.

Guess what? It usually didn’t. 😅

Then one day I watched a video from Ankit Bansal (SQL expert), and that’s when it clicked. 💥

It’s not about going slow—it’s about changing the way of thinking.

👉 Instead of finishing everything and testing later, it’s way better to enjoy the process: build step by step and debug along the way.

And here’s how he did it:

He started with something simple:

WHERE department_id NOT IN (SELECT dep_id FROM dept);

Then, he expanded it with a LEFT JOIN:

LEFT JOIN dept
ON emp.department_id = dept.dep_id;

Next, he pulled in the full data:

SELECT emp.*, dept.dep_name FROM emp;

Finally, he filtered just what he needed:

WHERE dept.dep_name IS NULL;

So instead of trying to write everything in one go, he validated each block until the solution was crystal clear.

💡 What I Learned

This style has a fancy name: incremental thinking.

But for me, it simply means: “don’t lose your mind.”

Fewer mistakes: you test each piece before moving on.
Easier debugging: when something breaks, you know exactly where.
Lighter brain load: it’s easier to reason in smaller chunks.
Real learning: you understand the journey, not just the final query.

And since my dream is to become a Data Engineer, I can see how this mindset will be essential.

Data engineering is all about dealing with complex systems, huge datasets, and tricky transformations — and there’s no way to survive without building things step by step.

🎯 How to Train This Mindset

If you also tend to write giant queries all at once, here’s a better way to practice:

-- Step 1: look at all the data
SELECT * FROM table;

-- Step 2: add filters
SELECT * FROM table WHERE condition;

-- Step 3: join tables
SELECT * FROM table1
LEFT JOIN table2 ON condition;

-- Step 4: refine with window functions, groupings, etc.

The idea is: build and test each step.

Don’t try to be “Neo from the Matrix” writing a massive query and only checking if it works at the end.

🎤 Conclusion

I used to think “build and test” meant slowing down.

But now I see it’s the opposite: it’s actually faster, because you make fewer mistakes.

Now, whenever I write a query, I remind myself:

“Take it easy, Fran. Build the Lego one piece at a time.” 🧩

And who knows — one day, as a Data Engineer, I’ll look back and thank myself for training this mindset early on.

How about you? Do you still try to write it all at once, or have you embraced the incremental path? I’d love to hear your experience! 😅

✍️ If you enjoyed this post, drop a comment, share it, and follow me here — I’m sharing my journey as a junior dev on the path to becoming a Data Engineer. 🚀

Going Back to a Previous Commit: How I Turned a Simple Git Reset Into a Horror Show (and What I Learned)

Franciele Stefani da Costa — Wed, 13 Aug 2025 14:00:48 +0000

The day I almost deleted my dignity along with my code

You know that day when you think: “This will be quick, just install Husky, configure commitlint, and done”?

Yeah… it was supposed to be that simple.

The request was easy: install Husky (pre-commit, pre-push, and commit-msg) and commitlint. I installed everything, set it up nicely… but, being a beginner, I had to make a few test commits to see if it was working.

Result? The commit history ended up messier than a drawer full of random cables that nobody knows what they’re for.

Then came the new mission:

"Franciele, we need to clean up the commit history."

And I thought: “Piece of cake, I saw this on Google.”

The fatal mistake

I went straight to a git reset… and friend, that was the beginning of the tragedy.

The command I chose deleted all the changes on my local machine.

And no, of course, I didn’t have a backup. Who hasn’t, right? (Seriously, always have one.)

In desperation, I dug around and discovered that, luckily, the original branch with the correct code was still intact. I breathed, cloned it, and this time, I actually researched before typing commands like I was some hacker in The Matrix.

What I learned about resetting commits

There are three main ways to use git reset, and each one can completely change your day (or ruin it):

git reset --hard <commit>

Returns your project to the state of that commit and deletes all uncommitted changes.

Perfect for losing code with no backup, not recommended.
git reset --soft <commit>

Moves the HEAD to that commit but keeps your changes staged. Your code is safe, only the history goes back in time.
git reset --mixed <commit> (default)

Like soft, but keeps the changes unstaged. You need to git add them again.

My problem and the solution

What I wanted:

Remove only the test commits.
Keep my current code intact.
Make a new, clean commit with a proper message.

Step by step:

Check which branch I was on:

git branch

Make sure I’m on the correct branch:

git checkout branch_name

See the commits:

git log

Copy the commit number before the test commits and go back to it using soft reset:

git reset --soft commit_number

Make the new commit:

git commit -m "chore: configure husky, lint-staged and commitlint properly"

Force push:

git push origin your-branch -f

The most valuable lesson
In the end, I realized that daily backups are your best friend.
Create a private GitHub repository and push your project at the end of each day.
Don’t trust that your computer will last forever or that you’ll remember every command.

Because losing a bit of code hurts, but losing everything because you didn’t back up…
It’s like spilling coffee on your keyboard and thinking you can dry it with a hairdryer: it’s gonna go badly.

And you? Have you ever made a “small disaster” in Git? Share it with me so I can learn from your mistakes too. 😅