What is Data Science?

Why this lecture exists

You are one week into a Master’s degree in data science. It is fair to ask:

  • What exactly is data science — beyond a buzzword on a job posting?
  • How do practitioners actually approach a problem, before any code is written?
  • What kinds of jobs does this field contain, and which skills matter for which?
  • What techniques will this course teach, and when is each the right tool?

Defining the field

A working definition

Data science is the discipline of drawing defensible conclusions and making decisions from data, combining statistical reasoning, computation, and domain understanding.

  • Statistical reasoning — uncertainty, variability, bias; knowing what the data can and cannot tell you.
  • Computation — the data rarely fits in your head, and increasingly not on your laptop; algorithms and engineering make the reasoning practical.
  • Domain understanding — a model of hospital readmissions built without understanding hospitals will confidently answer the wrong question.

Take any one of the three away and the result has a name: statistics without computation is limited to small problems; computation without statistics is how confident nonsense gets shipped; both without domain understanding is a solution in search of a question.

Data science, ML, AI, statistics — untangling the terms

  • Statistics — the mathematics of learning from data under uncertainty. The oldest and deepest of the four; most of this course rests on it.
  • Machine learning — algorithms whose performance improves with data. A toolbox data science uses, heavily.
  • Artificial intelligence — the broadest umbrella: systems doing tasks that seem to require intelligence. Today usually means large neural models.
  • Data science — the practice that draws on all three to answer real questions, end to end: acquisition to communication.

The boundaries are blurry and employers use the words loosely. What matters is not the label but the question you are answering — which is the next topic, and the most useful idea in this lecture.

How practitioners approach a problem

First, classify the question

Before choosing a technique, classify what kind of question you are asking. A useful taxonomy (after Leek & Peng, Science 2015):

Question type Asks Example
Descriptive What does the data say, summarized? Average ride time by hour
Exploratory What patterns are worth a closer look? Riders cluster into commuter/leisure groups
Inferential Does the pattern hold beyond this sample? Do commuters in general ride longer in rain?
Predictive What will happen for a new case? Will this user churn next month?
Causal What happens if we intervene? Does the discount cause retention?
Mechanistic Exactly how does the effect operate? Through which pathway does the drug act?

The taxonomy is not academic

  • Most real analyses fail by answering a different type than was asked — the classic version: answering a causal question (“should we launch the discount?”) with a predictive model (“churners tend to lack discounts”).
  • Each type has different standards of evidence. A predictive model is judged by held-out accuracy; a causal claim is judged by whether confounding is controlled. Excellent prediction can be worthless causal evidence.
  • This course teaches techniques across the whole ladder — and near the end (the causal inference sessions) we treat the prediction/causation gap head-on. Keep the distinction in mind from today.

The lifecycle of a data science project

Every project loops through roughly six stages — rarely in a straight line:

  1. Frame the question — with the stakeholder, in their terms; classify it (see previous slide); define what “good enough” means before modeling.
  2. Acquire the data — files, databases, APIs, scraping, instrumentation. Usually the least glamorous and most decisive stage.
  3. Clean and explore — missing values, duplicates, units, outliers; plots before models, always. Expect half the total effort here.
  4. Model — choose the simplest technique that answers the question type; this course’s techniques map is the menu.
  5. Validate — held-out evaluation, sanity checks against domain knowledge, error analysis. The stage that separates analysis from wishful thinking.
  6. Communicate and deploy — a decision-maker acts on it, or a system serves it. If nothing changes, the project did not happen.

Two cultures, one practitioner

Modeling to understand

  • Parameters mean something
  • Small, interpretable models
  • Inference, intervals, effects
  • “Why does Y happen?”

Linear/logistic regression, causal graphs

Modeling to predict

  • Accuracy on unseen data is all
  • Complexity fine if validated
  • Feature importance at best
  • “What will Y be?”

Random forests, neural networks

Breiman called these the two cultures (2001). A working data scientist moves between them deliberately — and says clearly which one a given result belongs to. Much of this course alternates between the columns; notice which side each technique lives on.

The jobs

Types of data science roles

The field has differentiated. Titles vary by company, but these clusters are stable:

Role Center of gravity Typical day
Data analyst descriptive/exploratory SQL, dashboards, “what happened and why” for a business team
Data scientist (product/inference) inferential/causal A/B tests, metrics design, “did the feature work?”
Machine learning engineer predictive, in production training pipelines, serving, monitoring; strong software engineering
Data engineer the data itself pipelines, warehouses, quality; makes everyone else possible
Applied / research scientist novel methods pushing a model class further; papers or patents
Analytics engineer the analyst/engineer seam dbt-style transformation layers, metrics definitions

What this means for you

  • Every role above uses the first half of this course — data handling, exploration, the supervised/unsupervised toolbox, and knowing which question type is in play.
  • The roles diverge on the second half: ML engineers go deep on the neural network sessions, product data scientists on the causal ones, analysts on communication and the descriptive end.
  • You do not need to choose today. You should leave this course knowing which columns of that table energize you — the electives that follow are where you specialize.
  • Every role’s interviews probe the same two things this course grades: can you justify your approach, and do you know why the technique works — not just which library call produces it.

The techniques map

What this course covers, and when to reach for it

You want to… Technique Sessions
Group similar things, no labels k-means, hierarchical, GMM 4–7
Say how alike two things are distance & similarity measures 3
Predict a category trees & random forests, k-NN, logistic regression 9–13
Predict a number linear regression + regularization 12–13
Compress / de-noise / visualize high-dimensional data SVD, PCA, t-SNE 14–15
Ask “did X cause Y?” causal graphs, effect estimation 16, 18
Learn from raw signal (images, text) neural networks 19–20
Work with language NLP pipeline, embeddings 21
Recommend items to users matrix-factorization recommenders 22
Reason about connected data graph analysis, centrality, communities 23–24

The arc of the semester

  • Foundations first (S3): what “similar” means, mathematically — because half the techniques in the map are built on a distance.
  • Unsupervised before supervised (S4–7 before S9–13): finding structure without labels forces you to confront what structure is; labels then feel like a luxury rather than a given.
  • Representation in the middle (S14–15): SVD/PCA is the hinge — it serves clustering behind you and feeds recommenders and neural networks ahead.
  • Causality after regression (S16 and S18, either side of quiz 2): you will have just fit your first regressions; the natural next question — “so does X cause Y?” — deserves an honest answer, which is: not without more assumptions than you think.
  • Structured and modern topics last (S19–24): neural networks, language, recommenders, graphs — each stands on two or three earlier sessions.

How to succeed in this course’s format

  • The pre-recorded lecture is where ideas arrive. Watch actively: pause, take notes, and interrogate what you don’t follow — asking an AI assistant to re-explain a concept from the lecture is encouraged, and is itself practice for how you will work professionally.
  • The knowledge check (due before class) is deliberately low-stakes: it exists to make the recap useful, not to catch you out.
  • In class we do, rather than listen: a short recap with cold-call Q&A — answering earns credit even when wrong — then a group activity where the real learning happens. You may use AI on activities, but you must be able to explain and defend every line when asked.
  • The weekly theory homework is where the foundations get exercised — it is participation-graded practice for the quizzes, which is where theory is graded for correctness.

Recap

  • Data science = statistics + computation + domain understanding, in service of defensible conclusions and decisions.
  • Classify the question first — descriptive, exploratory, inferential, predictive, causal, mechanistic. Most failures are type errors.
  • Projects are a loop: frame, acquire, clean, model, validate, communicate.
  • The job market wants differentiated roles; all of them stand on this course’s first half.
  • The techniques map is the course in one table; by December you should be able to reproduce it, with reasons, from memory.