Ten years ago this month, I was a 20-year-old PhD student sketching out the plan for what would become my first first-author paper.
Ten years later, I've published over 160 papers and I'm an associate professor at Harvard running a lab. I've mentored hundreds of students on their very first paper. With every one of them, I get to think about what actually matters for doing great research—not the credentials or the pedigree, but the capabilities you can actually develop.
The same three skills matter for paper number one as they do for paper number one hundred: execution, problem selection, and framing. This is my attempt to write them down.
The first capability: knowing how to build. Can you actually make the thing? Do you know what's feasible versus what's fantasy?
Execution isn't about brilliance. It's about reps.
In AI, this means the fundamentals—machine learning, systems, algorithms. You learn these through courses and practice. I learned a lot from coursework early in my PhD. But the real learning happens differently.
I had a peer in grad school—an exceptionally skilled programmer—who read code every morning. Not wrote. Read. Popular repositories. Reference implementations. Line by line, every day.
Reading code teaches you what reading papers can't. Papers describe ideas. Code reveals whether those ideas actually work.
Over time, they developed a sense for whether a method description was implementable or hand-wavy. This intuition is irreplaceable.
Another habit I picked up from a collaborator: write code every single day. No exceptions. Even if just refactoring. Even if just adding comments. Something got committed daily.
I adopted this practice. Looking at my GitHub, I've tried to follow this for a lot of the year. The continuity matters. The compounding works like this: daily code → continuous progress → faster completion → more practice → better at coding → even faster next time.
Beyond code, documentation compounds too. Another colleague wrote everything down after every meeting and work session. Everything. Not just "experiment X got accuracy Y"—the hypothesis before running it, observations during, interpretations after, what to try next and why.
When things worked, they knew exactly why. When things failed, they knew what to try next. Writing the paper took 2 weeks because all the content was already there.
Documentation isn't overhead. It's pre-writing your paper.
These daily habits matter, but so does knowing when to cut your losses. Pay attention to early signals. When something starts working in the first couple weeks—even imperfectly—that positive momentum usually carries through. Projects that show early promise tend to work out. Projects that don't often stay stuck.
I've spent months on projects that never showed early promise—time I could have redirected sooner. Get something working first, then improve it. A simple baseline that runs end-to-end beats a sophisticated method that's half-built. You can iterate from working code. Starting from nothing is brutal.
The same principle applies to how you structure your work. Think modularly. Break problems into components. Solve each piece independently. Compose them. Debugging becomes easier. Code becomes reusable.
Infrastructure matters more than you think. Early projects: hacky scripts, results scattered in random folders. This doesn't compound. Later: reusable components, systematic organization. Every time I write code, I ask: will I need this again? If yes, make it reusable now.
Over time, you build intuition for what will work. Not certainty—intuition. This is taste for execution developing.
That first paper I started sketching out ten years ago? The Stanford Question Answering Dataset. Over 10,000 citations.
But execution alone isn't enough. You can build perfectly and still build the wrong thing.
Last updated: 12/17/2025