Why I Start Things Uncomfortably Early
Over time, I’ve developed a habit that feels wrong: I start writing, integrating, and testing way earlier than seems reasonable. When I have just the first “signs of life” in a project, I’m already drafting paper sections. When my code modules are 70% done, I’m already trying to wire them together.
This goes against the instinct to wait until things are “ready.” But I think there are good reasons for doing it this way.
Ambitious research has a fundamental difficulty: rewards are sparse and delayed. I won’t know if my approach works until months in, when I finally have the complete system and results. But I need to make decisions now: which direction to explore, which component to prioritize, what to try next.
This is essentially the credit assignment problem from reinforcement learning. When the signal (the discovery of a new method, a successful validation) is very far away, how do I navigate?
The Working Memory Problem
I can only hold about 4 things in working memory at once. When I’m juggling 15 design decisions and vague intuitions about what might work, most of it is slipping away. I need concrete signals.
Writing and sketching force me to make things concrete. Writing is thinking. When I try to draft a results section for experiments I haven’t run yet, I immediately hit questions: “Wait, what’s the y-axis here? How would I actually measure this?” Those questions become my experimental plan.
Similarly, when I integrate code modules before they’re polished, the failures tell me what actually matters. Often the “polish” I was planning turns out to be unnecessary. And the failures tell me what actually matters.
What I Actually Do
- I start writing paper drafts at the first signs of life. Playing with different introductions helps me figure out which story actually makes sense. Sketching figure layouts exposes which experiments I’m missing.
- I wire together code modules when they’re partially done. The integration failures are informative.
- I run simplified experiments first—1000 examples instead of 1M, 2 layers instead of 12. I can add complexity once I know the direction has promise. This is to maximize research velocity.
- I submit to workshops before papers feel “fully baked.” The writing process and feedback catch blind spots.
- I share half-baked ideas. A conversation can save months of heading the wrong direction.
Pride vs. Progress
These practices aren’t technically hard. What makes them difficult is the discomfort of showing work that isn’t impressive yet, of risking visible mistakes, of accepting that my initial intuitions might be wrong.
But I’ve noticed that waiting for things to feel “ready” often means operating in the dark for too long. The cost of being wrong in private—spending months on the wrong path—tends to be much higher than the awkwardness of being wrong in public. And if we talk about spending public research money, we should minimize this cost.
How Fast Is Too Fast?
There is a limit, of course. If I’m moving so fast that I can’t reproduce last week’s experiments or I’ve lost track of what I’ve tried, I’ve gone too far. Clean experiments matter even when iterating quickly.
But I find I’m rarely limited by going too fast. More often, I’m limited by waiting too long—by postponing the test that would have given me signal.
So now when I catch myself thinking “this isn’t ready yet,” I try to ask: ready for what? Often the answer is: ready to learn something from. And that bar is much lower than I think.