I'm Naveen, Founding Engineer at BioCompute. I am building the electronics that read DNA, one molecule at a time. If that sounds like science fiction, that's because parts of it still are.

What I Do?

I work at the intersection of nanotechnology, low-noise analog electronics, firmware, and software, building systems for solid-state nanopore fabrication and molecular-scale sensing. Lately, my focus has been on developing read stack for DNA data storage using solid-state nanopores, which turns out to be a nice combination of physics, electronics, and things not working the first time.

In simpler terms: I design hardware and software that can intercept a single strand of DNA, listen to its incredibly small electrical "signature", and translate them into a reliable digital data.

What I'm Building?

The goal is to move DNA-based data storage from "cool research paper" to "practical infrastructure."

DNA can store staggering amounts of information in almost zero space, but it needs a reliable bridge to the digital world. I'm building that bridge.

printf("One C Program Later, I am a Hardware Engineer");

I hold a B.E. in Electrical and Electronics Engineering from Sri Krishna College of Engineering and Technology, but my real education started with a C compiler.

C has a very interesting way of forcing one to think of uncomfortable questions about memory, pointers, and what computers are actually doing when programs run. Trying to find the answer to those questions, in the hope of becoming a smarter and slightly cooler engineer, pulled me deeper through firmware, electronics, and eventually into the messy reality of analog and digital circuits.

Before all these interesting work I am doing right now, I was a part of and eventually led student motorsport teams where we built cars. The cars that we've built have a remarkable talent for failing in ways that no one ever predicted. That experience taught me one thing very clearly: reliability matters far more than theoretical elegance.

What's My Engineering Philosophy?

I know, no one asked, but here it is: The "No Idea" Rule, I'm primarily drawn to problems I have no clue how to solve. If I knew how to do it at the start, it probably wasn't worth doing.

What's my take on Failure: In engineering things rarely work on the first attempt. Or the second. My process is simple: Build, break, learn, repeat.

Do I care about domain boundaries? I identify as a hardware engineer, but I frequently "wander" into the software layer. Real-world problems don't care about departmental boundaries, so neither do I.

Failure is inevitable. The goal is just to make sure the system fails in a slightly more sophisticated and less confusing way next time.