Selected work

The question. Early diagnosis saves lives, but risk hides inside noisy, high-dimensional clinical data. Could a model surface it reliably?

What I built. I trained and compared four approaches (Logistic Regression, Random Forest, KNN, and Neural Networks) with feature engineering, hyperparameter tuning, and ensemble methods to push accuracy.

What I learned. Using ROC-AUC scores and confusion matrices to judge the models honestly, I saw clearly where ML genuinely helps early diagnosis and where it still needs a human in the loop.

The question. Genre is usually about sound, but how much of it lives in the lyrics? I wanted to find out, mixing my love of music with machine learning.

What I built. I cleaned and preprocessed a lyrics dataset, turned the text into features with TF-IDF vectorization, and trained a Random Forest classifier to predict genre.

What I learned. Reading the accuracy score, classification report, and confusion matrix showed which genres have a distinct “voice” in their words, and which ones blur together.

The problem. Studying online means fighting distraction. I wanted small, friendly tools that help instead of nag.

What I built. A set of browser extensions in JavaScript: Focus Search for quick access to learning content, a Pomodoro timer paired with lo-fi music, and a playback-speed controller for video lessons.

The result. Little frictions removed, one at a time. Exactly the kind of tooling I wanted while studying.

The question. Could the rigor I use on regulated healthcare data at my day job hold up on a different regulated domain, at real production scale, if I built the whole pipeline myself? I picked CFPB’s public HMDA mortgage-lending data, three years of it, 2022 through 2024, because it’s large enough to force real engineering decisions and messy enough that a clean answer isn’t free.

What I built. A normalized PostgreSQL schema loaded with 39,793,397 real mortgage applications through an idempotent Python pipeline that counts and logs every cleaning decision instead of silently dropping rows. HMDA’s data turned out to have several undocumented sentinel values (literal "NA" and "Exempt" strings, a numeric 1111 code) that the load script had to detect and handle explicitly. A six-check data-quality suite runs after every load. Twelve analytical SQL queries, each opening with the business question and a real recorded finding, cover window functions, multi-step CTEs, every join type, and GROUPING SETS. Then I measured the four heaviest queries with EXPLAIN (ANALYZE, BUFFERS), applied a materialized view, composite indexes, and year-range partitioning, and re-measured. One query dropped from 5,659ms to 32ms, a real 177.58x, not an estimate.

What I learned. The biggest risks weren’t in the SQL. They were in the assumptions between steps. A missing index turned a routine reload into a multi-hour operation. A statistics-stale query looked like a failed optimization until VACUUM ANALYZE fixed it. A materialized view built one step too early silently detached from the table it was supposed to summarize. None of that shows up until you actually run the thing end to end and check the numbers against reality, which is the same discipline that matters most in production data engineering, on any dataset.