Research in College: 6 Inspiring Lessons I Learned

When I was touring colleges a few years ago, people seemed obsessed with one question: “Are you involved in research?” Every tour guide mentioned it, every parent asked about it, and every brochure proudly displayed students working in labs. It sounded impressive, but I honestly had no idea what it actually meant. To me, it felt a bit like consulting: everyone talks about it, everyone nods knowingly, but if you ask what it really involves, you get vague answers. I used to think, “What are we even researching?” I have Google; I do “research” there.

That changed this past summer when I had the opportunity to spend ten weeks at Argonne National Laboratory as a DOE SULI intern doing high-performance computing (HPC) research. And suddenly, I began to understand what people mean when they say “research.” It’s not just googling things (though I did quite a lot of that along the way). Instead, it’s a mix of problem-solving, experimentation, and collaboration that pushes the boundaries of what we know and what’s possible.

So… What Did I Actually Work On?

My project centered on integrating AMD’s GPU-accelerated RCCL library into MPICH, one of the most widely used implementations of MPI (Message Passing Interface). MPI is the backbone of distributed computing; it’s what allows thousands of processors across a supercomputer to talk to each other and coordinate work. RCCL, on the other hand, is AMD’s communication library for GPUs, similar to NVIDIA’s NCCL, and it enables high-speed data exchange directly between GPUs.

The goal was to build a hybrid CPU/GPU backend for collective communication, which includes operations like Allreduce, Broadcast, and Gather that allow groups of processes to combine or share data. The design I worked on allowed MPICH to dynamically decide, at runtime, whether to perform these operations on the CPU or the GPU, depending on the size of the messages and the system configuration. For small transfers, CPUs can actually be faster; for very large ones, GPUs have the bandwidth to handle them better.

That might sound like a wall of jargon, and I’ll be honest: I didn’t know what any of this meant when I first walked into the lab. Now, though I’m far from an expert, I can at least explain what I did and why it matters. To make it more concrete, here are a few key terms:

• MPICH: a widely used implementation of a standard for parallel communication that helps supercomputers run programs across thousands of processors.
• RCCL: AMD’s GPU-accelerated communication library, essentially their counterpart to NVIDIA’s NCCL.
• Collective Communication: group operations like Allreduce, Broadcast, and Gather that let parallel programs share or combine data efficiently.

So, in simple terms, my job was to integrate RCCL into MPICH so MPI programs could seamlessly use GPUs for communication, not just CPUs. For my friends who know nothing about CS, I explained it like this:

• On iPhones, the iMessage app supports a lot of functionality like GamePigeon, adding members, message reactions, and high-quality media sharing.
• Once an Android phone joins the chat, the texts turn green and everything basically sucks.
• I’m designed the ultimate “messaging app” (for high-performance computing) that can allow both “iPhones” and “Androids” (or, in my project, CPUs and GPUs) to work together optimally.

This kind of optimization matters enormously for exascale computing. Imagine millions of cores and thousands of GPUs all trying to communicate at once — every tiny bottleneck adds up. My summer project was just one small step toward making that communication smoother.

Learning to Swim in the Deep End

Here’s the thing: even really smart people don’t know what they’re doing half of the time.

When I started at Argonne, I had no idea what any of those words or acronyms meant. MPI, RCCL, collectives, Allreduce. It was alphabet soup that didn’t connect to anything I had learned in class. The first week felt like I had been thrown into the deep end of a pool without knowing how to swim.

I had to learn from the ground up: how supercomputers actually run programs (hint: very differently from running Python on your laptop), why message size thresholds matter, what makes GPU interconnects special, and how to navigate a massive open-source codebase like MPICH. On top of that, there was the daily grind of debugging: chasing segmentation faults, tracing logs that seemed like gibberish, and learning how to test changes without breaking everything else.

It was overwhelming at first, but the people I worked with were patient and encouraging. Slowly, things began to click. I went from barely understanding what MPI even did to being able to explain how a hybrid backend might reduce communication bottlenecks in GPU-heavy workloads. That kind of growth, from complete confusion to meaningful contribution, is what made the experience so rewarding.

I also became incredibly comfortable with asking “dumb” questions. Remember: these professors and research scientists have spent decades studying incredibly specific topics that even most people in their own field don’t care about. They don’t expect you to know everything. In fact, they’re usually thrilled to answer questions. If you really want to get a scientist talking, just ask them about their niche. They love it.

If you’re interesting in reading my report or my poster from the internship, check them out here and here.

Choosing Research Over Industry

I almost didn’t do this internship.

I also had an offer for a software engineering internship at a reputable company. It came with higher pay, a clear trajectory, and the kind of name recognition that would look good on a résumé. For a while, it seemed like the “smart” choice.

But then there was Argonne. Argonne had Aurora, one of the fastest exascale supercomputers in the world. I had the chance to be part of something completely unique and much more niche than a traditional internship. I had to decide between the safe, established path and the less conventional one that promised a steeper learning curve and, potentially, a more memorable summer. In the end, the idea of contributing, even in a small way, to a system like Aurora was too intriguing to pass up. And I don’t regret that choice.

The Human Side of Research

One thing I wish someone had told me earlier is that research isn’t as intimidating as it looks from the outside. The hardest step is often just sending an email or submitting an application. I applied to Argonne with minimal computer science coursework, zero research knowledge, and much less experience than many of my peers. I thought my lack of qualifications would disqualify me immediately.

But when two researchers at Argonne reached out after reading my application, neither of them mentioned my GPA or my technical background. Instead, they both brought up the fact that I’m a dancer, something I had written about in my essays. 

One of the computational scientists at Argonne wrote in her first email to me: “Looking at your interests and the skills you have developed as a ballet dancer, I think that you would enjoy working on this project.”

That was what stood out: my interest in (note: not experience with) HPC and my dance background. It reminded me that research isn’t just about skills you’ve already mastered. It’s about curiosity, creativity, and the perspective you bring. Sometimes the most “unrelated” part of your story is what makes you memorable.

The Lessons

1. You don’t need to know everything to start. Most researchers begin by feeling lost. Growth comes from diving in, asking questions, and learning along the way.

2. The learning curve is the reward. Progress often looks like going from “I don’t get any of this” to “I can (kind of) explain it to others.”
3. Asking questions is a strength. Curiosity, even asking “dumb” questions, drives discovery and builds understanding.
4. Unique perspectives matter. Your background, interests, and creativity can make you stand out as much as technical skills.
5. Choosing research means choosing curiosity over certainty. It’s less about immediate payoff and more about exploring what hasn’t been figured out yet.
6. Uncertainty is part of the process. You don’t need a fixed career plan. Research is about exploring possibilities and finding what excites you.

Figuring Out the Future

So, what’s next? Did this experience tell me whether I want to build a career in academic research or head into industry? Not really. I still don’t know what path I’ll take long-term, and that uncertainty used to feel scary. But now I see it differently. This summer showed me that I enjoy research, that I like the challenge of tackling problems no one has solved yet, and that I can find my footing even in intimidating spaces. That’s enough for now.

This semester, I’m excited to be continuing my summer work with Argonne National Laboratory, while also working on a new systems-related project with UChicago. I’m also exploring research options here at Columbia, and I can’t wait to see what the future holds.

People sometimes look at me and say, “Wow, she’s so accomplished,” but the truth is that I’m still figuring it out like everyone else. I make choices, I learn from them, and I keep moving forward. That’s really all anyone’s doing.

Final Thoughts

If you’re a student wondering whether you should try research, my advice is simple: don’t let the word scare you off. It isn’t some exclusive club where you need years of experience before you’re allowed in. It’s just people working together to figure out things no one fully understands yet. You don’t need to know everything to start. You don’t even need to know what you want your future to look like. All you need is curiosity, the willingness to learn, and your unique perspectives.

That’s what research really is: not having the answers, but being willing to look for them anyway.