From Biomedical Engineering to Production Software

The Lab

My first real programming happened in a university bioinformatics lab. Not the kind with whiteboards full of system design diagrams, but the kind with pipette tips and PCR machines. The code was a means to an end: R scripts to run differential expression analysis on microRNA datasets, Python scripts to clean data that came out of sequencing machines in formats that seemed designed to frustrate.

I studied biomedical engineering at Penn State. The work was genuinely interesting. We were looking at how microRNA regulatory networks changed with aging, using tools like DESeq2, limma, and WGCNA to identify co-expression modules. I published two papers from that work, and I still think the research questions were good ones.

But the code was an afterthought. Research code doesn't need to be maintainable. It needs to produce the right numbers for the paper. Nobody reviews your variable names. Nobody asks about your test coverage. The code runs once, produces a figure, and gets archived.

The Pivot

The pivot wasn't a single moment. It was a slow realization that I was more excited about the pipeline than the paper. I'd spend hours optimizing an analysis workflow and then rush through the biological interpretation. I was building tools, not running experiments.

The restaurant technology vertical is where I landed. It's less glamorous than biotech, but the engineering problems are real: multi-tenant financial data, payroll integrations with legacy APIs, real-time dashboards for operators who don't care about your tech stack. These systems need to work every day, not just the day before a conference deadline.

I went from analyzing microRNA networks to building cash flow dashboards for restaurant groups. The domain changed completely. The engineering thinking didn't.

What Transferred

Analytical Rigor

Science trains you to question your assumptions. When a gene shows up as differentially expressed, the first question isn't "great, what does it do?" It's "is this real, or is this a batch effect?" That skepticism transfers directly to debugging production systems. When a dashboard shows unexpected numbers, the instinct to check the data pipeline before blaming the business logic comes from years of checking sequencing quality before trusting differential expression results.

Working with Messy Data

Biological data is inherently messy. Missing values, batch effects, normalization artifacts, confounding variables. You learn to build robust pipelines because the data will never be clean. This translates well to building integrations with third-party APIs. Restaurant POS systems, payroll providers, accounting software: none of them send you clean, consistent data. The tolerance for messy inputs is a direct transfer.

Scientific Communication

Writing a methods section teaches you to be precise about what you did and why. In software, that translates to writing clear pull request descriptions, useful commit messages, and documentation that actually helps the next person. The "reproducibility" mindset from science maps directly to "can someone else run this?" in engineering.

Experimental Thinking

Research is hypothesis-driven. You form a prediction, design an experiment, collect data, and update your beliefs. Good engineering works the same way. You hypothesize about why a bug exists, design a test to confirm, collect evidence, and fix the root cause. The difference is that experiments in software run in seconds, not weeks.

What Didn't Transfer

Speed of Iteration

In the lab, a single experiment might take two weeks. You plan carefully because redoing it costs real time and real reagents. In software, iteration is cheap. You can deploy, observe, and roll back in minutes. The adjustment from "plan everything" to "ship and learn" took time. I over-planned early in my software career, spending days designing systems that could have been validated with a quick prototype.

Production vs. Research Code

Research code is disposable. Production code is not. The mental model shift from "code that produces the right output" to "code that someone else will maintain at 2 AM" was significant. Error handling, logging, monitoring, graceful degradation: none of these matter in a research context. All of them matter in production.

Users vs. Reviewers

In research, your audience is peer reviewers who read your paper. They're experts. They'll fill in the gaps. In software, your users are people who don't care about your architecture. They care whether the dashboard loads quickly and the numbers are right. Designing for users requires empathy that designing for reviewers doesn't.

Deadlines

Research deadlines are soft. A paper can be delayed by a few months. Nobody dies. Production deadlines are often hard. Payroll needs to run on the 15th and the 30th. The restaurant group's investors expect the financial report on Monday. The shift from "we'll get to it" to "this needs to work by Friday" required a different kind of discipline.

The Hybrid Advantage

The hybrid background isn't a detour. It's a feature. Here's why.

Domain translation. Most software engineers can build a dashboard. Fewer can sit in a meeting with a restaurant operator, understand their actual problem (not the one they think they have), and translate it into a technical specification. The science background trained me to listen to domain experts and extract the real question from the noise.

Data intuition. When someone says "the numbers look wrong," I have an instinct for where the problem probably lives. Is it a data collection issue? A transformation issue? A display issue? Years of debugging analysis pipelines built that intuition.

Technical documentation. Patent work requires precise technical writing. Research papers require precise technical writing. Software documentation should require precise technical writing, but often doesn't. The bar is higher when you've been trained to write for peer review.

Pattern recognition across domains. A microRNA regulatory network and a restaurant's financial data pipeline have nothing in common biologically. But structurally, they're both directed graphs with weighted edges and feedback loops. The ability to recognize structural similarities across domains lets you apply solutions from one field to problems in another.

Where I Am Now

I build production software for the restaurant technology vertical. TypeScript, Python, PostgreSQL, AWS. The systems handle real money, real payroll, real operational decisions.

I'm also studying for the patent bar. The intersection of deep technical understanding and legal precision is where my background in both science and engineering becomes uniquely valuable. Patent work requires you to understand what's novel about an invention, which requires understanding both the technology and the prior art.

And I'm building Zaffira, which is still in the early stages but aims to bring the same engineering rigor I apply to client work into my own products.

The path from biomedical engineering to production software wasn't the shortest one. But the longest path around is often the shortest way through.