Research Reflections /

Lessons I Learned During My Undergraduate Research Internship

• June 27, 2025
• notes  
• advice  
• lists  
• education  
• learning  
• university  
• academia  
• research  

Disclaimer: I am a computer science student and all my research experience is in math (graph theory + data science) and CS (network security). I have no idea how things work in other disciplines.

I really meant to put this list up sometime last fall… whoops. (This is yet another incredibly overdue article.) Anyway, here are a whole bunch of things I learned while attempting to “do research” last summer, whatever that means. The big theme here is to make life easier for future you, who will have to wrangle together your several months of chaos and exploration into a rigorous and coherent narrative. Present you can help by being organized and breaking things down into smaller, documentable steps.

I. On actually doing the research

1. There are no shortcuts to learning things.

There are no shortcuts to learning – you need to put in the work and the hours. I have learned this so many times in so many different ways and I keep coming back to it.¹ This has become one of my mottos.

2. Having language to describe what you are doing is good.

Seriously, specific language (aka jargon, in some circles) can be useful – it speeds up communication and allows your brain to chunk information better, freeing up space to make progress on other things. If you don’t believe me, consider this: can you imagine if every time we referred to the colour green, we instead had to call it “the colour that deciduous tree leaves turn in the summer?” Therefore, the faster you can pick up the vocabulary others in your area are using and use it too, the better. If you stumble upon something new and find yourself repeatedly explaining it, give it a temporary name and write down a definition for it somewhere. Eventually you might find out that a name for that concept already exists. Or you might be the first to name it, in which case, props to you!²

3. Stop avoiding technical tasks that seem difficult.

Do not be afraid of getting your hands dirty with “technical” work. Learning new tools or a new programming language or a new software may seem somewhat intimidating,³ but that is the easy part. The difficult part is actually the thinking required to solve your problem, but that’ll be easier once you start doing things. Actually, it’s impossible to do that sort of thinking well if you aren’t also getting your hands dirty with the tools.

I read somewhere that procrastination is a fear response. I think this is pretty accurate. (Actually, you can probably guess exactly how apprehensive I feel about doing something by how much I procrastinate doing it. I am horribly bad at following my own advice when it comes to this.)

4. A slight shift in perspective can be incredibly helpful.

It’s not just thinking about problems, it’s also about how you think about them. Sometimes, relaxing some assumptions and trying to solve a smaller problem, or an easier problem can work. Sometimes, slightly shifting your approach can work. Really, you just try a bunch of slightly different but related things and hope one of them works; and sometimes you need a mostly unrelated thing, and you only realize that by accident (or by trying enough things).

5. “Tools don’t matter” is a lie.

Choosing the right tools to do your work is incredibly important. For example, if your research involves any sort of programming, choosing the right language can go a long way toward making your life easier, and choosing the wrong language can make your life hell.⁴ Some tools are better for fast prototyping; others really shine in production environments. And I know some of you will hate me for saying this, but sometimes the best tool for the job is a spreadsheet. Don’t overcomplicate it.

6. Quick-and-dirty solutions can become problematic at scale.

Things that are “negligible” at a small scale can suddenly become very significant at a large scale. What I mean by this is that a small inefficiency that might not even get noticed while working with a toy example dataset can become a massive bottleneck once the dataset is big enough. Cutting corners at scale is a nightmare waiting to happen.

7. Reading academic papers requires you to read between the lines.

Academic papers are horribly incomplete and are almost never self-contained, and reading them for deep understanding is a very active, as well as iterative process. You cannot expect to read a paper by itself and understand everything that was done and explained. You will likely have to do some grunt work and experimentation yourself, read some adjacent papers, read some background texts, talk to people, acquire the data used… that being said, aiming to fully understand every single paper you read is probably overkill.

8. Keep detailed notes on what did and didn’t work.

One of the habits I’ve adopted is spending anywhere from 5 to 40 minutes doing a brain dump semi-periodically. This brain dump generally included what I’ve been doing recently (or that day), what is working, what isn’t working, how I feel about the status of the project, how my meetings are going, any ideas or potential solutions to problems I might have, and some good old-fashioned venting. It can be hard to justify writing these notes, since they are 100% not intended for anyone else to read and are usually at least 30% ranting,⁵ but they really help clear my head, identify what is going on, and pinpoint areas of confusion.

I think it’s really important to take some time to do some self-reflection when working on these sorts of projects, since taking a step back to assess what is happening can prevent you from wasting time on something that clearly isn’t working. I also find that writing helps me think more clearly, so that’s another excuse to do the brain dumping. Sometimes I only understand what I’ve been doing as I’m writing the brain dump.

Plus, it’s just a great resource for future you. Documenting your frustrations will help you avoid them in the future; documenting your successes can help you figure out how to repeat them.

9. Write as you go.

I talk about this a lot more extensively here, but the key idea is that if you want to make sure the important thing you just thought of makes it into your future report, write the section (or at least, a sketch version of it) asap, before you forget, because future you will probably not remember. The more stuff you write while you’re still working, the better luck you’ll have with writing a complete and accurate report (or paper, or thesis, or whatever) at the end. It also reduces the cognitive load you have to walk around with if you know that you’ve been writing your insights down as they come to you. Last year, around when I was doing my writeup, I felt like I was carrying way too much information in my head at all times, and I didn’t know how to deal with it. It’s really easy for important information to slip your mind when you’re in that state.

II. On making the most of your time

10. Try the “dumb” (or rather, obvious) idea first.

When coming up with a solution to a problem, forget about trying to get the optimal solution at first. Even if you think the first solution you come up with is crude, bad, and likely not optimal, it is worth trying that first. Why? Because it gets you going, you’re less likely to get stuck later on if you have something to work with, it helps you “own the problem” a little bit, and you might learn a few things, come up with new ideas, or rectify misunderstandings of the problem in the process. Along the same lines, it can be useful to solve special cases of a problem or toy examples before attempting to tackle a huge problem.

11. It is hard to strike the right balance between reading and doing.

Sometimes to move forward you need to read more to get background knowledge; sometimes you need to mess around with toy examples and get your hands dirty; sometimes you need to actually work on the problem you are trying to solve. So when are you supposed to switch between the approaches? I don’t know. I’m still figuring that out.

12. Try to do something every day, even if it is small.

One of the things I found while working on my research was that keeping the project in my head was really important for making progress, because it meant my subconscious could work on stuff while I was off doing something else. If I strayed away from the project for too long, I would totally lose the thread of what was going on, and it could take a few weeks to rebuild the big picture of what I was trying to do in my head again. Especially when you’re close to making progress with something, it can feel like you’re holding a very delicate chain of information or events in your brain that you really can’t afford to have collapse. (The writing up stage can also feel like this.)

The best way to avoid losing the thread of the project, then, is to avoid taking a break from it for too long, which means trying to do something related to it on most days.⁶

Personally, I have adopted a list of what I like to call “too tired to function tasks”, which are things I can work on when I feel the need to continue to make progress but don’t actually have enough energy to do something that uses my brain. Some examples of such tasks I’ve had in the past include:

• making figures or editing figures to look pretty
• organizing my notes
• transcribing handwritten notes so that I can search them later
• finding articles to read later
• formatting documents
• planning tasks, such as making sketchy outlines
• writing a braindump of everything I can think of related to the project
• any sort of grunt work-type task I’d avoid doing under normal circumstances

I’m not advocating for working constantly, and there were still days where I legitimately did do nothing. But having a list of things you can do when your brain isn’t functional is still a really good idea, and can help avoid stagnating for too long. Do the tedious stuff while you’re tired so that you can do the real thinking when your brain is awake.

13. Time management is a nightmare.

Yikes, time-management. See, one of the fun things I learned about working on a large project, by myself, with dubious guidance, was how to make myself do things and make progress. Time management is both about figuring out how to divide up your work and organize your time in a productive way, and it will be your undoing if you don’t figure it out sooner rather than later. If you’re like me, and are prone to only getting stuff done close to a hard deadline, this is a bit of a problem. You absolutely cannot leave everything to the last minute and succeed – working on things incrementally leaves you with time to get help, make connections between different ideas, explore, go on tangents, etc. – all of which are necessary for making progress. I eventually realized that if I couldn’t find a way to motivate myself to keep making progress, I was going to fail. Figure out a system or framework for keeping yourself on track and use it.⁷

14. Try to avoid burnout.

Burnout makes doing anything else impossible and it can take a very long time to recover from it. Try to take breaks; make sure you have some way of unwinding from doing work, or your brain will forcibly unwind for you, often for days or weeks at a time.

15. Try to carve out longer chunks of time for focused work.

If you haven’t heard of the idea of “maker’s schedules” and “manager’s schedules” and the differences between them, go read Paul Graham’s essay about the subject. Research, like many other creative activities, is fundamentally best done on a maker’s schedule. The problem with doing research is that you’re often solving hard problems, and you need the appropriate amount of time to sink your brain into the headspace for making progress. If you keep not leaving yourself long enough blocks of time to meaningfully do anything of substance, you’re going to find yourself avoiding your project. This is especially true during the beginning stages of a project, since overcoming the initial inertia to get the ball rolling takes quite a bit of warming up, time, and effort.

16. Beware of assuming that a task is going to be simple.

This isn’t just advice for research: this is life advice, period. I’ve heard project managers complain about getting burned by assuming their projects wouldn’t be complicated. However, this bears paying special attention to in a research context, because by definition, research involves trying to uncover or create something new, and doing new things is almost never simple.

Anyway, this is another of my new mottos. I have nothing else to add. I’ve gotten burned by this assumption so, so many times…

17. There is no such thing as “done” in research.

Like artistic projects, research isn’t ever finished, it’s abandoned when it’s “good enough.” There’s always some other rabbithole, some new thing to investigate, or some new issue you need to get to the bottom of and fix, and sometimes you have to make a call to ignore some of those things and wrap up the project in a semi-coherent manner. It feels a lot like writing in that way. In fact, it feels a lot like writing (or like a self-directed personal project) in pretty much every way that matters, except for the fact that you have a supervisor, and have to deal with everything that comes with having a supervisor.

III. On file management (incredibly underrated and important)

18. Having organized notes is KEY.

I’m naturally a mildly scattered person, so I used to solely rely on external structures to keep me organized – if I was following a book, I would use its chapter structure as a guide; if I was taking a course, I would use the course’s chronological organization as a guide; otherwise, i just kept things in vaguely chronological order and hoped for the best.. When doing research, you have to organize things yourself so that future you will have a chance to make a sense of them and make connections between ideas. Make sure you put notes where you can find them - practice good file management. Name your files appropriately and date them when you can. Group similar files together when it makes sense.

If you’re like me, and are used to a mostly analog existence, it may be useful to start typing your notes so that they’re searchable and easy to reorder and find. Paper is great and wonderfully tactile, but trying to stay organized with paper is a nightmare. Also, paper is very heavy, and carrying around several notebooks isn’t always ideal. But as far as I’m concerned, the biggest problem with paper notes is that it takes extra effort to transcribe them or quote from them. One of the best ways to speed up writing a report is to copy and paste from your research notes verbatim. ⁸

19. Use version control, you idiot.

On a related note, BACK UP YOUR FILES, you idiot.

20. Markdown is a great format for note-taking.

Word processors are too bloated, text files are too barebones, and LaTeX markup is too time-consuming. Markdown is a great in-between, especially if you use an editor that supports displaying math using short LaTeX snippets. Markdown literally changed digital notetaking from an annoying process I wanted nothing to do with to an efficient and occasionally enjoyable one.

21. Printing out every paper you might want to read is probably a terrible idea.

Okay, I know I’m old-fashioned and probably no one else cares about this. But if you are like me and prefer to print things out, just realize that trying to print out every paper you want to read will be a massive waste of paper. It’s okay to print out a paper if you really need to understand it and it’s going to be your life for a while. But otherwise? Not really. Lots of papers don’t even need to be read in detail, just skimmed for general awareness or extra background. Do yourself a favour and notate them on a tablet if you really need to.⁹

22. Try not to lose track of the papers you read.

I talked a bit about this here. The last thing you want is to realize that the random idea you found in some paper you skimmed is probably useful and important for your project, but have no idea where to find it. Sane people use a citation manager to avoid this situation; not so sane people (aka me) dump relevant links to things in designated markdown files.

23. If you find a useful tool or dataset, download or archive it immediately.

Things don’t stay on the internet forever. When I was working on this project, the repository containing all of the data I wanted to use went down randomly in the middle of the summer and took a lot of the data I was interested in using down with it.¹⁰ I had already designed all of my code to run on data formatted like the data I’d downloaded from the site, so it created a lot of extra work for me: I had to find new sources of data, and then, I also had to convert them into a format that matched the old datasets. I wish I’d just downloaded the appropriate data as soon as I found it. It would have saved me so much effort.

IV. On interacting with other people

24. You need to have initiative - no one will just give you things, including help.

I actually wrote an entire blog post about this, called You Need to Be Proactive. People will assume you don’t need help unless you ask for it. People won’t realize you need resources unless you ask for them. People will assume you understand things unless you ask them questions. People aren’t just going to tell you about opportunities – you’ll have to seek them out yourself. Learn to ask about things and put yourself out there; the worst you can get is a no or a rejection.¹¹

25. Talking to other people can be very helpful.

If you’re stuck, talking through your problem with a friend or colleague can be helpful. In the worst case scenario, you at least gain a clearer understanding of your problem by having to break it down for someone else. In the best case scenario, you either figure out the solution on your own during the conversation, or the person you’re talking to offers a promising new avenue that shifts your perspective a little bit.

26. Doing a presentation? Find a “victim”¹² to help you practice.

Practicing your presentation in front of real humans in a real room, even if they have no idea what you’re talking about, will improve it much faster than practicing it by yourself in your room. When you have a real audience, you can’t afford to take shortcuts, so you get much better feedback about which parts are solid and which parts are still sketchy, in real time.

If that fails, find a real lecture hall to do your presentation in, and record it from beginning to end. I cannot tell you how much time I spent practising my presentation in empty lecture halls last summer.

27. Your research advisor is probably right, even if you don’t know why.

Don’t expect them to be able to explain themselves to you, though. A lot of the time they’re also going off of vibes and instincts; they just happen to have a lot more experience backing those instincts than you do. Also, as I’ve probably already said a few times, researchers are notoriously terrible at explaining themselves. You probably won’t understand why your advisor was right until you get burned and figure it out for yourself.

28. Sometimes you need to ignore your research advisor.

This is the last one for a reason. If, like me, you’re in the sciences, you can’t just ignore your supervisor: they’re the one funding you and providing the resources you’re using, so in return, you need to listen to them and work on their project. However, they aren’t doing your project: you are. Sometimes, if you have a different idea for how to spend your time that seems like it’ll advance the project or be more productive, you should do that instead and deal with the consequences later.¹³

The key, however, is that you’re going to need a good explanation when you go back to your advisor, and you’re also going to meet to have evidence and results that your detour was worthwhile and successful. If your gamble is successful, your advisor will likely be happy; if not, they might be mildly annoyed at you. But the thing is, you’re not going to get very far in research by blindly following instructions. Sooner or later, you have to at least try to think for yourself and defend your choices.