I wrote my first program at nine. It made me a better biologist.

I started writing code when I was nine or ten. Nobody taught me. I wanted the computer to do something it did not do yet, and the only way to get there was to learn how it thought. Most of what I wrote in those years was small and forgettable. What stayed with me was the habit.

The habit of breaking things down

A program does exactly what you tell it, nothing more. If it fails, the fault is somewhere in your instructions, and you find it by splitting the problem into pieces small enough to check one at a time. That is the most useful thing coding ever taught me, and it turned out to be the core of experimental biology too.

When an experiment fails, the instinct is to blame the cells, the reagent or bad luck. A programmer’s instinct is different: isolate the step, add a control, run it again, change one thing. I brought that instinct into the lab long before I had words for it.

Biology became a data problem

When I started graduate school, a single mass spectrometry run on yeast could produce thousands of protein and lipid measurements. Spreadsheets break at that scale, and so does patience. Writing my own analysis scripts in Python let me ask questions of the data that the standard software did not offer, and redo an analysis in minutes instead of days when a reviewer asked a new question.

The experiment produces data, and the person who can shape that data is the person who can see what it means.

Later, the same applied to flow cytometry, live-cell imaging and dose–response curves. The instruments changed. The pattern did not: the experiment produces data, and the person who can shape that data is the person who can see what it means.

Code as a lab notebook

There is a quieter benefit. A script is a precise record of what you did. Every filter, every normalization, every threshold is written down. If I come back to an analysis a year later, I can rerun it and get the same answer. In a field that worries a lot about reproducibility, that matters more than any single result.

What I tell students

Students often ask whether they need to learn to code to do biology. My honest answer is no, but it helps more every year. You do not need to become a software engineer. You need enough to automate the boring parts, check your own numbers and talk to the people who build the tools.

Start with one real problem from your own work, something you do by hand every week. Automate it badly. Then make it better. That is how I learned at nine, and it is still how I learn new tools today.

The two halves of my working life used to feel separate: biology on one side, software on the other. They no longer do. The most interesting questions I work on now sit exactly where they meet.