You Already Know Machine Learning and Just Call It Something Else

What finally clicked when I finished Andrew Ng’s “Supervised Machine Learning: Regression and Classification,” and how to make the ideas stick if you already write code.

I’ve spent most of my career writing application code: functions in, behavior out, logic I could reason about line by line. So when I started Andrew Ng’s Supervised Machine Learning: Regression and Classification, which is the first course in the Machine Learning Specialization, my biggest fear was the math. Greek letters everywhere. Partial derivatives. Cost surfaces.

What I didn’t expect was how much of it mapped cleanly onto things I already understood as a software engineer. By the end, the math wasn’t the point. It was just notation for ideas I’d been using for years under different names.

If you write code for a living and you’ve been circling ML from a distance, this is the post I wish I’d read first. I’m going to walk through the core ideas the way they actually landed for me.

The one mental model that makes everything else easier

Here’s the reframe that unlocked the whole course:

A machine learning model is just a function with parameters you don’t set by hand.

In normal code, you write the logic and you choose the constants. In ML, you choose the shape of the function and then let an algorithm find the constants for you by showing it examples.

That’s it! That’s supervised learning. You hand the system a pile of labeled examples, meaning inputs X paired with the correct answers y, and it figures out the parameters that best reproduce those answers. "Supervised" just means you had the answer key during training.

There are two flavors, and the only difference is what kind of answer you’re predicting:

• Regression predicts a number. How much will this house sell for? How many minutes until the server falls over?
• Classification predicts a category. Is this email spam or not? Is this transaction fraud?

Same machinery underneath. Different output.

Linear regression: your first model is a straight line

The course starts with the simplest possible model, which predicts one number from one input with a straight line:

f(x) = w * x + b

If that looks like y = mx + b from school, it is. w is the slope (the "weight"), b is the intercept (the "bias"). Feed in a house's size, get back a predicted price.

The interesting question isn’t the formula. It’s: how do you pick w and b? You could eyeball it. But "eyeball it" doesn't scale, and it definitely doesn't work once you have dozens of inputs. You need a way to measure how wrong you are, and a way to get less wrong automatically.

The cost function: a score for how wrong you are

To improve something, you have to measure it. In ML that measurement is the cost function (or loss function).

For regression, the standard one is mean squared error: for every example, take the gap between your prediction and the real answer, square it, and average all those squared gaps.

cost = sum((prediction - actual) ** 2 for each example) / (2 * m)

Think of it as a single number that says “across all my training data, here’s how badly I’m doing.” Big number, bad model. Small number, good model.

Squaring does two things: it makes every error positive, so overshooting and undershooting both count, and it punishes big mistakes far harder than small ones.

Now the whole problem has a clean shape: find the w and b that make this number as small as possible. That's an optimization problem, and optimization is something engineers already do all the time.

Gradient descent: the algorithm that does the learning

This is the heart of the course, and honestly the heart of a huge chunk of modern ML.

Imagine the cost as a landscape. The horizontal directions are your parameters (w, b); the height is how wrong you are. You're standing somewhere on this terrain in thick fog, and you want to reach the lowest valley. You can't see the whole map, but you can feel the slope under your feet.

So you do the obvious thing: take a step downhill. Then feel the slope again. Step again. Repeat until the ground is flat and you can’t go any lower.

That’s gradient descent. The “gradient” is just the slope, because the derivative tells you which direction is downhill and how steep it is. Each iteration nudges every parameter a little in the direction that reduces the cost:

w = w - learning_rate * gradient_w
b = b - learning_rate * gradient_b

If you’ve ever written a loop that iteratively refines a guess until it’s “good enough,” this will feel familiar. It’s the same instinct, formalized.

The learning rate is the one knob that bites you

The learning_rate is your step size, and it's the parameter people get wrong first:

• Too large, and you leap right over the valley, so your cost bounces around or blows up to infinity. (Every engineer has shipped a retry loop that diverged. Same energy.)
• Too small, and you’ll get there eventually, but you’ll be watching the loss crawl down for a very long time.

There’s no universal right answer; you tune it. A practical tip from the course that stuck with me: plot the cost against iterations. If it’s smoothly decreasing, you’re good. If it’s jumping around or rising, your rate is too high.

More features, and why vectorization matters

Real problems don’t have one input. A house has size, bedrooms, age, location. So the model grows:

f(x) = w1*x1 + w2*x2 + ... + wn*xn + b

Every feature gets its own weight. The logic is identical. It’s just a line in higher dimensional space (a “hyperplane,” if you want the fancy word).

Here’s where the course made a point that lands hard for developers: don’t loop over your features one at a time. Vectorize. Using NumPy, that whole weighted sum becomes a single dot product:

import numpy as np
f = np.dot(w, x) + b

It’s the exact same reason you reach for array operations instead of writing for loops by hand in any code where performance matters. Vectorized math runs orders of magnitude faster because it's offloaded to optimized, parallelized routines under the hood. With real datasets, this isn't a nicety. It's the difference between training in seconds and training in hours.

Feature scaling: a small step that saves you

One subtle, very practical lesson: if one feature ranges from 0 to 2,000 (square footage) and another ranges from 0 to 5 (bedrooms), gradient descent gets lopsided and converges slowly. The fix is feature scaling, which means rescaling every feature to a comparable range before training, so no single feature dominates the others just because its numbers happen to be bigger. It doesn’t change the problem; it just makes the optimization landscape nicer to walk across. It’s the kind of unglamorous detail that separates “it works in the tutorial” from “it works on my data.”

Classification: same idea, squashed into a probability

Now flip from predicting numbers to predicting categories, like spam or not, fraud or not. You might think “just use the line and call anything above 0.5 a yes.” Andrew Ng walks through why that breaks down, and the fix is elegant.

Logistic regression takes the same linear combination you already know and runs it through the sigmoid function, which squashes any number, no matter how large or small, into the range 0 to 1:

def sigmoid(z):
    return 1 / (1 + np.exp(-z))

Now the output reads as a probability. 0.9 means “90% confident this is spam.” You pick a threshold (often 0.5) to make the final call, and the line where the model flips from “no” to “yes” is called the decision boundary.

There’s one trap worth knowing: you can’t reuse mean squared error here. Plug the sigmoid into MSE and the cost surface gets bumpy, filling with local dips that trap gradient descent before it reaches the real bottom. So classification uses a different cost function called log loss, also known as binary cross entropy, which is specifically shaped to stay smooth and rounded so gradient descent can do its job. It’s the same optimization algorithm, just with a cost function chosen to play nicely with it.

Overfitting: when your model memorizes instead of learns

The last big idea is one every developer intuitively gets, because we already have a name for the bad version of it: hardcoding.

A model overfits when it learns the training data too well, including its noise and quirks, and then falls apart on data it hasn’t seen. It’s the difference between writing general logic and writing code that only passes because you hardcoded the exact test inputs. It looks perfect in training and fails in the real world.

The opposite, underfitting, is a model too simple to capture the real pattern, like a straight line trying to fit an obviously curved trend.

The tool the course introduces to fight overfitting is regularization. The idea: add a penalty to the cost function for large weights. Now the optimizer isn’t only rewarded for fitting the data, but is also nudged to keep the model simple. Think of it as a linter for model complexity: it discourages the overly clever solution in favor of one that generalizes. One knob (often written λ) controls how hard you push, and tuning it is part of the craft.

What I’d tell another developer before they start

A few honest takeaways:

You need less math than you fear. Comfort with the idea of a slope and a willingness to sit with notation gets you most of the way. Andrew Ng builds intuition before formulas, every time.

Do the labs. The optional Jupyter labs are where the concepts stop being abstract. Reading about gradient descent is fine; watching the cost drop as you tweak the learning rate yourself is what makes it real. As a developer, this is your home turf, so lean into it.

The vocabulary is the hard part, not the concepts. “Weights,” “bias,” “loss,” “gradient,” “regularization.” Most of these are familiar engineering ideas wearing academic names. Once you map the word to the concept you already know, the fog lifts.

It’s a foundation, not a destination. This course won’t have you shipping a production model on day one, and it’s not trying to. What it gives you is the mental model that everything else in ML is built on: functions, cost, optimization, and generalization. Neural networks, the next course in the specialization, are this same machinery stacked deeper.

Closing thought

What surprised me most wasn’t any single algorithm. It was realizing that machine learning, stripped of the intimidating notation, is something developers are already wired to understand: define a function, measure how wrong it is, and iteratively make it less wrong. We’ve been doing versions of that our whole careers.

If you’ve been waiting for the “right time” to start, this course is a genuinely good front door. The math is approachable, the intuition comes first, and by the end you’ll have a vocabulary that makes the rest of the field readable.

I’m carrying these foundations straight into the next stage of my own AI engineering journey, and if you’re a developer standing where I was when I started, I’d say this: start. It’s more familiar than it looks.

Just completed: Supervised Machine Learning: Regression and Classification, from DeepLearning.AI and Stanford Online, taught by Andrew Ng.

Follow me on Github where I share Machine Learning Code in Python: **https://github.com/foobearer**

Photo by Ricky Kharawala on Unsplash