About Me

For a while I only cared about what showed up on the screen. Slowly I started asking what happens underneath: deployments, containers, pipelines, what we monitor, what we log, how state moves between services, what breaks when nobody is watching, and why reliability is hard on purpose.

That curiosity turned into a habit. I started reading runbooks, staring at dashboards, tracing requests across services, and caring about the gap between a green build and a calm production week.

I'm Minh Pham. I'm a Computer Science and Mathematics student at the University of Minnesota, Twin Cities. The work I want to grow into spans software engineering, backend and distributed systems, platform engineering, DevSecOps, data engineering, and ML infrastructure: how software is built, kept alive, secured, and observed once it leaves a single file.

Over time I cared less about “did I ship a feature” and more about how software is tested, packaged, deployed, watched, patched, scaled, and handed off. A feature that cannot be deployed safely is not really done. That is the shift for me: not abandoning building, but widening the frame from one service to the whole system around it, and then further, to how that system fails, how it recovers, and how the data flowing through it stays trustworthy.

I like dependable systems. I like automation because it removes fragile manual steps people forget under stress. I like observability because it tells the truth when assumptions are wrong. Distributed systems push me to think past one service: message ordering, retries, idempotency, partial failure, and how pieces fail together instead of alone. Reliability, to me, means designing for conditions that are messy, concurrent, and real.

School helped with that. Operating systems and networking gave me a feel for what the machine is actually doing. Algorithms and mathematics trained me to notice trade-offs, costs, and edge cases. I think about failure modes and efficiency more than I used to, and I want explanations that are clear enough to hold up when something breaks at night.

When I work, I think about the full loop: build, test, deploy, observe, improve. I work in small steps because big surprises rarely help anyone. I expect failures to happen; the point is to learn from them. Logs, a broken build, a long debugging session, a noisy metric: those are often where I learn the most, even when they are painful.

To me, DevSecOps is where policy meets the pipeline: scans, secrets, and review have to travel with the same rhythm as the deploy. Data engineering is the same discipline pointed at a different failure mode: schema drift, late-arriving data, and pipelines that need to be idempotent, not just fast. MLOps sits nearby too: models need reproducibility, deployment discipline, and monitoring like anything else running in production, sometimes with harder data problems on top.

I was a soccer captain for a while. It was less about being loud and more about communication, trust, and responsibility when the game was tight. That carries over: teams, clear signals, and owning outcomes together.

I try to build in public in a simple way. My GitHub, projects, and blog are where I share the work in progress, not only the tidy ending. I would rather someone see what I tried than pretend I never had a wrong turn.

On a personal level, I stay curious about how systems fail. I have spent hours debugging something small because I needed to know why. I still sketch ideas on paper before I touch a terminal when the problem feels fuzzy. Outside of code, I try to keep a consistent training routine; it is its own kind of discipline, and honestly a good reset after a long debugging session.

Experience