A data scientist exists to turn data into decisions better than the ones the\norganization would have made without it. The discipline sits at the join of\nstatistics, computing, and the messy domain where the data was generated. Its\nreason for being is that humans are confidently wrong about patterns: we see\nfaces in clouds, trends in noise, and causes where there are only correlations.\nA data scientist quantifies how much you should believe a claim, and is honest\nwhen the answer is "the data can't tell us that." Without that discipline, the\nloudest opinion wins; with it, the evidence does.
\n","wordCount":101},{"heading":"Core Mission","id":"core-mission","markdown":"Extract reliable, decision-relevant signal from noisy data, quantify the\nuncertainty around it, and communicate both clearly enough that a non-expert acts\ncorrectly.","html":"Extract reliable, decision-relevant signal from noisy data, quantify the\nuncertainty around it, and communicate both clearly enough that a non-expert acts\ncorrectly.
\n","wordCount":24},{"heading":"Primary Responsibilities","id":"primary-responsibilities","markdown":"The glamorous image is building models; the actual work is upstream and\ndownstream of that. A data scientist frames a vague business question into one a\ndataset can answer (\"does this feature lift retention?\" becomes a defined\nmetric, population, and comparison). They find, clean, and interrogate the data,\nwhere most of the hours and the errors live. They choose the simplest method\nthat fits — often a well-specified regression or an A/B test, not a neural\nnetwork. They validate honestly, guarding against the ways an analysis can fool\nyou, and translate a coefficient or confidence interval into a sentence a product\nmanager can act on. And they own the consequences: deciding when the data does\nnot support the decision someone wants, and saying so out loud.","html":"The glamorous image is building models; the actual work is upstream and\ndownstream of that. A data scientist frames a vague business question into one a\ndataset can answer ("does this feature lift retention?" becomes a defined\nmetric, population, and comparison). They find, clean, and interrogate the data,\nwhere most of the hours and the errors live. They choose the simplest method\nthat fits — often a well-specified regression or an A/B test, not a neural\nnetwork. They validate honestly, guarding against the ways an analysis can fool\nyou, and translate a coefficient or confidence interval into a sentence a product\nmanager can act on. And they own the consequences: deciding when the data does\nnot support the decision someone wants, and saying so out loud.
\n","wordCount":127},{"heading":"Guiding Principles","id":"guiding-principles","markdown":"- **Garbage in, gospel out is the real danger.** A clean-looking number from\n dirty data is more dangerous than no number, because people believe it. Most\n trustworthiness is decided before any model runs.\n- **Correlation is not causation, and you will be asked to forget that.** The\n business wants causal claims from observational data constantly; knowing when\n you can and cannot make that leap is the core skill.\n- **The simplest model that answers the question wins.** Complexity buys\n marginal accuracy at the cost of interpretability, fragility, and your ability\n to debug it at 2 a.m.\n- **Quantify uncertainty or you haven't finished.** A point estimate without a\n range is a guess wearing a lab coat.\n- **The question is harder than the math.** Framing it — with the right\n population and metric — is where analyses succeed or fail.\n- **Be your own harshest skeptic.** Before someone else finds the confound, the\n leakage, or the survivorship bias, find it yourself — and validate on data the\n model has never seen, since training performance measures memory, not knowledge.","html":"A data scientist is a translator, and the job lives at the translation seams.\nWith product managers and executives, they convert business questions into\nanalyzable ones and results back into decisions, fighting the constant pull\ntoward the answer the stakeholder already wanted. With data engineers, they\ndepend on clean pipelines and feel every gap. With software and ML engineers,\nthey hand off models that must survive production. The recurring failure is the\ndata scientist working in isolation, producing a technically correct analysis of\nthe wrong question. Good ones spend as much effort on framing as on analysis.
\n","wordCount":97},{"heading":"Ethics","id":"ethics","markdown":"Data is people, and models made from it allocate opportunity: who gets the loan,\nthe interview, the longer prison sentence. The duties that follow: audit for\ndisparate impact even when nobody asked, because a model trained on biased\nhistory reproduces that bias at scale; protect privacy and resist\nre-identification; refuse to torture data until it confesses the conclusion the\nclient paid for; and disclose uncertainty honestly rather than projecting false\nprecision to win the room. The quiet ethical line runs between analysis and\nadvocacy, and a data scientist's integrity is whether they hold it.","html":"Data is people, and models made from it allocate opportunity: who gets the loan,\nthe interview, the longer prison sentence. The duties that follow: audit for\ndisparate impact even when nobody asked, because a model trained on biased\nhistory reproduces that bias at scale; protect privacy and resist\nre-identification; refuse to torture data until it confesses the conclusion the\nclient paid for; and disclose uncertainty honestly rather than projecting false\nprecision to win the room. The quiet ethical line runs between analysis and\nadvocacy, and a data scientist's integrity is whether they hold it.
\n","wordCount":95},{"heading":"Scenarios","id":"scenarios","markdown":"**The miracle model.** A churn model lands at 0.99 AUC on validation — far\nbetter than anything the team has seen. The expert's reaction is suspicion, not\ncelebration. They check feature importance and find `account_closed_date` near\nthe top: a field populated only after a customer churns. The model is predicting\nthe future from the future. Remove the leaked feature, the AUC drops to a\nbelievable 0.78, and the model becomes one you can actually deploy. The lesson:\nwhen a model is too good, audit for leakage before you trust it.\n\n**The feature that \"increased\" retention.** Product reports that users of a new\nfeature retain far better and wants to roll it out hard. The data scientist\nrefuses to read causation into that: the users who *chose* the feature are the\nalready-engaged ones — a selection effect, not a treatment effect. A randomized\nrollout to half the users shows a real but much smaller lift, and only for new\nusers, so the rollout is targeted accordingly — saving the cost of a feature\nthat did nothing for most of its intended base.\n\n**The Friday answer.** An executive needs a number by end of day to decide on a\nmarket launch; the honest analysis needs two weeks. Rather than refuse or\noverstate, the data scientist gives the back-of-envelope estimate *with its\nrange* — \"between a 3% and 12% lift, most likely around 6%, and here are the\nassumptions that could move it\" — and flags which one the two-week study would\nnail down. The executive makes a calibrated bet instead of a blind one.","html":"The miracle model. A churn model lands at 0.99 AUC on validation — far\nbetter than anything the team has seen. The expert's reaction is suspicion, not\ncelebration. They check feature importance and find account_closed_date near\nthe top: a field populated only after a customer churns. The model is predicting\nthe future from the future. Remove the leaked feature, the AUC drops to a\nbelievable 0.78, and the model becomes one you can actually deploy. The lesson:\nwhen a model is too good, audit for leakage before you trust it.
The feature that "increased" retention. Product reports that users of a new\nfeature retain far better and wants to roll it out hard. The data scientist\nrefuses to read causation into that: the users who chose the feature are the\nalready-engaged ones — a selection effect, not a treatment effect. A randomized\nrollout to half the users shows a real but much smaller lift, and only for new\nusers, so the rollout is targeted accordingly — saving the cost of a feature\nthat did nothing for most of its intended base.
\nThe Friday answer. An executive needs a number by end of day to decide on a\nmarket launch; the honest analysis needs two weeks. Rather than refuse or\noverstate, the data scientist gives the back-of-envelope estimate with its\nrange — "between a 3% and 12% lift, most likely around 6%, and here are the\nassumptions that could move it" — and flags which one the two-week study would\nnail down. The executive makes a calibrated bet instead of a blind one.
\n","wordCount":262},{"heading":"Related Occupations","id":"related-occupations","markdown":"A data scientist shares the software engineer's need to ship reliable code but\nreasons in distributions and uncertainty where the engineer reasons in\ncorrectness and state. The machine learning engineer takes the models a data\nscientist prototypes and makes them run at scale in production — overlapping\ndeeply but optimizing for systems rather than insight. Data engineers build the\npipelines a data scientist depends on and complains about. Statisticians and\nresearch scientists are the methodological ancestors, holding the field to its\ninferential standards. Product managers supply the questions and consume the\nanswers.","html":"A data scientist shares the software engineer's need to ship reliable code but\nreasons in distributions and uncertainty where the engineer reasons in\ncorrectness and state. The machine learning engineer takes the models a data\nscientist prototypes and makes them run at scale in production — overlapping\ndeeply but optimizing for systems rather than insight. Data engineers build the\npipelines a data scientist depends on and complains about. Statisticians and\nresearch scientists are the methodological ancestors, holding the field to its\ninferential standards. Product managers supply the questions and consume the\nanswers.
\n","wordCount":91},{"heading":"References","id":"references","markdown":"- *The Elements of Statistical Learning* — Hastie, Tibshirani, Friedman\n- *Statistical Rethinking* — Richard McElreath\n- *Causal Inference: The Mixtape* — Scott Cunningham\n- *The Signal and the Noise* — Nate Silver\n- *Trustworthy Online Controlled Experiments* — Kohavi, Tang, Xu","html":"