A note before we start: this is my first attempt at writing down what research means to me, and I hope it won’t be the last. I’m early in my career, so some of this may read as naive in a few years. That’s partly the point. I want to come back, write the next version, and see how the answer has changed. Until then, take it for what it is: an honest opinion, not a verdict.
The word research arrives dressed up. It sounds like conference badges, grant numbers, and a PDF with two columns and a lot of Greek. (The Greek appears to be mandatory.) That is where research ends up. It is not what it feels like from the inside.
From the inside, research mostly feels like a bench at night: a question you cannot put down, a measurement that disagrees with you, and a notebook full of things that are half true. This post is about that part, the part nobody photographs, using the work on this site as the specimens.
It starts with an itch
The most honest research question I have asked was not planned. A Bluespec build at work had been running for fifteen hours and had eaten 64 GB of RAM, on a module with about ten thousand interface signals that we knew had no real scheduling conflicts.1 The full story, with the fix, is in Scheduling, ILP, and a Bluespec Bug That Ate 64 GB of RAM. Nothing sharpens curiosity quite like a progress bar that has stopped pretending.
At first the question was how do I make this stop. That is engineering, and it is a fine question. But somewhere around hour ten it turned into a different one: why does a scheduler that is provably correct become unusable at this size? That shift, from “how” to “why”, is the moment research begins. The bug stops being an obstacle and becomes a specimen.
Curiosity is not a personality trait you either have or lack. It is a reflex you can train: the habit of noticing when something surprises you, and refusing to let the surprise go unexplained.
Make the question small enough to answer
The second instinct, after the itch, is to make the question enormous. How should hardware be designed? Can a compiler decide what to put in silicon? These are the questions worth a career, and they are useless on a Tuesday afternoon.
When I started macro_gen, the first entry was deliberately tiny: one cell, an inverter; one objective, its switching threshold; one process, SKY130. That felt almost embarrassing to publish. It turned out to be the most useful constraint I set, because a small question can actually be finished, and a finished small answer tells you which big question to ask next.
Research is a ladder of small questions. Nobody climbs it by staring at the top; mostly you just get a stiff neck.
Measure before you believe
Every model is a story we tell about the world, and stories are persuasive, especially the ones we wrote ourselves. The only antidote is measurement, and the discipline to print the table even when it makes you look worse.
In that first macro_gen entry, the analytical seed landed within a fraction of a millivolt of the target at 0.9 V. It was tempting to stop there and call the model good. Running four more targets showed the truth: the seed never looked at the target at all, it was simply lucky at 0.9 V, and the search window ran out of room at both ends. In the second entry the delay model came in 5 to 24 percent below SPICE on every buffered circuit. Not wrong enough to discard, not right enough to trust blindly. Exactly the kind of number that teaches you something.
The interesting part of a result is almost never where it agrees with you. It is the gap. The gap is the map: it tells you where your understanding ends.
Be wrong on purpose, and in public
Science has a quiet ritual that engineering often skips: writing down what you expect before you look. If you predict, then measure, you can be wrong in a way that counts. If you measure first and explain afterwards, you will almost always find a story that fits, and you will learn nothing. Astrologers have worked this way for a few thousand years, and they are not famous for their error bars.
This is also why I write dev logs as the work happens rather than after it is polished. A log written afterwards remembers the successes. A log written during the work remembers the detours, and the detours are where the understanding lives.2 A good test of a research log: if every experiment in it worked, it is not a log, it is a brochure.
Reading is research too
Not every part of research is new. Much of it is borrowing carefully. My notes on abstract models, the data-flow graphs, sequencing graphs and logic networks that high-level synthesis is built on, are not original results. They are me redrawing someone else’s diagrams, node by node, until I could have drawn them myself. A sequencing graph in a textbook is a figure; one you have rebuilt in TikZ at midnight is a tool. (It is also a lesson in humility. TikZ makes sure of that.)
That is why the notes are allowed to be unfinished. A research notebook is a garden, not a museum. Some entries are a sentence and a promise. That is fine, as long as I keep coming back.
Keep a list of questions, not answers
If I had to give one practical habit, it would be this: keep a written list of open questions, and reread it often. Mine currently includes things like:
- Can physical constraints such as wire delay and congestion be first-class parameters in a hardware compiler, instead of a problem handed to the back end?
- Where is the right boundary between a programmable core and a fixed accelerator, and can a compiler find it from the application itself?
Most of these will not be answered by me. That is not the point. (Well, it is a little bit the point.) The list is a compass. When a bug like the 64 GB build shows up, the list tells you whether it is a nuisance or a clue.
So, what is research?
My working definition, for now:
Research is curiosity with a notebook: a question small enough to answer, a measurement honest enough to embarrass you, and the discipline to write down what you found and what you still don’t know.
It is slow, and it is mostly being wrong, carefully. It looks less like a eureka and more like compound interest: small corrections, a little better each week, until one day the question you started with has quietly become a different, better one.
The paper at the end is just the moment you decide the notebook is worth sharing. The research was everything before it.
This is version one of my answer. Ask me again in a few years; I’m curious which parts I’ll have got wrong. My money is on most of them.