jcardena.com Blog A capstone project that finally made the math click
145 posts
EN ES

A capstone project that finally made the math click

AI

An enterprise architect's story of how a hands-on recommender project transformed abstract linear algebra into durable, intuitive knowledge for system architecture.

I almost failed linear algebra in my second year of university. It wasn't that I couldn't follow the steps to multiply matrices or find an eigenvector. I just couldn’t connect it to anything real. The lectures felt like a series of arcane rules for manipulating grids of numbers, completely detached from the software I wanted to build. It was a frustrating, abstract barrier.

The Gap Between Theory and Practice

This is a story I've seen play out many times in my career. We encounter foundational math—calculus, linear algebra, probability—in a setting that treats it as a pure, theoretical discipline. We learn to compute a derivative but don't develop a feel for a gradient: the direction of steepest ascent on a landscape of error. We learn to invert a matrix without an intuition for it as a way to "undo" a spatial transformation.

In my experience, this is a significant hurdle for engineers moving deeper into data and AI. Anyone can import a library and call .fit(). But when the model performs poorly or the abstraction leaks, they are stuck. They lack the first-principle intuition to debug the system because they don’t have a feel for the mathematical machinery humming under the hood. They see the API, not the architecture.

For me, the fog only cleared when a final-year capstone project demanded I build something that actually worked, without leaning on a high-level library to do the heavy lifting.

A Project with Consequences

The task was deceptively simple: build a collaborative filtering recommender from a dataset of movie ratings. The goal was to predict how a user might rate a movie they hadn't seen. This was, in essence, a smaller version of the problem that teams were famously tackling for the Netflix Prize. As I learned later, the techniques I was wrestling with were at the heart of winning papers like the one by Koren, Bell, and Volinsky, "Matrix Factorization Techniques for Recommender Systems."

The first step was structuring the data as a giant, sparse matrix. Each row was a user, each column a movie. The cell at (row, column) held a rating. Most of the matrix was empty. This was the first click. The "matrix," once a whiteboard abstraction, was now a concrete representation of my entire problem space. It was a map of human taste. The challenge was no longer an exercise; it was a practical one: how do you fill in the blanks in a meaningful way?

Users Rate MoviesBuild User-ItemMatrixFactorize MatrixPredict MissingRatings
From Ratings to Predictions

When Symbols Become Systems

The chosen method was matrix factorization, using Singular Value Decomposition (SVD). In class, SVD was an opaque formula: decompose matrix A into U * Σ * Vᵀ. You can find brilliant theoretical explanations, like those in Gilbert Strang's MIT lectures, that explore its profound geometric meaning.

Some argue for that theory-first approach, and they have a point. A deep understanding of abstract proofs can help you generalize better. For me, however, the intuition had to be built on a scaffold of code. In the context of my recommender, SVD became something beautiful. It broke my user-item matrix into two smaller, denser matrices: one for user-features and one for item-features. These were latent features. A column might implicitly learn to represent an affinity for "dark comedies."

Suddenly, the math mapped to the system:

  • The dot product wasn't just a formula; it was a measure of alignment between a user's taste vector and a movie's characteristic vector. A high value meant a good match.
  • The gradient of the error function wasn't just calculus; it was a vector pointing "downhill" on a massive landscape of prediction errors. Each training step was a nudge, moving my model toward better predictions.

The pain of wrestling with raw NumPy arrays was the price of admission for genuine understanding. I watched the error slowly decrease and saw how a poorly chosen learning rate made it explode. The direct feedback loop between the math and the system behavior was the lesson.

The Durable Abstraction

That project was more than 15 years ago, but the intuition it built has outlasted every framework I've learned since. When I look at a modern transformer model, the attention mechanism is, at its core, a sophisticated system of dot products measuring alignment. When I work with embedding layers, I see my old user-feature and item-feature matrices. We are still just learning a dense vector representation for an item, a word, or a customer.

This is the durable knowledge that architecture is built on. It’s not about knowing PyTorch syntax over TensorFlow. It’s about understanding that we are transforming data from one representational space to another, hoping the new space is more useful for the task at hand. That principle is permanent.

DATA SOURCESUser RatingsStreamMovie Metadata DBDETERMINISTIC PIPELINEData IngestionFeatureEngineeringMatrixConstructionLEARNING & STORAGEMatrixFactorization…Vector DatabaseModel TrainingLoopSERVING LAYERPrediction APICandidateGenerationUser-Facing App
Architecture of a Recommender System

Building Architectural Intuition

In an era of powerful, high-abstraction libraries, it’s tempting to skip the fundamentals. This is a trap that creates brittle knowledge. A modern proponent of a hands-on approach is Jeremy Howard, whose "Top-Down" philosophy with fast.ai advocates for getting things working first and diving into theory later. The goal isn't to reject theory, but to build a practical framework to hang it on.

For those of us building systems, my advice is to focus on what lasts:

  1. Build one thing from scratch. Implement a simple linear regression or k-means with a basic matrix library. The struggle is the lesson. Feel the shape of the data as it moves through your logic and you'll never forget the principle.
  2. Map math to system transformations. Constantly ask, "What does this operation represent?" Answering "we are computing a dot product" is less useful than "we are measuring the similarity between this user vector and this product vector."
  3. Focus on the data's journey. See the system not as a sequence of library calls, but as a series of state changes to the data's shape and meaning. This is the architectural view, and it’s where real ownership of a system begins.

The goal isn't to become a mathematician. It's to build a durable intuition for the machinery that powers our modern systems. In my experience, that intuition is never granted by a textbook; it is earned through building.

JC
Juan Cardena
Enterprise Architect, Data & AI

Enterprise architect with 25 years across web, software, data, and AI. MIT CDAO ’25. Writing on agentic AI in production.