How to Start a Research Work

Everyone keeps telling you to "get into research." Read papers. Run experiments. Publish. But almost nobody tells you where the first step actually is. When I started, the hardest part wasn't the math or the coding - it was the blank page. I had energy, I had curiosity, and I had absolutely no idea what to do with either.

So this post is the note I wish someone had handed me on day one. It's not a rulebook. It's just how I've learned to begin.

Everything starts with a problem

Here's the thing nobody says out loud: research isn't about knowing answers. It's about noticing questions.

If you can find a genuine problem - something that doesn't add up, something that annoys you, something everyone accepts but nobody has explained well - then you already have a direction. Once a problem exists, everything else has somewhere to point. Your reading has a purpose. Your experiments have a target. Your late-night "what if" thoughts finally have a place to land.

Without a problem, you're just collecting facts. With one, you're doing research.

How do you know you've found a real one? A few signs I've learned to trust:

• It keeps coming back - it has annoyed you more than once
• You can say it in one sentence, without hand-waving
• The existing answers feel unsatisfying once you actually read them
• You catch yourself thinking about it when you're supposed to be doing something else

A good problem is worth more than a clever method. You can always find a method later. You can't fake a problem worth solving.

My first real read: Attention Is All You Need

The first paper I ever properly read - not skimmed, read - was "Attention Is All You Need" by Vaswani and his co-authors at Google, published in 2017. It's the paper that introduced the Transformer, the architecture behind pretty much every large language model you've used.

But here's what surprised me. When I finally understood it, the thing that stuck with me wasn't the equations. It was the thinking. I kept asking myself: how did this idea even show up in someone's head?

So instead of just studying what they built, I tried to reverse-engineer how they got there.

Back then, sequence models like RNNs and LSTMs read a sentence the way you'd read through a straw - one word at a time, in order. That created two real headaches. It was painfully hard to parallelize, because word 10 had to wait for word 9. And over long sentences, the model kept losing track of things it had seen far back.

Attention already existed at the time - but it was mostly a little helper bolted onto those recurrent networks. It assisted the main model. It wasn't the main model.

And this is the moment I find beautiful. The authors looked at that setup and asked a question that sounds almost reckless:

What if attention isn't the helper? What if attention is the whole thing?

They didn't invent attention. What they did was correctly identify the real bottleneck - the recurrence itself - and then had the nerve to throw it out entirely. The title isn't a slogan. It's literally their thesis, stated as plainly as possible: attention is all you need.

Here's how I picture that leap:

The lesson I took wasn't "learn attention." It was this: breakthroughs usually come from someone naming the real problem, not from someone inventing a brand new trick. The trick was already lying around. The insight was seeing what to remove.

That completely changed how I read papers. Now I don't just ask what did they do? I ask what did they notice that everyone else walked past?

Once you have a problem, draw a roadmap

Finding the problem is step one. But a problem without a plan just becomes anxiety.

So the moment I have a problem I care about, I sketch a rough roadmap - the whole path from "here" to "hopefully an answer." It's messy. It's usually wrong in places. That's fine. The point isn't to predict the future perfectly; it's to give my future self a thread to follow when I inevitably get lost.

The shape of it is always the same:

See that line climbing back up the right side? That loop is the most honest part of the whole diagram.

Your roadmap is a draft, not a contract. You will change it. An experiment fails, a paper points you somewhere better, a small result opens a door you didn't know was there - and the plan updates. That's not you failing to plan. That's the plan doing its job.

If it helps, here's how I loosely think about the phases early on:

Every row loops back to the top. That loop is the research.

And honestly? Day one of every project I've started looks embarrassingly similar:

$# day one, every single time
$mkdir why-does-this-work && cd why-does-this-work
$git init
$echo "# The question I'm chasing" > NOTES.md

No framework. No cluster. Just a folder, a question, and a notes file.

If I had to compress this whole post into something a compiler would accept, it would be this:

// research, written as the loop it actually is
while (curious) {
  const problem = notice(whatBugsYou);
  let plan = sketchRoadmap(problem);      // a draft, not a contract

  while (!solved(problem)) {
    const result = runExperiment(plan);
    plan = revise(plan, result);          // failure just updates the map
  }

  curious = true;                         // every answer ships a new question
}

Notice there's no exit condition. That's not a bug.

The first step is smaller than you think

If you're staring at that blank page like I was, don't try to find a world-changing problem today. Just find one thing that genuinely bugs you - one paper whose reasoning you want to understand, one result that feels too good to be true, one "why does everyone do it this way?"

Pull that thread. Sketch a rough plan. Let the plan change.

That's it. That's how you start.

Research isn't a leap. It's a loop - and you only have to take the first small step into it.