[kenanfyi]

This does not sound realistic for work in academia or technical stuff. In fact there are some techniques to read a technical paper. I never read a paper just once an move on. An abstract says a lot if a paper worths reading and after that I skim that quickly. Then I skim again more deeper a day or so later. Only after that I read it throughly and take notes.

On taking notes/highlighting I agree with the author. A general behavior I observe in colleagues or co-workers is that they highlight half of a paper, but they never do anything with that highlights. This is something I never understand. If you never use that piece of information anywhere, why bother even spending ink on it?

[neilv]

> A general behavior I observe in colleagues or co-workers is that they highlight half of a paper, but they never do anything with that highlights.

They might be using this exercise to help them focus and absorb what's important on their first pass of reading -- they might not expect anyone to ever use their highlights.

People will have been taught different techniques, and adapted their own.

I never got into highlighters. We were taught to keep our books unmarked, for the next year to reuse them, or for resale value.

In grad school, I was told paper-reading techniques closer to what you describe.

(Skim abstract, decide whether to keep reading, skim results/conclusions, decide whether to keep reading, look at citations, cynical joke about citation politics, decide whether to keep reading, then some order of skimming introduction and related work and other parts that I don't recall because I didn't follow that guidance, and then eventually you might give the whole thing a close read.)

[tombert]

I read papers depth-first recursively. I read the abstract and see how much I understand. If there's a lot of stuff I don't understand, I hop down to the references, find one of those papers, and try again. I do this until I get to a paper I more or less understand and bubble upwards.

I take pretty aggressive notes in Obsidian for each paper [1], which carries the benefit of being able to MediaWiki-tag definitions as I find them and build up a dictionary of terms I can reference.

I've never really seen the point of highlighting, it takes zero comprehension of the material to rub a marker over a page. I try my best to summarize each paragraph into a bullet. I figure that if I can summarize stuff accurately, I at least have some understanding of the material, and again this builds up a repository of notes I can read later (though I rarely do because I usually have a decent enough memory of the source material afterward).

Some day I will start sharing my archive of paper summaries for the world to not-actually-read, though I can't right now because they're kind of intermingled with personal notes that will take some time in order to decorrelate.

[1] I have actually been experimenting with Logseq lately, and I use Codex to synchronize back to Obsidian for the time being.

[jrrrp]

I highlight as a way to categorize my annotations. I highlight in Zotero as I go, and in the highlight's comment section briefly jot down why (e.g. something to follow up on, or whether this reminded me of something else it contrasts with). I dedicate a certain colour to "background references I should have", another to ~ "things I disagree with" etc., which I find useful when coming back over the paper to type up my notes.

In a sense the highlighting is just a way to localize my thoughts to a particular passage of the text, and the colours (or even highlighting at all) are secondary.

There's some considerable duplication of effort (notes in Zotero, then I type up notes in Obsidian, then also extract out some of those ideas into their own files). But, much like the recent posts about "outsourcing thinking" and GP noting that people sometimes do nothing with their highlights, I find that the work is useful for understanding and remembering.

Out of interest, why have you been considering Logseq?

[tombert]

> Out of interest, why have you been considering Logseq?

Primarily because it's FOSS; I love Obsidian (I even pay for it) but I have to consider the possibility that they'll be bullshit and start charging for stuff or start restricting things arbitrarily. If Logseq becomes bullshit then I (or someone else) can fork it and maintain/grow it. It's also written in ClojureScript, so legally I have to kind of like it :).

I've also kind of grown to like the way that the "unit" of Logseq is the "block" instead of the "page". Pages are more about aggregation than "units" of information, and as a result of this I find that the graph view is actually useful, instead of just something pretty in Obsidian.

There are some things I really don't like about Logseq (the lack of proper Vim keystrokes being a big one for me), but one of my biggest pet peeves is when people try software for five minutes, make zero effort to understand what the application is actually trying to do, give up, and declare the software as "bad". I felt like that's what happened with Gnome Shell, for example.

I will likely eventually go back to Obsidian, but I figured that I should give Logseq a fair shake, and it's different enough from Obsidian that I felt it's only fair to spend a few weeks properly learning it.

[trinsic2]

I tried Logsec for a few hours, prolly should work with it more. It looks like a great tool, but I don't like nested bullet lists as a way to organize information. I'll check out your blog.

[tombert]

It’s been really hit or miss for me.

The bullets don’t bother me, since I outline a lot already, but there are other annoyances, like the poor performance, and an inability to split the screen.

I am still using it for a bit just to give it the fairest shake, but honestly I am kind of counting the days before I am back to Obsidian.

[jrrrp]

That sounds fair enough, I'd be interested in reading your thoughts at a later date on the experience!

[tombert]

I've been gradually updating this post [1] if you want to follow along. It's in a fairly rough state (all good blog posts require multiple rewrites and I haven't done that), but you are welcome to follow along as I compile stuff.

[1] https://blog.tombert.com/Posts/Technical/September-2025/Tryi...

[sevensor]

I read the abstract and skim the intro before committing to a read. The authors have to convince me that they know the field, they think they’ve done something interesting, and I think what they’ve done is plausible. If it passes that bar, I assume the most adversarial possible mindset and look for holes in their methods. If their methods are junk, I may skim the conclusion just to see what kind of unfounded nonsense to watch out for in the future, but otherwise I’m done, and really most papers are done at this point. Papers in my field are mostly bogus, unfortunately. Every now and then, somebody uses plausible methods, and only then do I really bother to sit down and read the whole thing.

[tombert]

I tend to work in more theory-heavy CS (at least when I'm reading papers), so sometimes even the abstract is obscured by lots of scary terminology, so if I want to understand even the basics, I need to do it recursively.

[sbinnee]

Hopping to the references right away doesn’t work for me. I prefer just going through the whole paper once and coming back. To me it’s analogous to reading a book in a language not familiar to me. You read it lengthy chuck of texts even though you come across words you don’t know. Then you can find the meaning of words and read the texts again for better understanding . This way I think is more helpful to grasp the whole topic and intention of texts faster.

[manwe150]

I don’t highlight often, but when I do it is for the same reason I take notes. I never refer back to either one. But they focus my mind to stay on track so it cannot wander as much, in the moment, and prompts me to immediately reflect on or quickly reread what I think might be important or interesting.