Someone messaged me recently asking which machine learning course to take first. They had never written a SQL query. I told them to close the course tab and go do fifty SQL exercises instead, and I think they were disappointed by the answer.
I am a backend engineer, not a data scientist, so take this as advice from someone who sits next to the data function rather than inside it. But that position gives me a specific view: I build the systems that produce the data, and I see which analysts and data people actually get things done inside a company. The pattern is consistent enough to be worth writing down.
Data science and analytics keep ranking near the top of in-demand IT skills, and the volume of learning material has grown accordingly. Most of it is arranged in the wrong order.
SQL Is Not the Boring Prerequisite, It Is the Job
The mental model many beginners have is that SQL is a small hurdle before the interesting statistical work. In practice, in most organisations, querying and reshaping data is the majority of the work, and the person who is genuinely fluent in SQL is more useful than the person who has read three books on modelling.
Fluent means more than SELECT ... WHERE. It means you are comfortable with:
Joins to the point where you can predict the row count before you run the query — and you know why a join accidentally duplicated your revenue figures.
Window functions. Running totals, rank within group, comparing a row to the previous one. This is the tool that turns "I need a script for that" into one query.
CTEs for readable multi-step logic, because a 200-line query with six nested subqueries is a maintenance problem, not a flex.
Aggregation with correct handling of NULLs, which quietly produces wrong numbers more often than any other single thing I see.
Reading a query plan well enough to know why something takes four minutes and how an index would help.
If you can do those, you can answer most business questions on your own without waiting for anyone. That independence is what makes someone valuable early in their career.
Python, But the Unglamorous 20% of It
The Python you need for data work is narrower than a general programming course suggests. Pandas or Polars for reshaping, enough of the standard library to move files and call APIs, and the discipline to write functions instead of a 400-line notebook cell.
The habit I would push hardest on: get out of the notebook for anything that runs twice. Notebooks are excellent for exploration and terrible as production artefacts. Hidden execution order, no tests, no version control diff worth reading. When a piece of analysis becomes something the business depends on weekly, it should become a script with parameters, a schedule and logging. That transition is where a lot of analysts stall, and getting past it is most of what separates "analyst" from "analytics engineer."
You also do not need to write your own algorithms. Understanding what a model does, what assumptions it makes, and how to evaluate whether it is any good matters far more than being able to implement gradient descent from scratch.
Power BI and the Dashboard Trap
Every company I have worked with has dashboards that nobody opens. Usually because they were built to display everything available rather than to answer a specific question that someone actually has on a Monday morning.
The technical side of Power BI is learnable in a couple of weeks. Connect a source, model relationships, write measures in DAX, arrange visuals. The part that takes longer, and matters more, is knowing what to leave out.
Two things I would tell anyone learning it. First, learn the data modelling layer properly — a clean star schema with a dedicated date table solves most of the performance and "why is this number wrong" problems people blame on DAX. Second, build the dashboard backwards from the decision. Ask what action someone will take differently depending on what they see. If there is no answer, you are building a wall poster, not a tool.
What Actually Goes Wrong With Data in Production
Here is where my side of the fence gives me a slightly different view. The analytics failures I get pulled into are almost never modelling failures. They are plumbing failures.
A field that used to be a string became an integer after a release, and the pipeline silently coerced it. A timezone mismatch made a daily report count some events twice and skip others. A dashboard aggregated soft-deleted records because nobody told the analyst about the deleted_at column. The source system changed a status name from active to ACTIVE and a filter stopped matching, so a number quietly dropped by 12% and nobody noticed for a month.
Which is why the skills that pay off fastest in a real job are not the ones at the top of the curriculum:
Understanding the source system. Talk to the engineers who built the application. Ask what a row in this table actually means and when it gets written. Half of all analytical errors are semantic, not statistical.
Data validation as a habit. Row counts, null rates, distinct values, min and max dates — check them every time before you trust a table. A five-minute sanity check has saved me from wrong conclusions more times than any sophisticated technique.
Idempotent pipelines. If a job runs twice, the result should be identical. This one requirement prevents an entire category of duplicated-data incidents.
Version control and code review for analysis. Yes, for SQL and notebooks too. The number that goes to the board deserves at least as much review as a button colour.
Where Machine Learning Actually Fits
I am not talking anyone out of ML. But the sequencing matters, and so does honesty about how often it is the right tool.
Most business questions are answered by good aggregation and a clear chart. Of the remainder, most are answered by a straightforward model — logistic regression, gradient boosting on tabular data — that is easy to explain to a stakeholder and easy to keep running. Deep learning has a genuine and important place, and it is a smaller place than the course catalogue implies.
What has genuinely shifted is that language models made unstructured data tractable. Support tickets, reviews, call transcripts, PDFs, free-text fields — this used to be a specialist project and is now an API call and a schema. If you want a differentiator right now, being the person who can reliably turn messy text into clean structured rows is worth more than another certificate in a framework.
The Order I Would Learn It In
SQL until it is genuinely comfortable, with real messy data rather than tidy course datasets. Then Python for reshaping and automation, with the goal of turning one manual weekly task into a scheduled script. Then a BI tool, built around one decision that a real person makes. Then statistics — distributions, sampling, what a p-value does and does not tell you, why correlation keeps embarrassing people. Then modelling. Then, if you enjoy the plumbing side, the data engineering layer: warehouses, orchestration, transformation tooling.
Build things that use real, ugly data. The public dataset that comes pre-cleaned teaches you almost nothing about the actual job, which is largely negotiating with reality about what the numbers mean.
And learn to write a paragraph explaining your result to someone who will not read the chart carefully. The analysis that changes a decision is the one that got understood, and that skill has never been automated away.
