What an MS in CS Taught Me About the Gap Between Research and Production

I'm a few months from finishing my MS in Computer Science at Northeastern. Before this, I spent two years as an ML engineer at Myelin in Bangalore, shipping production models. Before starting, I wrote about hoping to close the gaps in my knowledge, to go from calling loss.backward() to actually understanding optimization landscapes.

Now, on the other side of it, the picture is more nuanced than I expected.

What Academia Gave Me That Industry Couldn't

Mathematical maturity. At Myelin, I could implement a paper. After two years of coursework, I can read one and know why the authors made specific architectural choices. Courses in machine learning theory and probabilistic graphical models forced me to engage with the math I'd been skating past. That foundation compounds over time.

The habit of reading papers critically. In industry, you skim papers for the architecture diagram and the results table. In a research setting, you learn to interrogate methodology, spot leaky evaluations, and ask "does this result actually generalize?" That skepticism is permanently useful.

Exposure to adjacent fields. My coursework touched NLP, systems, and algorithms in ways that my ML-focused industry role never would have. Some of my best ideas at Honeywell came from connecting concepts across domains I wouldn't have explored on my own.

What Industry Taught Me That Academia Never Would

Production constraints are real and humbling. At Myelin, I learned that a model with 92% accuracy that runs in 50ms is more valuable than one with 96% accuracy that takes 500ms. At Honeywell, I learned that a model that works in the lab but fails under factory lighting conditions is worthless. No course teaches you that.

Engineering rigor matters as much as model quality. Logging, monitoring, versioning, rollback strategies, CI/CD for model artifacts. None of this showed up in my coursework. But at Honeywell, the difference between a prototype and a production system was entirely about this infrastructure.

Shipping teaches you what matters. When you have a deadline and a customer waiting, you develop an instinct for which improvements are worth pursuing and which are academic. That instinct is hard to build in a classroom.

The Honeywell vs. Myelin Comparison

These were fundamentally different engineering cultures. Myelin was a startup where speed was everything. You could go from idea to deployed model in a week. The feedback loop was tight, the stakes were lower, and experimentation was the default mode.

Honeywell was enterprise engineering. Longer timelines, more documentation, rigorous testing requirements, strict deployment procedures. The models I built had to work reliably in industrial environments where failure had real consequences. It taught me a discipline that startup culture doesn't prioritize.

Both were valuable. Both had blind spots. The startup taught me speed. The enterprise taught me rigor.

The Gap Is the Opportunity

Here's what I keep coming back to. The ML field has a shortage of people who can do both: read a paper on a new attention mechanism on Monday, understand the theoretical implications, and have a production-ready implementation with proper monitoring deployed by Friday.

Most researchers I met during my MS were brilliant but had never dealt with model serving at scale. Most engineers I worked with in industry were effective but couldn't tell you why their optimizer choice mattered beyond "it works."

The people who bridge that gap are disproportionately valuable. They can evaluate whether a new technique is worth adopting, implement it correctly, and deploy it reliably. That combination is rare, and I think it's the most important thing my MS gave me: not just the theory or the practice, but the ability to move between them fluently.

If I had to distill two and a half years of grad school into one sentence, it would be this: the best engineers read papers, and the best researchers ship code.