Machine Learning
Getting computers to learn patterns from data and improve at a task, instead of being explicitly programmed with rules.
When not to use it
- When the rule is knowable. If a domain expert can state the condition, code the condition. ML is for when the rule is too complex or unknown to write down — not for when nobody's asked.
- Without enough data to learn from or evaluate on. You need both, and teams routinely forget the second.
- When being wrong is unacceptable and unexplainable. ML makes statistical bets. Some decisions shouldn't be bets.
Reach for something else instead
- Rules and heuristics — fast, testable, and correct far more often than the field admits.
- Statistics when you want to understand a relationship rather than predict a value.
- Buying it — for common problems, a mature API beats a bespoke model on cost, time, and quality.
Sources & further reading
- Domingos (2012), A Few Useful Things to Know About Machine Learning — the most useful nine pages in the field.
- Sculley et al. (2015), Hidden Technical Debt in Machine Learning Systems — what happens after the model works.
- Wolpert & Macready (1997), No Free Lunch Theorems for Optimization — why there is no best algorithm, only fits.
Primary sources, listed so you can check the claims on this page rather than take them on trust.
Where people go wrong
- Starting with the model instead of the decision. If nobody can say what action the prediction changes, the project has no destination.
- No baseline. Without "what does guessing the average get us," accuracy numbers mean nothing.
- Underestimating data work. It's most of the job, and it doesn't stop after launch.
At a glance
FieldFoundations
Core idealearn rules from data, not from code
Needsdata
Three paradigmssupervised, unsupervised, reinforcement
DifficultyBeginner
Flashcards for this concept
Question
—
Answer
—
1 / 4
Often compared with
AI vs. Machine Learning vs. Deep Learning — the field, a way to achieve it, and a technique within that.