Data & Analytics

Data work is sold as a subject and practised as a sequence. Records are produced by systems nobody in the data team controls, moved somewhere they can be queried, reconciled against each other, interrogated, drawn as a picture, and then made to happen again next week without anyone watching. Every real data job sits at one or two points on that sequence, and the points are not interchangeable. The uncomfortable thing about the field is that learners and employers have settled on different ends of it. Course catalogues are dense at the late stages, where the work photographs well: a model that predicts churn, a chart that finally changes a board's mind. Job adverts are dense at the early stages, where the work does not photograph at all. They ask whether you can pull years of CRM exports into a warehouse without dropping the deleted rows unnoticed, and whether you can explain why finance's revenue figure and marketing's revenue figure have never once agreed. That gap is not a failure of taste on anybody's part. It follows from where organisations feel pain. A company without trustworthy tables cannot use machine learning at all, so it hires for tables first, and it keeps hiring, because pipelines break in ways models do not: a source system renames a field, a time zone shifts, a vendor changes an export format, and every number downstream is wrong while still looking entirely plausible. Data visualization sits at the far end of that chain and inherits every error made before it.

What happens between a source system and a decision

1. Production. The data is created by software the data team does not own: a CRM, a billing system, a checkout, a set of event trackers. None of it was designed for analysis, and that is not negligence, it is the point. Whoever built the checkout optimised for taking money. The job at this stage is not to change anything but to learn how the system behaves, because every quirk not learnt here reappears later disguised as an insight.
2. Movement. Getting records out of those systems and into somewhere queryable is data engineering, and it is where a large share of the open roles live. It is connectors, schedules, retries, backfills, and a warehouse that has to stay affordable while it grows. Almost nobody enrols in a course about backfills. Almost every team that has tried to run analysis directly against a production database has learned, painfully, why the warehouse exists.
3. Modelling in the warehouse. Raw tables are not answers. Someone has to turn them into a layer everyone agrees on, usually with dbt or an equivalent, and decide what an active customer is, when a subscription counts as churned, which refunds reverse which orders. This is a definitional job wearing an engineering costume, and it carries more leverage than any other stage, because every figure produced downstream inherits the decision taken here.
4. Wrangling. Data wrangling is the reshaping that happens after you have the data and before you can ask anything of it: joins that do not line up, dates in four formats, nulls that mean three different things, and a spreadsheet somebody maintains by hand that is nonetheless the only record of which accounts are internal. This stage rarely appears in a syllabus and reliably appears in a Monday.
5. Analysis. Data analysis is the part people picture: the question, the query, the comparison, the answer the analyst is prepared to defend when someone senior dislikes it. SQL does most of it. Python with pandas does the rest, mostly when the shape of the problem outgrows a single query. The scarce skill here is not technique, it is knowing which difference is real and which is noise.
6. Prediction. Fitting a model and expecting it to hold on data it has not seen. This is the stage with the most courses, the most enthusiasm and the fewest junior openings, for an unremarkable reason: a company needs a working pipeline before it needs a forecast, and plenty of companies are still building the pipeline. Worth learning, after one can be trusted with a number.
7. Presentation, and then again next week. A chart, a report, a dashboard in Power BI or Tableau that someone opens on a Monday morning and acts on. The presentation half is a writing skill more than a charting one. The next-week half is engineering again, and it decides whether an analysis becomes a standing input to decisions or a document nobody reopens.

Start where the enrolment isn't

Learn stages two and three first. Concretely: SQL until it is boring, a warehouse you have loaded yourself even if it is a free tier holding your own bank statements, and enough dbt to understand why a model layer exists at all. Then a spreadsheet at a level most people never reach, because business data still arrives as one and findings still leave as one. Then Python and pandas. Then a single dashboard tool, chosen by what your target employers already run rather than by which looks best, which in practice means Power BI inside Microsoft organisations and Tableau across much of the rest. What people who skip those stages get wrong is specific and recognisable. They can produce a number but cannot defend it, because they never saw where it came from. Asked why the figure moved, they re-run the notebook. Asked whether the join dropped rows, they do not know, and frequently do not know that this is a question at all. Their portfolio opens with a clean CSV, which is the single condition the job never meets. That last point deserves an argument rather than an assertion. Practitioners spend most of their time on data quality and courses spend almost none, and neither fact is anyone's fault. Errors enter at every stage before analysis and none of them announce themselves: a model trains perfectly well on wrong inputs and returns a confident answer, a chart renders a corrupted join without complaint. The only available defence is checking, and checking is most of the week. But a teaching dataset has to be clean to be teachable. You cannot set a reproducible exercise on a mess whose shape you do not control, so the exercise arrives tidy, the student rehearses the tidy part, and the ratio between what the course drills and what the job demands is inverted before anybody has done anything wrong. Knowing that in advance is worth more than another badge. If you want badges anyway, PL-300 certifies the reporting stage and DP-700 the engineering one, and neither of them proves you can find the bad join.