Learning to Build: What nanotech Taught Me About Writing Code

I didn't plan to become a developer. My background is in nanotechnology, molecular biology, nanomedicine, lab work. Code was a tool I picked up to stop doing repetitive things manually. Python scripts to parse plate reader output. Shell scripts to batch process genomic data. Automation as a form of laziness.

Then something shifted. The tool-building started to feel like the most interesting part of the work.

The Scientist-to-Developer Pipeline

There's a surprisingly well-worn path from bench science to software development. Scientists are trained to work with complex systems, reason about uncertainty, read dense documentation, and debug systematically. These skills transfer directly.

The gap is usually in the vocabulary and conventions, not the thinking. Terms like "callback," "state," "async," and "component" feel foreign at first, but the underlying concepts of function composition, data flow, and side effects have direct analogues in how you'd think about a biochemical pathway or an experimental protocol.

Where scientists often struggle early on: tolerating ambiguity in the problem statement. In the lab, you usually know exactly what you're measuring. In software, the problem is often underspecified, and figuring out what the right problem is can be harder than solving it.

Building Your First Real Thing

The advice I give to anyone making this transition is simple: pick something real and build it.

Not a tutorial project. Not another todo app. Something you actually need, or that someone you know actually needs. The motivation matters enormously. You'll hit walls, dependency errors, confusing documentation, the JavaScript date API, and motivation is what gets you through those walls at 11pm when you've been stuck for two hours.

My first real project was a dashboard for lab inventory tracking. Embarrassingly ugly. Barely functional. Full of bugs I only found months later. But it was real, people used it, it saved real time, and maintaining it taught me more than any course would have.

The second project was better. The third was better still. That's how this goes.

What Makes a Good Learning Project

The best learning projects have a few characteristics:

• Defined scope — You know when it's done. Infinite projects are motivation traps.
• Real users — Even if it's just you. Using your own software surfaces problems tutorials never show you.
• Slightly above your level — Enough that you have to look things up constantly, not so much that you're drowning.
• Something you'd be mildly embarrassed not to finish — Social commitment, even to yourself, works.

The worst learning projects are the ones you start because they seem impressive rather than because you care about them. Blockchain voting app. AI-powered recommendation engine. Impressive-sounding, low personal stakes, abandoned by week three.

The Mindset That Actually Helps

A few things from scientific training that have genuinely helped:

Hypothesis-driven debugging. When something doesn't work, don't just try random things. Form a hypothesis: "I think the problem is that this value is undefined before the component renders." Then test it. Then revise. This makes debugging systematic rather than exhausting.

Reading primary sources. A lot of developers rely too heavily on Stack Overflow and random blog posts. The actual documentation, MDN, the React docs, the Next.js docs, is usually more accurate, more complete, and written by people who understand the system deeply. It takes longer at first, but the mental model you build is more durable.

Accepting that you don't understand most of what you're using. In biology, you can sequence a genome without understanding every gene. In software, you can build a working Next.js app without understanding every part of the runtime. Comfort with partial understanding is a superpower.

The Part Nobody Warns You About

The hardest part of learning to code, in my experience, isn't the technical content. It's the psychological adjustment to constant incompetence.

In science, you spend years becoming competent in a domain. Switching to software means starting over, the beginner frustration, the imposter syndrome, the sense that everyone else already knows things you don't. This feeling doesn't fully go away, but it does become a lot more tolerable once you've worked through it a few times and internalized that it always precedes growth.

The developers I've learned the most from are comfortable saying "I don't know how that works." Not as an excuse to not find out, but as a starting point, free of the anxiety that admitting uncertainty somehow reveals inadequacy.