I’ve been working on my current research project for around four to six months. The results haven’t been that good. I have a meeting about it tomorrow, and I’d say there’s about a 50-50 chance we decide I should stop working on the project and switch to another one. If it ends that way, well, that sucks. But after reflecting on it for a while, I think I’m mentally prepared for that outcome.

In preparation for that meeting, my manager recommended I write a document describing what the project is, how it got to where it is now, and all the things I tried along the way. I agreed this was a good idea, although I was starting to get sick of explaining my project. In the past, I wrote a doc when I proposed the project, then made a presentation after it got refined, then wrote another doc when I pivoted. Ironically, all that documentation made it hard to figure out where the project was, because each doc built on the previous ones.

From a naive viewpoint, writing a summary shouldn’t have taken that long. I’ve been living and breathing this project for months, and I had already written several documents on the project. How long could writing one more take?

Well, turns out it took me about a day. That’s actually not too long, all things considered, but why did it have to take that long at all? It was only summarizing things I’d already written.

The tricky part of research is that the author is trying to take these grand ideas, that have never been arranged the way the author’s arranged them, and then he or she needs to convert them into text that gets the point across.

Yasha Berchenko-Kogan (who I actually kinda know in real life) has a great quote about communicating research.

Communicating these ideas is a bit like trying to explain a vacuum cleaner to someone who has never seen one, except you’re only allowed to use words that are four letters long or shorter.

A lot of the metaphorical four letter words I used weren’t useful anymore, and filtering it to just the key points was most of the work.

When I got comments back, I had a shocking revelation: the only one who fully understood my project was me.

On the surface, that’s not so surprising, so let me clarify. I’ve been talking to most of these people about my project for months. They’ve received and read every doc I wrote about my project, from start to finish. I’ve had weekly meetings with several of these people, to explain issues I ran into and get tips on how to get past them.

And the whole time, I was the only one who understood everything that was going on?

What the hell?

I used to think good writing was important because nobody wants to extend research that’s hard to understand.

But now I’ve realized there’s another big benefit. If you want people to give useful feedback, it’s very important they actually understand what the problem is.

I’m about to describe one of those ideas that’s obviously true. Are you ready? Okay, good.

When people say “That sounds good to me”, they’re implicitly saying “Based on my understanding of the problem, that sounds good to me.” Worryingly, if they missed a few details you tried to convey, their brains will fill in the details by themselves. And the details they fill in will be ones that make sense to them, which likely differs from the details you were trying to convey in the first place.

The relevant point: if you ask for help from your advisor, and your problem is in one of those details you failed to convey, you’re not going to get good advice.

If you yourself are a researcher, and this was a new idea for you, read over it a few times. I think it’s worth knowing.

In hindsight, the biggest shifts in my research didn’t happen when I had a new idea. They happened when experienced researchers finally grasped a detail I thought they’d already understood. They would then immediately make an obvious argument for why doing it that way was dumb, and then I’d feel like an idiot.

If everyone’s busy climbing your chain of reasoning, they won’t notice the weak links, because they’ll assume all the links make sense.

That suggests two things:

  • Prefer simple solutions over complicated ones. Complicated solutions are hard to explain, meaning it’s harder to get good feedback, and complicated solutions are the ones that need feedback the most.
  • If you do need to use a complicated solution, be very, very careful that you understand why you’re doing everything you’re doing, and that the reasons you made up four months ago still make sense in the present.

If I had explained my research project better, I could have saved a few weeks of work, because I could have avoided a lot of silly ideas that weren’t worth doing in retrospect.

Research miscommunication is inevitable. It takes a long time to explain things properly, and usually people don’t have the time for that. I suspect that’s the main reason research takes so long - it’s the blind leading the blind. Sometimes the blind one is you. Sometimes it’s someone else. It’s hard to tell the difference.

If the pattern holds, people aren’t going to understand everything I wanted them to understand from this post. Oh well. I tried.