A community thread on r/learnmachinelearning landed on a sharp claim this week: 20% of ML theory handles 80% of production work. The post — written by a data scientist six months into an engineering role — named the algorithms (logistic regression, gradient-boosted trees, transformers) and the shipping skills (Docker, SQL, data validation). It left the theory itself implicit. The four classical concepts below are what production reliably tests for, and what reliably falls away.
Bias-variance, but as a deployment forecast
Bias-variance is taught as a U-curve and a training-set anecdote. In production it shows up earlier — as the forecast for whether a model will quietly degrade between offline metrics and live traffic. High-variance fits look brilliant on a held-out set and embarrass themselves on the long tail; high-bias fits look mediocre offline and stay mediocre live. The reason the framework earns its keep is that it answers the question every team asks in week three — "training looked fine, deployment didn't, why" — without inventing new vocabulary for the diagnosis.
Why regularization is a data-budget question
The textbook frames regularization as a way to discourage large weights. The production frame is cheaper: regularization is the lever for "how much data does this model have, really, after the duplicates and the leakage are gone." Strong L2, larger dropout, smaller learning rates are the same answer to the same problem — the effective dataset is smaller than the row count suggests. Tuning regularization without first auditing data quality is how teams burn a week chasing a number that data cleaning would have moved more.
Loss functions as a product spec
Most teams pick a loss function the way they pick a base image — once, by default, and never again. The classical concept that earns its keep is the inverse: the loss function is a product spec, written in math, that the optimizer takes literally. A fraud model shipped with vanilla cross-entropy is telling the optimizer that catching one extra true positive is worth nine extra false positives, and then everyone is surprised when human reviewers drown in alerts. Naming the asymmetry — class weights, focal loss, an explicit cost matrix — is the smallest theoretical move with the largest downstream effect.
Calibration before accuracy
The metric on the dashboard is accuracy or AUC. The metric the downstream system actually consumes is a probability — a 0.84 score that some other service multiplies by an expected-value estimate, or that a threshold rule converts into an action. Models can score well on AUC and still be wildly miscalibrated, returning 0.9 confidence on events that resolve true 60% of the time. A reliability diagram or a quick Platt-scaling pass takes an afternoon and forecloses the most common production failure mode for any model whose score is going to be multiplied by something later.
What the thread does not cover
The four concepts above are theory. The Reddit thread is right that the day is mostly not theory — it is data pipelines, observability, on-call rotations, and the long discipline of evals that survive a model swap. Those skills decide whether the theory ever gets a chance to matter. For that systems half of the job, the original thread is the better read, and the comments below it — where practitioners argue about the algorithm list — are worth more than the post itself.
Source: 6 Months of ML Engineering: The 20% of theory that handles 80% of production code.
