This is a long-term post. It will be updated over time as I learn more about what makes research good.

I’ve been working on research for over a year now and have faced six rejections from various conferences and journals.

This isn’t uncommon in my field, but for some of my AI fellows, it feels like a disaster. After all, going a whole year without a single publication sounds like a nightmare. I felt the same way at first—waiting for reviews made me anxious for months. And when the rejections started rolling in, they really got to me.

When I looked back, I realized that my anxiety could, in part, be attributed to my PhD application, where publications are highly valued for interviewees. Once I decided to accept the offer from CUHK, I felt completely relieved.

Here are some points I believe make for good research:

  • Practical: Research that can be applied in real-world production.
  • Theoretical innovation: Not just a trivial improvement in a narrow area.
  • Depth: Digging deep into a problem and making meaningful progress.

I’m both ashamed and honest enough to admit that one of my earlier projects didn’t meet these standards. But I’m grateful for the experience because it helped me understand what constitutes good research.

Here are some examples that I believe meet those standards:

  • RUDRA: Finding Memory Safety Bugs in Rust at the Ecosystem Scale 1
  • Boosting Compiler Testing by Injecting Real-World Code 2
  • Accelerating Fuzzing through Prefix-guided Execution 3
  • …

I thoroughly enjoy reading these papers. They have inspired me not only in how to write a paper but also in how to create a great project. For someone like me, who plans to continue researching in SE/PL for a long time, coding is just as important as writing. Reaching that level is a long-term goal I aspire to achieve.

(updated at 2025.04.02)

I spent months writing a paper. The exhausting journey taught me one more thing about good research: presentation matters just as much as the work itself.

I was thrilled when I discovered dozens of bugs using the tool I had developed. At the time, I truly believed it was good enough to be used in production. But there was a problem—only my instructor and I could understand what we were actually doing. Without a detailed explanation, it was nearly impossible for others to follow.

I carefully wrote my first draft. Still, my instructor asked me to refine it—layer by layer. That’s when I realized I had made a common mistake: assuming readers already shared some background knowledge. When it comes to presentation, especially in writing, we have to imagine we’re talking to someone who knows nothing about the topic. Then, gradually, we build up the context and ideas, step by step.

And that’s just the writing part. I’m planning to participate in a SRC soon. Along with a potential talk for the paper, it will be my first real challenge in face-to-face presentation. Hopefully, I’ll be able to handle it well.

  1. RUDRA: Finding Memory Safety Bugs in Rust at the Ecosystem Scale ↩

  2. Boosting Compiler Testing by Injecting Real-World Code ↩

  3. Accelerating Fuzzing through Prefix-guided Execution ↩