Machine learning is the practice of fitting a function to data instead of writing it by hand. That is the whole idea. Everything else — architectures, optimizers, embeddings, transformers — is engineering around that one substitution. If you are a software engineer approaching the field now, the useful mental model is not "learn the math first" but "learn what class of problem each tool solves, then go as deep as the problem demands".
The families, and what they are for
- Supervised learning — you have labelled examples and want to predict the label for new inputs: fraud scoring, churn, demand forecasting, defect detection. This is still the majority of ML that earns money.
- Unsupervised learning — no labels, find structure: clustering customers, anomaly detection, dimensionality reduction before visualization.
- Reinforcement learning — an agent acting in an environment for delayed reward: pricing, routing, game playing, and the alignment phase of modern language models.
- Self-supervised / foundation models — train on enormous unlabelled corpora by predicting masked or next tokens, then adapt. This is where LLMs and modern embeddings come from.
For tabular data — rows and columns, the shape of most business problems — gradient-boosted trees (XGBoost, LightGBM, CatBoost) remain the honest first choice and frequently the last. Deep learning dominates unstructured data: text, images, audio, video. Knowing which side of that line your problem sits on saves months.
The transformer, briefly
A transformer turns tokens into vectors and then repeatedly lets every position look at every other position through attention: each token emits a query, a key, and a value; the query is matched against all keys to produce weights; the output is the weighted sum of values. Stack that with feed-forward layers and normalization, train it to predict the next token over a large corpus, and the resulting model develops a startling amount of usable structure. Attention is quadratic in sequence length, which is precisely why context windows are expensive and why so much research targets that cost.
The part that decides whether you succeed
Model choice is a Tuesday afternoon. Data quality, leakage, and evaluation are the whole quarter.
The most common way an ML project fails is not a bad model — it is a beautiful offline metric that does not survive contact with production. The usual culprits: target leakage (a feature that encodes the answer and will not exist at prediction time), a random split on time-series data, training on a distribution that no longer exists, and optimizing accuracy on a problem where the classes are 99:1 and accuracy is meaningless.
- 01Define the decision the model informs, and the cost of each kind of error, before touching data.
- 02Split by time if the data has time in it. Always.
- 03Build the dumbest possible baseline — a heuristic, a constant, last week's value. Many models never beat it.
- 04Pick a metric that matches the cost asymmetry: precision/recall at a threshold, PR-AUC for imbalance, calibration when downstream logic uses probabilities.
- 05Ship it behind a shadow deployment, compare against the current process on live traffic, and only then let it decide anything.
- 06Monitor input drift, prediction drift, and outcome quality separately. Data pipelines break far more often than models degrade.
Working with LLMs specifically
For most product teams the question is no longer "train or not" but "prompt, retrieve, or fine-tune". The ladder runs in that order for a reason. Prompting with good structure and examples is free and instant. Retrieval-augmented generation grounds answers in your own documents and fixes most factuality complaints. Fine-tuning is for format, tone, and narrow task specialization — it is the wrong tool for injecting knowledge that changes weekly. Reserve training from scratch for organizations whose product is the model.
- Build an evaluation set before you build the feature — fifty real, hard, hand-checked cases beat any amount of vibes.
- Treat prompts as versioned artifacts in the repository, with diffs and review.
- Constrain output with schemas or tool calls; parse-and-retry beats hoping for well-formed JSON.
- Assume every model call can be slow, fail, or return nonsense, and design timeouts, fallbacks, and human escape hatches accordingly.
- Log inputs and outputs (with consent and redaction) — that log becomes your next evaluation set and your best debugging tool.
How to actually learn it
Pick one real problem with real data you care about. Do the whole loop end to end — messy data, baseline, model, evaluation, deployment, monitoring — before you optimize any single stage. Read the papers of the methods you actually use rather than the ones on the front page. And keep a bias toward the boring: a well-monitored logistic regression in production is worth more than a state-of-the-art notebook nobody can run.