When I was an undergraduate first getting into research, I focused on hiding my lack of knowledge over growing from my confusion. I would often nod along while my supervisor said things I didn’t understand¹. I would fool myself into thinking that I could figure it out from context. I didn’t, since these were technical matters. I suspect that the mental structure my supervisor had in mind differed greatly from my own.

Insecurity held me back as a scientist. I didn’t want to expose my lack of understanding, and if I did think I understood, I didn’t want to check, because that meant I could have been wrong. I preferred projecting the illusion that I understood, even though in the long run it meant I understood less.

This experience reinforced an important lesson: speaking and writing are easy, but communicating is difficult. It’s one thing to transmit words and ideas, but quite another for the receiver to absorb them and build similar mental structures to your own.

Working on cutting-edge science is fun, but it’s even better when you can do it with a bunch of enthusiastic scientists who push each other to their potential. Having a group of scientists working on a single goal means its easier to move past barriers that might have blocked a scientist working on their own. Even better, each researcher in a collaboration brings their own skillset, which means a team can accomplish more together than on their own.

Sounds great, right?

But research collaborations are hard work. They don’t form spontaneously, and they take active effort to maintain. Research collaborations can bring a lot of forward momentum to a question, but it’s also easy for things to fall by the wayside, dissolving into nothing.

I wanted to highlight a few points to keep in mind as you look to jump into your next research collaboration.

When I was a budding graduate student looking for a supervisor and a research direction to pursue, I had little idea of the scientific landscape. I had a bit of research experience as an undergraduate, but not much. I wasn’t sure what to do next.

I began by looking at the websites of several researchers, trying to see if anything excited me. I spoke to some of them about how I was thinking about joining their group in the future.

When it came to talking about projects, they almost always said the same thing: “Take a look at my recent publications.”

This sounds reasonable. Looking at a scientist’s papers should give you a good idea of what research topics the person cares about. But this is a bad idea, particularly for someone with little experience in the field and wanting more information.

The best way to speed up your code is to figure out which parts are running the slowest.

If you spend two hours halving the speed of part A in your code, but part A only takes up two seconds of a minute computation, you’ve shaved off one second. On the other hand, if you spend a few hours halving part B which contributes to the other fifty-eight seconds, then your computation time is only 31 seconds now, almost a 2x improvement.

This is why saying, “My code sure is running slow” is true, but useless.