How to read documentation

Posted by NNNiharri-229@reddit | learnprogramming | View on Reddit | 16 comments

I enjoy watching lives of people reading documentations and doing discussions with the people in the chat and doing code in the same time. But when I try to read docs while coding I don’t really understand how to find the things or where to look for or should I read end to end. I always end up asking deepseek with thinking mode on. So the thought process of deepseek kind of helps me to understand, and then i try to implement it on my own in brute force and then I see the actual code…

I know this is not as same as reading documentation but I don’t know how to do it. I don’t want to get into tutorial hell but I end up get into AI hell..

What is the right way to do this?!

[-]

MissingSnail@reddit

Not all documentation is created equal. Some things are easier to learn from the does than others. But here are some general guidelines:

Read chapter one in full - the part that describes the purpose of the project, installation, and getting started.

Use the reference sections to understand now to use all the arguments in the key functions you’ll use.

Read release notes to see new and changed features in libraries you've used for years.

AI can be a great way of learning if you’re asking follow up questions. Ask what does line 10 do? Why did you use function X and not Y? What are the advantages of doing it this way and not that way? Ask Al for the link to the docs where it found something.

[-]

NNNiharri-229@reddit (OP)

Thanks for the suggestions. I will do that.

[-]

binarycow@reddit

You didn't specify which language you are learning, so I'll answer generally, and give examples from my favorite language, C#.

It depends on the kind of documentation.

Some are tutorials or how-to guides (Example: General structure of a C# program). You are meant to read the entire thing, following along, and doing it for yourself.

Some are going over the high level to medium level concepts (Example: Configuration in .NET). You are meant to read the introductory sections in full. Then, you can read the relevant parts of the document as you see fit.

Some are "deep dive" documents or low level documentation (I don't have an example). Beginners usually don't need to read these at all, and more advanced people usually skim the table of contents and read specific parts.

Some are merely documentation listing the types/properties/methods/functions (Example: C#'s Uri type. You are meant to read these to answer questions. For example "How can I parse a Uri?" or "Once I have a Uri, what can I do with it?" or "What information do I need to create a Uri?"

[-]

NNNiharri-229@reddit (OP)

Write now I am learning fastAPI for backend then I will also learn Django

[-]

Ormek_II@reddit

If I read documentation, I have an expectation already. Something like: “The Draw claw does this and that. It will have a method called paint and a method call run”.

I then check, if my expectation is correct:

Draw class does exist. Brief top line fits with me assumption. Others classes in the list do not surprise me (e.g. why is there a Painter class?)
1. Methods do exist, briefly check if they really do, as I expected.

Now I can read the details I came here to read about.

If you do not have expectations already, or if the reality does not match your expectations: read more; read slowly; maybe even read top to bottom.

Documentation today often lack a description of the concepts. Instead they just give examples and references :(

[-]

NNNiharri-229@reddit (OP)

this is a method I do but still I don’t really go further in that whole page. The moment I get my answer I start to implement other lines of code… Is this okay or should I read the whole page? and sometimes in this process I miss a lot of things..

[-]

Ormek_II@reddit

As long as you check that your expectations are really met, you are good. Then you know enough of that topic and just look for some facts.

[-]

johnpeters42@reddit

Writing code is fine, but since you were reading documentation, you should immediately test it and compare actual vs expected behavior. If they differ, then go back to the documentation and look for anything that may be relevant to the difference.

[-]

NNNiharri-229@reddit (OP)

ok I will do that thanks

[-]

JGhostThing@reddit

Reading documentation is a necessary skill. You gain this by reading documentation. It's just that simple, just that complex.

I'm one of the old fogies. I don't use AI. At all. I do web searches, mainly with google. I read documentation. I read datasheets.

[-]

szank@reddit

I read. And read. And read . If necessary read again. Until i have an idea on whats there.

Then i cmd+f for whatever i need details of in a given moment.

Generally speaking the answer to "how to read the docs" is read until you think you wont read anything at all for the next month and then continue reading.

Theres no lifehack here.

[-]

Backtawen@reddit

dont read docs end to end, nobody does that. just ctrl+f what you need or use the search
the real shift is going in with a specific question. “how do i configure retries” not “let me read the whole thing”. docs are a reference not a book

[-]

NNNiharri-229@reddit (OP)

yes correct, thanks

[-]