How to Think Like an ML Practitioner
You'll learn to
- -Adopt the core mental habit of ML practitioners: thinking in terms of data and distributions, not rules
- -Recognize the difference between a rules-based mindset and a learning-based mindset
Traditional software engineering is rule-writing. You specify exactly what should happen for every input you anticipate. Machine learning inverts this. Instead of writing the rule, you show the system many examples of inputs and correct outputs, and an algorithm finds a rule, or something rule-shaped, that fits.
From "What Should Happen" to "What Usually Happens"
A traditional spam filter might hard-code something like: if the email contains the word "lottery" and has more than three exclamation points, mark as spam. An ML-based spam filter is shown thousands of emails labeled spam or not-spam, and it learns patterns, which might include word choice, sender reputation, and structure, that no human explicitly wrote down. The tradeoff is real. You gain the ability to handle patterns too complex or too numerous to hand-code, but you lose the ability to point at a single line of code and say this is why it made that decision.
- -Rules-based thinking is precise and debuggable, but brittle to inputs you did not anticipate.
- -Learning-based thinking is flexible and generalizes to new inputs, but harder to explain and harder to guarantee correctness for.
Most real systems use both. A production ML system is usually a learned model wrapped in ordinary rules-based code that handles validation, guardrails, and fallback behavior. You rarely see a pure ML system with no traditional code around it.
The Practitioner's Questions
When an ML practitioner looks at a problem, they ask different questions than a traditional engineer would. What data do we have, and is it representative of what we will see in production? What does "correct" even mean here, and can we measure it? What happens when the model is wrong? Can we detect it, and what is the fallback? You will see these three questions resurface constantly through the rest of this phase.
A PM asks you to add a rule: "if a user does X, flag them as high-risk." You suspect this is really a classification problem. How would you explain wanting to reframe it that way?
"I would just say ML is more modern and accurate, so we should use it instead."
"I would point out that hand-coding a threshold rule assumes we already know the exact pattern that predicts risk, which is rarely true and gets brittle fast as new patterns emerge. Framing it as a supervised learning problem lets the system learn that pattern from labeled examples instead, at the cost of needing labeled data and losing some of the rule's inspectability. I would also flag that a real system usually wraps the learned model in rule-based guardrails anyway, so it is not really rules versus ML, it is rules plus a learned layer where a fixed rule cannot keep up."
What is the core mental shift this chapter describes when moving from traditional software engineering to machine learning?