Edit wiki/research-notes/reading-papers.md — Work Reflections

---
visibility: public-edit
---

# how to read and extract value from papers

this is maybe the most repeated lesson in my notes across both the startup internship and later research work: read more. "literally read more — so repeated it should be instinctual at this point."

## the pattern of not reading enough

"for [two different research projects], both did not do enough reading." the failure mode was always the same:
1. get excited about a problem
2. start building/coding immediately
3. hit a wall because i didn't understand the fundamentals
4. realize i should have spent 2 days reading before writing a line of code
5. go back and read
6. realize the approach was wrong from the start

"the way to do research and also learn is to spend 1-2 months reading up on a topic and become an expert, then go do the thing."

## what to read for

when entering a new research area, the questions to answer before doing anything:

- what are each of the things that experienced people in this area are talking about?
- what are the things that people have done already?
- what is the state of the art?
- what are the big weaknesses of current approaches?
- how do the fundamental methods even work?
- what have other people tried? did it work? why or why not?
- is the problem even that important? sometimes the thing you think is the hard part has already been solved.

from working on signal processing: i could have saved weeks if i'd spent 3 days reading ISCEV standards and MNE documentation before trying to hand-code everything.

## how to actually read

### the standard approach

for VEP research, the useful reading order was:
1. the clinical standard (ISCEV standard for VEPs)
2. a textbook chapter or review paper
3. 3-5 recent papers using the method
4. documentation for the tools (MNE, scipy signal processing)

the standard gave me the parameters. the textbook gave me the theory. the papers gave me the gotchas. the docs gave me the implementation.

### reading vs doing

there's a tension. "valuable to in these days be able to learn" vs the pressure to produce results. the resolution: reading IS doing. it's the highest-leverage work early in a project.

"generally when hitting a thing, read / research. bias towards learning. will do it so much better." — the bias should be toward understanding before acting, especially early on.

### active reading

passive reading (skimming papers while eating) doesn't count. the useful reading was:
- taking notes on key findings
- connecting to what i already knew
- questioning whether the conclusions applied to my specific setup
- trying to reproduce key results before building on them

## the LLM problem with reading

"every time you use LLMs a lot you fall into a pitfall." LLMs are great for getting a quick overview but dangerous for deep understanding. they'll give you a plausible summary that's subtly wrong in ways that only matter when you're actually implementing.

the failure mode: ask chatgpt what parameters to use for EEG filtering, get a reasonable answer, use it, get bad results, not understand why because i never read the actual standard that explains the reasoning behind the parameters.

LLMs for research reading: good for "explain this concept simply" and "what are related topics." bad for "what parameters should i use" and "is this result good."

## the research → implementation bridge

"read then implement → become crazy good. stay centered."

the bridge between reading and doing:
1. read until you can explain the approach to someone who doesn't know the field
2. implement the simplest version first
3. validate against known results
4. iterate and extend

skipping step 1 was my most common mistake. skipping step 3 was my most expensive mistake.

---

*see also: [[signal processing workflow|signal-processing-workflow]], [[experiment design|experiment-design]], [[learning from experience|learning-from-experience]]*