Before I taught, I built. From 2019 to 2020, I worked as a database developer for Afghanistan's National Examination Authority, maintaining the relational systems behind exams taken at national scale. It's the kind of infrastructure work that's invisible when it goes right and very visible when it doesn't.
Integrity first, features second
When the data behind your system determines whether a student's result is recorded correctly, every schema decision carries weight beyond the immediate feature request. Most of my day-to-day work was less about writing new queries and more about protecting the ones already in production: checking constraints, auditing for duplication, making sure an optimization for speed never came at the cost of correctness.
Optimization is a negotiation
Query optimization on an exam-scale database taught me that performance work is rarely a pure win. Indexing speeds up reads and slows down writes. Denormalizing for reporting makes analytics faster and integrity harder to guarantee. Every change was a negotiation between the person requesting the report and the person who'd have to explain a data inconsistency months later. I got good at asking which trade-off the system could actually afford.
A national exam database doesn't get a second chance to be right. That constraint shaped how I've approached every system since.
Why it still matters to my work today
That discipline — integrity before convenience — is the same lens I now bring to machine learning work: a model is only as trustworthy as the pipeline and the data behind it. It's also why, in my current M.Sc. studies, I keep gravitating back toward the intersection of data engineering and applied ML rather than treating them as separate fields.