#065: 4 Reasons Why You Should STILL Lean SQL

SQL is still the most important skill to build as a data engineer, and it is the first one I recommend to anyone getting started. Four reasons: it is where most of your working day actually goes, it is the foundation every other data skill builds on, there is enormous demand for people who can clean up badly written queries, and it is embedded in old and new tools alike. It gets brushed off because it has been around forever and is not the exciting new technology. SQL on its own may not land you a job, but not knowing it will very likely disqualify you.

Why SQL keeps getting brushed off

When you are getting started in data engineering, it can feel like there are a million skills you need before you are credible. There is no shortage of lists and roadmaps, including my own.

Underneath all of them, I still believe an understanding of SQL is the most important thing you can have.

It gets taken for granted precisely because it works. It has been around forever, it is not the new and exciting technology, and there is no marketing budget behind generic SQL.

That is also why it stays undervalued, and why putting time into it is still one of the best returns available to you. If the broader anxiety about keeping up is what brought you here, I wrote about that in You Don't Need To Know Every Data Tool & Skill.

Reason 1: It is where your day actually goes

Interacting with SQL is where you will spend most of your day to day time, whether you are an engineer or an analyst. That is where the core job responsibility sits.

The work itself

Think about what the role actually consists of:

• Building a data warehouse
• Creating stored procedures
• Building data pipelines
• Writing data transformations

There are edge components around all of that, triggering things and writing automations, and those pull in other skills. But looking back across nearly a decade of my own career, most of it has been writing SQL in some capacity.

Data modeling runs through it

Data modeling is the topic everyone wants to learn, and reasonably so. It is also hard to implement a good data model in a database if you cannot write SQL.

The modeling concepts are only half of it. The other half is expressing them in queries that run.

Job descriptions versus the real day

We both know a lot of job descriptions are ridiculous now. They list a stack of tools and experiences that no single person uses in a week.

From experience, the real day to day requirement of most of those jobs is writing SQL. The rest of the list exists because somebody wanted to cover every possible scenario.

The conversations you will be in

It also shapes the technical conversations you have with your team. Following what is going on, writing it, and being able to talk about it are a large part of working with other engineers.

Reason 2: It is a foundational skill for your whole career

The second reason is that SQL is something you keep building on rather than something you pass through.

A lot of people treat it as a beginner level skill. Learn the basics, check the box, move on to the more exciting things. That is not how it plays out.

I look at it as a foundational pillar skill for your entire career. Everything else sits on top of it.

What happens when you skip it

If you get a surface level understanding and jump straight to advanced concepts and newer tools, you are making the rest harder on yourself. A core component is missing and it shows up later.

Go the other way and the effect reverses. With a deep understanding of SQL, the other tools become easier to use, because you can see how they interact with the database underneath.

It is also a way to stand out. Strong SQL is far less common than the number of people who list it on a resume would suggest.

Reason 3: Teams need help with SQL

Reason three is about opportunity. There are still a lot of poorly written queries out there, and that is work waiting for someone.

What bad queries actually cost

You see overly complicated logic, redundant logic, and rabbit holes of queries that have gotten worse over time. The costs land in two places:

• Compute. The query is doing far more work than the question requires, and you pay for it on every run.
• Developer time. Nobody can tell what the query is supposed to answer, so every change starts with an investigation.

I do not always know whether it comes from a gap in skill or from a deadline that forced things through quickly. Either way the result is the same.

Why that is good news for you

From working with a lot of teams and a lot of companies, I can tell you plainly that people need help writing SQL.

So do not stop at the basics. Go deeper, to the point where you can read someone else's code and quickly see where it can be improved.

You can build an entire career on that alone. Come in with a genuinely strong understanding of SQL and there will be opportunities, and people will want to work with you.

Reason 4: It is built into so many tools

The fourth reason is reach. SQL is integrated into an enormous number of data tools, old ones and new ones.

That includes drag and drop tools and version controlled, code based tools. It turns up across ingestion, transformation, orchestration and automation.

The database is still where you will use it most. The point is that it does not stop there, so the skill keeps paying off in places you did not expect.

Where to put the effort

If you are newer and trying to decide what to focus on, this is the one. If you are experienced and looking to refocus, going deeper here is rarely wasted.

Learn the basics properly, then keep going: performance, readability, and the ability to look at an unfamiliar query and understand its intent quickly.

Related reading

• SQL vs dbt Models (& the value of CTEs)
• Good Habits to Help You Write Cleaner SQL
• 3 Must-Haves for Any SQL Style Guide
• What to Learn First as a Data Engineer

Final takeaway

Almost every engagement I take on starts with reading somebody's existing SQL, and the quality of it predicts how the rest of the project will go. Get deep enough that you can look at an unfamiliar query and see the intent, and you will be useful on any data team you join.