From Physics to Systems Software: Why the Dual Degree Paid Off

When I tell people I have a dual degree in Computer Science and Physics, the usual response is polite confusion. "So... which one do you actually use?" The honest answer is both, constantly, and in ways I didn’t expect.

Physics Teaches Abstraction

In physics, you spend years learning when to ignore things. Friction, air resistance, quantum effects, relativistic corrections — in most engineering problems, these are noise. The skill is knowing which level of abstraction is appropriate for the problem you’re solving.

This maps directly to systems software. When debugging a telemetry latency issue, I need to know whether the problem is at the application layer (bad batching logic), the IPC layer (serialization overhead), the OS scheduler (process priority), or the hardware (memory bandwidth). Each level has its own mental model. Switching between them quickly is the job.

Dimensional Analysis as a Debugging Tool

Physicists are obsessive about units. Every quantity has units; every equation must be dimensionally consistent. I carried this habit into software: whenever I see a performance metric, I immediately ask "per what?" Latency per request? Throughput per second? Per core? The denominator matters enormously.

When I was diagnosing the 30-minute telemetry delay, one of the first things I did was instrument the pipeline with per-stage timing. Not just total time, but time per IPC call, time per serialization, time per subsystem. Physics taught me that you can’t fix what you haven’t measured at the right granularity.

Comfort With Complexity

A senior physics student has spent years being comfortable with not fully understanding something. The universe is genuinely complex; most interesting problems don’t have clean closed-form solutions. You learn to work with approximations, to reason about systems you can’t fully simulate.

Distributed systems are the same. IOS-XR runs across dozens of processes and multiple hardware nodes. You can’t hold the whole thing in your head. You build mental models, you make predictions, you test them. If the prediction was wrong, you update the model. That’s the scientific method, applied to debugging.

The Unexpected Benefit: Signal vs. Noise

My favorite intersection of the two fields: when I built BugInsights, the clustering algorithm (HDBSCAN) essentially separates signal (structured bug patterns) from noise (one-off, anomalous bugs). That’s a signal processing problem wearing software clothes. The intuition for what a "cluster" should mean — dense, well-separated, meaningful — came as naturally as thinking about spectral peaks.

Would I recommend the dual degree? Only if you’re genuinely interested in both. The overlap is real, but it rewards people who think across disciplines, not people collecting credentials.