Most of what I know about Postgres came from its documentation. Most of what I've forgotten about Postgres also came from its documentation.
For years my relationship with docs was purely transactional. Something breaks, I search, I land on the right page, I copy the one line I need and close the tab. Problem solved. Two months later the same problem shows up and I do the exact same search, land on the exact same page, and feel faintly embarrassed that the purple link is already purple.
That's fine for trivia. Nobody needs to memorise every flag on tar. But some docs are worth actually learning: the core of the framework you use every day, the database you're responsible for, the cloud service your app lives on. For those, I changed how I read, and it's made a real difference.
Read the overview pages nobody reads
Search drops you into the middle of the docs. You get the reference page for one function with zero context about why it exists or what it's next to.
The pages I used to skip, the "Concepts" or "Architecture" or "How it works" sections, turn out to be the ones that make everything else stick. The React docs have a whole "Thinking in React" section. The PostgreSQL manual has a tutorial part before the reference part. The Go spec is short enough to read in an afternoon.
Reading those once, start to finish, gives you a map. After that, every reference page you land on from Google has somewhere to go in your head, and that's most of why things stop falling out.
Read with a question
Passive reading is where docs go to disappear. My eyes move, nothing lands.
What works for me is writing down one question before I open the page. "When does useEffect run its cleanup?" "What actually happens during a Postgres VACUUM?" Then I read until I can answer it in my own words, out loud or in a scratch file. If I can't, I haven't finished reading, even if I've reached the bottom of the page.
It sounds slow. It's faster than reading the same page five times over a year.
Run the examples, then break them
Docs examples are designed to work. That's their job. The trouble is that watching something work teaches you very little about the edges.
So I paste the example into a scratch project and then change one thing. Pass null. Remove the dependency array. Drop the index and run EXPLAIN again. The moment it breaks, and I see the actual error message, is usually the moment the concept clicks. It's also the error I'll recognise six months later at 11pm.
Keep notes that are short and yours
I tried keeping long notes on documentation. It turned into a second, worse copy of the docs.
What I do now is write the smallest possible note in my own words, with the link to the real page underneath. Something like: "Postgres: VACUUM reclaims space from dead rows, but plain VACUUM doesn't give it back to the OS. VACUUM FULL does, but it locks the table." Two lines, and a link for when I need the details. If I can't write the note without looking, I go back to the page.
Come back to it before it's gone
This is the step almost everyone skips, including me for about eight years.
You read a page, you understand it, you feel good. A week later most of it has evaporated, because you never needed it again in that week. Then you need it in month three and it's gone.
Spaced repetition is the boring fix. Look at what you learned a day later, then a few days later, then a week, then a few weeks. Each review is quick because you nearly remember it. I wrote about what's actually worth putting on a flashcard as a programmer if you want to go the Anki route. Concepts and gotchas are worth it. Syntax you can autocomplete usually isn't.
Where Recl fits in
Documentation was never my only source, though. Half of what I learn about a tool comes from a conference talk on YouTube, a blog post someone shared, a podcast episode, or a 60-second video that explains one thing better than the official page. Tracking reviews for all of that by hand never lasted more than a fortnight.
That's the problem I built Recl for. You save a docs page, article, video, reel or podcast from your phone's share sheet or the Chrome extension. Recl writes a summary of the key ideas (with timestamps for videos), files it under a topic, and brings those ideas back to you 1, 3, 7, 14, 30 and 60 days after you saved them.
The part I use most for docs is Ask. You can query your own saves, so "what did I save about Postgres locking?" pulls up the pages and videos I saved, with sources, instead of me starting a fresh search and landing on the same purple link again.
It doesn't do the reading for you. You still need the question, the broken example and the two-line note. Recl just makes sure you see it again before it's gone.
What changed
I still search docs constantly. That part never goes away, and it shouldn't.
The difference is that for the handful of tools I use every day, I now read the overview once, read the rest with a question, break the examples on purpose, and come back on a schedule. The pages I've learned that way, I mostly don't need to look up anymore. That was the whole goal.
I'm Spartan Rich, and I build Recl, an AI learning app that saves your videos, reels, podcasts and articles, summarizes them, sorts them into topics, and uses spaced repetition so you remember what you learned.
Top comments (1)
The "read the overview pages nobody reads" advice is the most underrated productivity hack in engineering. Search engines drop you right into the reference for useEffect, but without reading the "Thinking in React" page first, you have no mental map to hang that knowledge on.
Also, "run the examples, then break them" is exactly how you actually learn. Docs are written to show the happy path, but the real learning happens when you pass null or remove the dependency array and stare at the error message.
One question about the spaced repetition aspect: for docs specifically, how do you decide what's worth turning into a flashcard? Do you just save the specific "gotchas" (like the VACUUM vs VACUUM FULL distinction), or do you try to memorize broader architectural concepts?