How do people actually read documentation without getting overwhelmed (or missing important stuff)?

Posted by OneLastPop@reddit | learnprogramming | View on Reddit | 39 comments

Hey folks,

I’ve been learning programming and often find myself diving into documentation for different classes, especially in Flutter or other frameworks. But sometimes I open a class doc and it just… feels endless. So many properties, methods, constructors, inheritance, mixins, parameters, and I’m like:

"Wait… what do I actually need to look at right now?"

I often just search for what I need in the moment, but then I get this weird FOMO (fear of missing out), like maybe I’m ignoring something really useful that I’ll need later. At the same time, reading everything seems impossible and draining.

So I wanted to ask:

How do you personally approach big documentation pages?

Do you just read what’s relevant now?

Do you take time to explore what else a class can do, even if you don’t need it yet?

And if yes, how do you remember or organize what you saw for later?

I guess I just feel like I should "know everything" and that pressure gets overwhelming. Would love to hear how others deal with this — especially devs who’ve been doing this for a while.

Thanks

[-]

Ezykial_1056@reddit

I am an old programmer (retired in fact) but I still code because I enjoy it. I say that, because I think the answer is use AI, and I have history to support my claim.

I started programming before the internet, and the ONLY documentation was paper. Companies had rooms full of manuals, and you had to look up, or photocopy, or buy your own documentation to know the api, usage etc.

Then HTML arrived, actually IBM had another online format, but very similar just before html. At any rate, people who used the online documentation were more productive than those still reliant on paper, the change happened and today no one even considers having a paper copy of documentation (seldom anyway). The old guys were like "What you can't remember that api?". They were soon out-produced by the newer guys.

Next came stack overflow, and other question / answer assists, and productivity increased for those that used it. Soon, it was required knowledge if you wanted to be competitive. Again, old mentality guys said "You don't already know that? You have to look it up?". Again, outdistanced soon.

I'm sure you get the pattern.

AI is the next documentation tool. This time the "example" code it provides is even closer to what you need. It's not right, often, but it's close, and sometimes it has an approach you had not even considered.

The nay-sayers will be left behind again.

Use the tools, use the technology. Give yourself every advantage you can find, it's not lazy, it's not being ignorant, it's progress. In 50 years of programming, it's always been this way. You either keep up, or you become unmarketable.

You still have to learn more on your own, but boring api, or programming patterns is not where you win. Learn the theory, WHY is this way better than that. What is the benefit of this way or that way, and the chat bots can help with this learning too. That's where you will outshine your competition.

[-]

Ormek_II@reddit

There is also a why in an API. There is a WHY in a framework. Using AI will get you done faster, but the “you have to learn on your own” remains.

You and I (still over 10years until retirement) had to learn by looking into the docs. If we did not we’d become old juniors.

[-]

Analbatross666@reddit

I feel like you may have something here. But also that - since it's obviously much more of a drastic upgrade from stack Overflow, compared to stack vs Online docs - there is probably a certain level of general ability that you should acquire, before you start to rely (really, at all) on AI for help. And that certain level of ability is a rather high bar. Just imo

snowbirdnerd@reddit

You don't read all of it. You search for the functionality you are after and read that.

Of course you have to have enough fundamental knowledge of programming to know what to look for.

nextnode@reddit

This user u/snowbirdnerd is known to just make up whatever they feel like - do not take any of their feelings as accurate.

delditrox@reddit

Just try to remember what things you can do with said library, not how to do them. That way, when you actually need it, you can just search for it.

dev-ed-5414@reddit

Docs and not structured for learning. They are a reference guide. There a site called docroot.ai that takes the docs and turns them into lessons. It the closest to what you’re looking for.

franker@reddit

Despite all these comments, a lot of times in this sub, people DO actually just tell you to go to the docs to learn to code, and they just drop a link to the documentation site. It's like just dropping the Bible on someone who wants to learn about religion, like, here just read this.

SynapseNotFound@reddit

I think some documentation is great

with some great examples

but others are lackluster, at least for me, being a somewhat newbie

mozillas javascript documentation is amazing

microsofts C# documentation has a lot of information but its not written as well as mozillas, so i dislike it

but then again, my native language is not english, so i prefer simpler terms and solid code examples. and microsoft are not as good as that, as mozilla.

mro21@reddit

Most documentation isn't great and doesn't explain any background.

Like "press this button if you want to do what it says". E.g. "press exit to exit the application"

The people writing docs must have a hard time bc I guess they are mostly not the actual developers.

SelfWipingUndies@reddit

I use AI for this now, mainly to point me in the direction I want to go. I'll ask what functions in a library do x, y or z and then verify by going to the actual documentation and looking those things up. Sometimes the AI is wrong or has outdated information where it's recommending deprecated functions.

DamionDreggs@reddit

Table of contents, introductory chapters, focus on what I need to solve my current problem and just a little more

The and just a little more part compounds over time spent in the documentation, which means if you're in the documentation a lot you'll absorb the extra stuff without feeling like you're wasting your time on things you don't need

Gawd_Awful@reddit

Skim over it, don’t bother trying to remember the details. Then when you need something, you think “oh yeah, I remember something that can help” and then go look up how to implement it

NewMarzipan3134@reddit

This. I do a lot of data work in python and if I tried to remember everything from each library I'd uninstall myself. IMO the key is knowing the basics well, and then just knowing where to find anything else efficiently.

AcnologiaSD@reddit

Me watching Java masterclass xD

Be careful to understand the overview. I experienced people solving the problem by using the framework (osgi) in the wrong way.

MastaSplintah@reddit

I agree with this. Last time I responded to a similar question I always have a skim read of the basics then just start doing what I'm trying to do and when I get stuck I go back to the docs and look at the specitpart I'm stuck on. Don't feel like you need to remember it all. I'll go back through the docs many times while working on something new.

affectionate_orchid@reddit

same here. I just dive in, hit a wall, then check the docs. No need to memorize everything upfront.

KyleTheKiller10@reddit

Best advice

rasmusdf@reddit

Don't read. Get an overview, skim. Do some exercises. Look it up as reference.

Also - often people produce overviews pointing out the most importants parts of a book.

CodeToManagement@reddit

You look for what you’re trying to do. You don’t need to know every function or feature of the class you just need to know the bits that solve the problem you’re trying to solve.

Historical_Equal377@reddit

Try to see a predefined function as a utility. Must a chef know how to use every kitchen utility every made or judge the chef by the out. Aka good food?

When I started programming I've manually converted decimale numbers to hex by hand. I've used string splitting and merging just to capitalize the first word. Now I know there are predefined functions for that, which I now use.

Fix the problems for your app and go look for solutions that support that. Api documentation isnt meant to be read from A-Z.

JohnCasey3306@reddit

Don't approach it like an academic exercise wherein you put yourself under pressure to memorize everything ... The documentation isn't going anywhere.

Instead, try to keep an approximate recollection of what's possible; in the future, when you're solving a very specific problem, you'll hopefully just remember that X did Y, and you can jump back to the docs to show you how.

No amount of reading docs is gonna make you an expert,.it's hands on coding with a framework or language, day-to-day that makes it sink in.

nightwood@reddit

Patiently.

erebospegasus@reddit

The reason one goes to the docs is to try to understand if the object can do something to help them in their project, either by having a method or a parameter to change behavior. Memorizing everything is pointless and expensive. Some times I just search a keyword. Good packages have good naming conventions that make this process intuitive, specially if they follow some design common principles

Ksetrajna108@reddit

Don't try to learn everything. It will waste your time. That said, as you are reading the documentation, you can take a side road from time to time, but just skim. You do want to get the lay of the land, but you don't want to get sidetracked while you focus on the problem you need to solve.

The lay of the land is super important.

CauliflowerIll1704@reddit

Depends on how big of a read it is. My limit is about 2-3 pages for the relevant section I am working with before I hit control-f and try to find the specific thing I need.

hari_bo@reddit

I don't think anyone actually reads the entire documentation, unless you are a masochist. Just Ctrl-F what you need or refine your google search until you get what you want.

For codebases, I create a mind map, just to get a sense of the high level architecture overview (ie. what connects to what, what is this class for, etc).

LForbesIam@reddit

Get Gemini deep research to summarize. It really is good at that.

snobpro@reddit

Skim over like others said. I try to categorise available stuff into “why buckets”. As in why this class even exists. Now i also use AI to comb through them when the need arises.

stiky21@reddit

It's a skill you learn over time. I remember being exactly where you are right now.

LN-1@reddit

I’ve read the rust book thrice and skimmed over the docs. Also super helpful to read some library’s docs.

Rain-And-Coffee@reddit

Most have a getting started section that cover 70% of what you need.

Personally I like reading the entire docs.

I can speed read it pretty fast and it helps to understand most how it works.

But the larger ones definitely take more time.

I always do a top down approach for everything. I read, skim, learn enough to believe I have an overview what exist (there is a bunch of classes for …., those things are realised as mixins) and how everything should work together.

Then, whenever I read up on a specific class, I review my top down understanding: Is something I see surprising, thus unexpected? I will skim the list of fields, methods, properties etc. and stop at those that I did not expect (what is that?).

I might also read some to confirm my view.

Main take away: have an expectation and review it every time. Using a framework in the wrong way is bad.

helpprogram2@reddit

It’s 2025 man. Throw the docs in chat gpt and ask it questions

idle-tea@reddit

There's a huge difference between reading for reference, and reading to learn a whole subject.

Documentation of each class and the like is nearly always optimized for and meant exclusively for reference, not reading it all in one big sitting.

If you're trying to learn the concepts and overall idea of a system that tends to be a separate text.

Occasionally I might skim in systems I'm less familiar with, or in new things that come out with new versions of system I am familiar with. I'm not trying to memorize anything, just note what features exist.

For the most part: I don't. Very often when I end up needing something I read about months or even years ago I just get an itch telling me that I remember there's some way to do that sort of thing, and I go hunting in the docs.

I guess I just feel like I should "know everything" and that pressure gets overwhelming.

No, you shouldn't. This is the desk of one of the most famous computer scientists out there back before looking things up on the internet was a reliable option. Notice the giant stacks of books behind him - they're not there for light reading, they're there because needing to reference material is common and expected.

Mysterious-Falcon-83@reddit

Read what's relevant to get the task at hand taken care of. There will always be an overwhelming amount to read, don't stress over it. And, don't feel bad if you find yourself revisiting documentation over and over.

Is it nice to have some piece of knowledge ready at will? Absolutely! Does that happen overnight. Absolutely not! It takes time -- lots and lots of time -- to commit even a fraction of the documentation to rapid recall.

Often, the thing that makes a great programmer ISN'T knowing everything, it's knowing where to find what you need when you need it. A side benefit is that by going back to the docs, you discover when things change.

no_regerts_bob@reddit

Most documentation has an overview section and then the details section. Study the overview and then use the detail section like a dictionary, look up what you need as it's needed