
Ask HN: How to RTFM? - rja907
I have seen dozens of times that people direct to the language manuals etc. to understand something in depth. I am a new college grad working as a Software Engineer and I mostly reference the manual when I cannot find something on Stackoverflow or some blog. 
Whenever I have tried to go through the manual, the  kind of language used has diminished my interest and ended up in my giving it up. Also, I don&#x27;t have an eidetic memory, so I don&#x27;t see how manuals can be useful in the real sense but I really want to go in depth of some topics like PostgreSQL, Spring, Javascript, Python etc. 
It would be great to hear if someone actually reads the manual and is able to successfully apply it in their lives...
======
DATACOMMANDER
I’ve had the opposite experience. I’ve found countless times that online
tutorials confuse the issue, even if they help you to accomplish some specific
task. The FM on the other hand tells it like it is. The trick is to only read
the parts that you need to in order to clear up your confusion. This sometimes
means reading one section and having to look something up in another section
before you can understand the first, and this can sometimes be a recursive
process, but if you have any understanding of the technology at all the
recursion depth is rarely greater than two or three. You’ll quickly find that
the things you don’t understand have straightforward explanations in terms of
the things you do understand.

If you find yourself five levels deep in this process and still unable to
comprehend what you’re reading, you need to take a step back and ask yourself
if you do in fact have any real understanding of the technology you’re using.

~~~
veddox
> If you find yourself five levels deep in this process and still unable to
> comprehend what you’re reading, you need to take a step back and ask
> yourself if you do in fact have any real understanding of the technology
> you’re using.

... in which case, you are in exactly the right spot to learn the fundamentals
of whatever you're trying to learn :D

One reason why I value (good) manuals is precisely that they are _not_ simply
a how-to-do-X-with-Y tutorial. Instead, a good manual will explain the theory
behind what you're trying to do - and so leave you in a much better position
to solve future problems on your own. Because now, you actually understand
what you're doing.

~~~
2muchcoffeeman
I find that a lot of documentation is poorly written or poorly structured.
They read like a straight description of a piece of software rather than a
document designed to help you understand what’s going on.

------
dwb
Don't read to remember everything (that's virtually impossible for most
people), mostly skim to build an index of concepts and possibilities in your
mind – and leave the details to the reference materials. Don't even bother to
try and remember details for something you don't immediately need. Computers
are good at details, humans are good at high-level webs of concepts.

You also need to be comfortable with stopping at a certain layer of
abstraction and mostly trusting that abstraction holds. For many programmers
(including me) I suspect that's the model of a computer presented by C. I
don't really bother to try to understand much of what's underneath this model
because time and my brain is regrettably finite. I just know more or less what
it's meant to do and trust it works. (Trust that, as evidenced by
Spectre/Meltdown, is unfortunately misplaced, but still – I'm only one
person.)

If I had to attack trying to understand, say, PostgreSQL, I would find out
what sort of thing it is (an RDMBS), what sort of ingredients that has (a
network protocol, a query parser, fundamental data storage structures, etc)
and fill in detail as my interest takes me. There's always going to be more to
learn about – these are massive subjects – so it's always going to be
piecemeal.

------
noir_lord
I find the most detailed manual I can find on a thing and then I skim it,
making note of chapter and paragraph headings.

90% of the benefit of a manual is knowing _that a thing is possible_ the other
10% is the manual telling you _how that thing is possible_.

I do the same thing with man pages, I just scan down them, I don't care about
the minutiae at that point but it's handy to know.

------
jolmg
Just so you know, manuals aren't read like story books, from beginning to end.
They're arranged in a tree structure with the root/trunk giving a rough
Overview or Introduction on whatever the manual is about, the branches
explaining various features in broad terms and ordered by their importance,
and the leaves explaining the most arcane details you might eventually need to
know about.

What I do is first take note of whatever seems like a Table of Contents which
neatly lays out this tree-like structure with one-line summaries. Pay
attention to each title, remembering their existence for future reference, and
determine how much you want to know from the get-go. Of course, the
root/trunk, otherwise known as Overview or Introduction, will be relevant to
everything so go over it. Only go to the deepest branches/leaves when you're
planning on using that knowledge, but always go over the branches that lead to
those leaves.

That about covers it. For example, there was recently a question on SE on what
had higher precedence in the shell, the | or the &&. Had this person gone over
the shell grammar section of the bash manpage, the answer would've been
obvious:

> Pipelines: A pipeline is a sequence of one or more commands separated by one
> of the control operators | or |&.

> Lists: A list is a sequence of one or more pipelines separated by one of the
> operators ;, &, &&, or ||, and optionally terminated by one of ;, &, or
> <newline>.

By the way, some answers say that you shouldn't go over the manual unless you
want to know a detail, but I think it sometimes pays off to read it whole (or
most parts of it). I've read most of the manuals for vim, bash, i3, urxvt,
among others, and I can say, it has paid off. This might depend on how you
learn best, though.

~~~
kazinator
> _Just so you know, manuals aren 't read like story books, from beginning to
> end._

Yes they can be! And if you're working a great deal with some technology, it
behooves you to read the manual from cover to cover. Try it!

I've read a number of programming language standards from cover to cover,
after which my facility greatly improved.

After I read the GNU Make manual from cover to cover, I was able to understand
complex Makefiles like never before, never mind generate them from scratch.

At university I read a Motorola 68000 architecture spec from cover to cover
(while writing an emulator). My ability to code MC68K assembly shot through
the roof.

I haven't read the entire POSIX standard cover-to-cover (not even the much
smaller classic 1990 version), but sections of it, like the complete
description of the Shell Command Language. My ability to write robust shell
scripts shot through the roof.

I've read the complete manuals for GNU Flex and Bison, plus the POSIX
descriptions of these and other materials. Complete whiz here.

Highly recommend cover-to-cover. Problems is, standards have gotten a lot
thicker. Everything takes more time. You have to choose wisely and prioritize.

> _branches explaining various features in broad terms and ordered by their
> importance, and the leaves explaining the most arcane details you might
> eventually need to know about._

That simply isn't how most technical manuals work. Once you get past the
intros and overviews, the arcane details are spread throughout all the
descriptions like raisins in a pudding. Generally, the description of a
specific feature or construct is completely given in one lump, with all the
arcane details. If there are four paragraphs, the first two may be general,
the second two full of arcane details. If you don't read the arcane details,
you could be screwed. Oftentimes, you're reading this stuff because of the
arcane details, not because you don't get the gist of it.

------
ElijahLynn
The thing is with RTFM is that it takes time. We don't all have time. So while
RTFM will sometimes help, almost all the manuals lack good examples. It would
be much more useful if all manuals had an equally extensive examples section.
Then we could say RTFE(xamples). `man awk` and `/` for `examples`, they have a
great example section. `man curl` doesn't have a specific section but does
have examples sprinkled throughout the options. `man kill` has zero references
to `example`, yeah, probably don't need it but there are some nice `kill`
tricks that could be in there.

I do read `man` pages daily, and it does get easier & faster with time. I am a
pro at searching man pages, but again, most lack good, high quality examples,
which would be most effective. As soon as I open a man page I press `/`, which
lets me search. If I am looking for an option (e.g. -F) I search for ` -F`
with the preceding space, this almost always gets you the actual option, not
just mentions of it. Then I press `n` or `shift + n` to go to the next and
previous results.

Also keep in mind that some apps don't have man pages, for those try `help
<command>` or `info <command>`.

Another tip is that the `apropos` or `man -k|--apropos` command can search all
man pages for you. Also there are hidden man pages, like `man 7 signal`
instead of just `man signal` (try it). `apropos` can find those for you.

Getting faster at reading is a key part of this, I spent some time exercising
my eye muscles and it does help. (Eye Q) was the name of the software I used,
I plan on revisiting that again.

I also spent a lot of time reading technical books, which _only_ helps if you
practice the information you learn. Otherwise it just goes in and out. You
want to take knowledge and turn it into skills, by practicing. Deliberate
Practice to be more specific per the book Peak by Anders Erickson (must read
for all learners).

At any rate, don't be afraid to ask and use StackOverflow, we don't all have
many hours to find answers, we need to be effective, that includes reading a
lot, but also knowing how to search, very effectively. Search Engines are a
manual in a sense.

------
dan-robertson
As others have said, it is often helpful just to have a general idea of what
things can be done so one can know where to look to find it. E.g. it might be
“I know a library/tool related to this problem, let me find it’s manual and
guess some keywords to search”, or even just “this feels like something for a
lesser used unix tool, let me do info coreutils and look around.”

For programming languages, the thing I find particularly helpful is a formal
grammar as it typically resolves any syntax related issues (and often these
are subtle issues where two terms look similar written but one may be more
restrictive than the other). The other thing I try to do is build a mental
model of the compiler: If one has a good idea of what sort of thing one’s code
might be compiled to, it is more obvious what constructs should and should not
be allowed. This can backfire slightly: if one has an idea that eg Javascript
will be compiled to fast code, it is obvious that the with construct should
not be allowed, but maybe that just implies that the construct makes code
slow.

I think this can help to understand eg why virtual methods are slower to call
or why overloading works the way it does in an oo language, or eg why only
certain subtyping operations should be around (in particular one way to decide
this is “this language has certain typing rules and those demand certain
constraints” Another is “this language wants to compile this construct to a
certain thing and that requires that certain obvious constraints must follow”

------
giancarlostoro
Read the documentation for what you're currently using and struggling with.
Sometimes I peruse the documentation and discover new things I have never
tried that I can try to make my life easier. It's a bit hard at first, but
once you're used to it you can just read documentation and get work done. I
also read the underlying source sometimes to get further insight.

------
muzani
I feel that Google's manuals are notoriously bad or written in some kind of
manualese dialect that only Googlers use. Things like Android or Firebase.

For Android, the unofficial manuals are better, or even Stack Overflow.

I've seen some very well written manuals though. Facebook seems to be good at
it at least.

------
jrockway
Documentation is good when it's good, bad when it's not. And people don't put
much effort into documentation, in the average case. The final source of truth
is the code. If you're wondering why something doesn't work, the code will
tell you exactly why, because that is what controls success or failure. The
manual author may have forgotten something, or the documentation might be out
of date. You'll never know for sure.

For that reason, I would say that the amount of time I spend reading
documentation is significantly less than then amount of time I spend reading
the code.

For documentation authors, I'd recommend focusing on giving the reader the
high-level context necessary to understand the code. It can be hard to dive
into that. But things like "an error will be returned if these 86 conditions
are true" probably should be a reference to the code, because you know there
are going to be 87 conditions tomorrow and you'll forget to update the
documentation.

As for your actual question, it can be hit and miss as to whether or not you
can go into depth in something by merely reading. I have not found a book
about modern Javascript ("use the axios library to make HTTP requests from
your code") and just have to cobble things together from existing code,
googling for the current problem I'm having, etc. I imagine that sucks for
people new to the field, but I suppose is why you get paid for having
experience. For things like SQL, you can definitely find a book about it, as
it's been essentially the same for my entire life, and what really matter are
the fundamentals of relational databases... the Postgres-specific things you
will probably discover while doing some work.

So I guess what I'm saying is... focus on getting experience. If you tell
yourself, "I want to write 'foo' in Javascript" you will learn Javascript
somehow. It's not as easy as just reading something, but it will stick with
you forever. And when you run into the inevitable obscure error message,
realize that you can just read the code to figure out what's actually
happening. You need not be dependent on a secondary source when reading the
primary source works. Because someday, you will be paid to work on code
without documentation, and you will need that skill.

------
UncleEntity
> I am a new college grad working as a Software Engineer...

I don't want to sound harsh but...How did you manage to earn a college degree
without learning how to research specific topics?

That's pretty much all I did in college, I tried to "pivot" a while back and
started at one of those private universities and was truly offended when they
said I had to take a course on "researching topics" or some such nonsense and
wouldn't let me out of it when I said "but, Dude, I have an _art history_
degree..."

------
effie
> _I really want to go in depth into x y z_

Don't worry. Manuals are not supposed to be read like a textbook/tutorial. Not
most of them anyway.

I know a guy who read through half a thick book on Python without writing a
line of code. He said it all made sense until a point, where he began to hate
the language. Well, it was a terrible book for a beginner, but the point is,
reading about the stuff is not enough and you will only get repelled.

Choose one tech that you like. Investigate how real use works, mostly by
trying to build _real_ things, even if only for study purposes. If you get
lost or the learning material gets repulsive/boring, move on. You need to have
a good time. Seek existing useful examples by other people in real famous
software not textbooks. Emulate them / reuse parts for your projects / invent,
imagine new uses. You get deep by enjoying and "pushing the envelope" on what
you can build. Not by reading per se. That is a parallel activity that can
help, but is not enough.

Many books/manuals are good for getting straight idea on which version of the
tech supports the feature you need, and what is the version-specific syntax
and limitations. But this is the kind of information that gets useful only
after you already have a very good working knowledge of the thing and need to
deal with real world ugliness of different versions/obscure features/corner
cases at work.

------
ezrast
I find that after you've picked up the basics, reference materials are usually
the most useful part of documentation by far.

For programming languages I always add the standard library reference into my
browser's search engines. For example, I can type "kt mutablelist" into my
address bar to go straight to
[https://kotlinlang.org/docs/reference/?q=mutablelist&p=0](https://kotlinlang.org/docs/reference/?q=mutablelist&p=0).

------
davismwfl
For context I have been writing professional code since the early 90's, and
while I have a ton of experience, I still will pull out the manual or google
to refresh myself. The difference between being in college and the
professional world is it is expected that you have to use reference material
to do your job effectively. And over time things you use frequently or have
solved frequently will stick in your head. The things you have solved, but not
used regularly will require more time to refresh.

The more you specialize in solving a specific type of problem or in a specific
area of software the less referring you do for everyday problems but it will
still be a part of your normal day.

Also, when you read something, the only way to truly understand it (and
tradeoffs) in my opinion is to write tests and actually test it. That is
something that is super critical to success, doing small test projects to
prove it out and see what works and what doesn't. Because frankly what is
written in the manual and what it actually does or how you actually do it
might differ still.

------
scott00
Manuals are not really for reading cover to cover. You generally want to use
the table of contents, the index, or searching of some variety (google,
ctrl-f, whatever) to narrow in on exactly what you want to know. A few
scenarios I find them useful:

(1) If you're getting conflicting advice from blogs and stack overflow: this
is often the case when software is changing fast. Manuals are often explicitly
versioned to match the software, so if the manual covers the topic you care
about, going to the latest manual is a great way of figuring out which advice
is current.

(2) Skimming the index: a quick way of discovering topics you can then explore
in more detail either in the manual itself or through follow up googling.

(3) A manual you know and love. Over time you get a feel for which manuals you
interact with are good. If a manual is good and you've gotten comfortable
reading it, it's often faster to find the answer you're looking for by
searching the manual directly rather than wading through a google search.

------
CydeWeys
I refer to documentation when I need to learn how to do individual things, and
then once I'm starting to become comfortable with the
library/software/whatever then I'll sit down in more depth and read through
more of the documentation. At that point you have enough context to understand
what's going on.

------
SamuelAdams
It's pretty simple with modern tools. For example, I'm learning Angular at the
moment. I needed to learn how to use an IF statement in the HTML code.

The first google result is a blog post [1] from some guy. It's helpful, but
really dilutes the core material. So instead I just went directly to the
angular docs [2]. This was straightforward and gave me the info I needed to
know.

Now CLI manuals from tools created in the 80's and 90's? Those are trickier.
I'm still trying to learn a good way to grok those tools, but so far blog
posts and Stack Overflow have been better than the man files, in my
experience.

[1] [https://toddmotto.com/angular-ngif-else-
then](https://toddmotto.com/angular-ngif-else-then)

[2] [https://angular.io/api/common/NgIf](https://angular.io/api/common/NgIf)

------
devonbleak
Seems like you're going about it backwards - start with the reference docs to
figure out how something _should_ work, then if that breaks down start looking
to other sources for workarounds or more information. This approach will force
you to get better at understanding TFM. Going to SO or blogs may be a quick
way to get a solution but as a software engineer you also need to understand
how and why that solution works, which is where the reference docs come in.

If you're finding that TFM is just too dense to get through then you probably
need to start learning/understanding the building blocks in whatever way works
best for you (online courses, wikipedia, more reference manuals, tutorials,
etc).

------
thiago_fm
I think reading software manuals is a waste of time. Unless if you do
something wrong, you break something, it is much more efficient to just try to
do a few examples and work with the tool, then when you need the manual, you
read it. Just search on it what you need.

I think it is impossible to read those things and still be ahead of the curve
on what is happening with software and things in general. Very time
inefficient way of learning things. Try to learn by practicing and knowing
where to search when problems happens, learn how to debug problems in real
life effectively, because that's what you will do on your whole career.

~~~
dlkinney
I used to feel the same way... until I actually read one.

It was a point several years ago that I was looking for a "better" solution to
something I was doing. A bunch of Stack Exchange answers on the topic each had
a different way of doing it, and each was as complicated as my own solution.
Over the course of _years_ , people tried to make the solution better.

Then I noticed the very bottom answer, below some dozen others. Posted about a
month before my search.

It was one line.

The individual just posted the one-line answer and a link to the manual.

It was part of the standard library.

 _And had been SINCE INCEPTION._

It was at that point that I began to RTFM. There are good manuals and there
are bad manuals. But one thing I've noticed is that for _most_ libraries, it
is absolutely invaluable to be able to have a high level picture of what's
available. It has completely changed the way I code, now.

First, read a few hello world tutorials so I can wrap my head around the gist.
Then RTFM. Then maybe read a book about it if I want a good idea of best
practices. Only _then_ do I search SE or other online sources.

Which I now rarely have to do, for the things in which I RTFM...

------
mugwort13
Every time someone says 'read the manual', I weep for humanity.

When I open most manuals pages I may as well be reading 'ᐅᒥᐊᕐᔫᑉ ᐳᓪᓕᓕᒫᐸᒐ ᑕᑦᑕᕐᓂᖅ
ᐊᒻᒪᔭᖅ'

It does nothing for me. I am seldom any smarter afterward.

These people don't understand there are different brain types, and only ~25%
are read/write brain types.

Couple that with the fact that many in technology write in a broken, sterile
form of English that any grammar correctly immediately flags as wrong.

No, the 'RTFM manual' people are typically extremely left-brained, analytical,
black/white people who have no ability to see from others' point of, and often
little desire to do so.

</endRant>

------
nicklaf
Manuals complement books and tutorials. Say I'd like to review sockets: I'd
probably first pull up Beej's _Guide to Network Programming_ [1], and then
switch over to (say) 'man 2 listen' when I want to dive in and see for myself
that Beej's exposition is true on my system. :-) Then I'd dive in and try it
out in code, referring back to the man pages as needed.

[1]
[https://beej.us/guide/bgnet/html/multi/index.html](https://beej.us/guide/bgnet/html/multi/index.html)

------
kazinator
> _Whenever I have tried to go through the manual, the kind of language used
> has diminished my interest and ended up in my giving it up._

I think you have to change your attitude and get used to reading that
language, and learn how to write it, too.

It is the language of engineering specifications.

I recommend reading at least one standard (e.g. programming language) in its
entirety.

Things refer to other things; at some point, you need the transitive closure
of the whole darn thing in your head to properly understand any part.

------
dwrodri
I would like to start by declaring that very, very few software manuals are
can be read cover-to-cover and offer great benefit. There are some exceptions
to this--the one that comes to mind the most is Ableton Live's manual.

Clearly, the most common use case for a manual is when a user has encountered
a situation where they don't know how to use a product as it should be used.
Here are two examples of different scenarios where RTFM as ended in different
ways:

* Keras: I'm currently optimizing the architecture of an artificial neural network at work, and I needed a little more detail on how quickly the network was training. The Keras documentation quickly guided me to the Callback section, where I quickly learned what callbacks were, and then found the CSVLogger callback. Not only did the documentation link directly to the source, but I thought the documentation gave a good high level overview of what the function did so I could see that clearly this was the function that was going to solve my problem.

* Vim: I use vim quite frequently at work as my main editor, and some of my co-workers also use it. Recently, I had asked a coworker how he configures vim for his projects, and he told me about Vim sessions. I asked him for more details about how vim sessions and tabs worked, and he referred me to the vim documentation. While the explanations were clear, I've always held the opinion that the vim documentation is a bit of pain to navigate, and suffers greatly due to the lack of example vimrc snippets. Maybe others think differently than I, but I've learned much more vim through blogs and vim-tutor than I have through vim's own documentation.

The biggest piece of advice I can offer is that regardless of the quality of
the documentation there is always some guarantee that the official
documentation is not the only documentation out there. It is quite rare that I
ever truly grasp an answer or new piece of information on the first read; I
often need examples or further reading for me to incorporate that information
into my everyday life.

All that being said, start with official documentation. I can't say for
certain, but in my experience it has always been the most authoritative and
the highest quality writing on the software itself. Seek out blog posts and
unofficial technical writing for further examples or different writing styles
that might be easier to grasp.

------
drenvuk
I find example usages first then decipher what the manual means while
referring to them. Many times it feels like manuals have their own language,
phrasing, templating syntax or what-have-you. If you have something to compare
against when they you can usually understand what they mean from that. I
really wish more manuals had simple examples at the start of the manual. You
don't even need many, just like 2.

------
emmelaich
Try things out as you read.

I read the Unix manual from cover to cover when I started out. As I went
through it I'd try the commands. Often there were short examples.

This was when there were only a couple of hundred pages though.

Regarding the language -- usually it's not only too terse but badly written.
However the classic books e.g. Kernighan & PIke's UNIX Programming Environment
are excellent.

------
kleer001
Maybe a slow walk through each item in that subject is needed? Also for any
particular popular subject there's more than one 'manual'.

I rarely read manuals. Except for roleplaying ones back in the day.

Is it a matter of time to focus for a long time on one task?

------
gabrielblack
Exactly. The question is where's TFM today ? Doxigen is not TFM. The examples
are not TFM. The comments are not TFM. The video posted on Youtube is not TFM.
The blog is not TFM. I want TFM or at least TF Man Pages.

~~~
sneakernets
Thing is, Documentation that thorough is _hard_ , and it's only harder with
the rapid release schedules many have adopted as of late. Then you have
software that hasn't had a completed set of man pages in years, because no one
bothered to finish it. So, I've resorted to reading the source code to see
what the blazes is going on if there's no competent manual available.

If I'm grabbing for the manual in the first place, I've found it's mostly to
search for an answer to "Can I do x in y context without having to code it in
the way I know works but is exhaustive, bloated, and a waste of my time".

I ran into this last year with an XML parsing library; I wanted to do
something so simple yet the library appeared as if it couldn't - parse
incoming XML payload - but the library's manual only discussed parsing XML as
if it were fully formed and from a local file, which is only applicable in a
fantasy world. It seemed very odd to me that the library would have its own
routines for local file loading, so I assumed it was required and I would have
to write incoming XML to a file and load it every time. Then I looked at the
source code to the library and discovered the author had coded it specifically
so that newbies could use it and not be affected by XXE attacks. Now the
library specifically mentions this in its tutorial, but not in its manual, so
I never saw the bloody thing.

I wasted a whole day for something that could have been mentioned in the
"manual".

------
tmaly
I would suggest taking a look at the book How to Read a Book by Mortimer
Adler. The title of the book does not do it justice.

It covers analytical and syntopical reading. But it also addresses how to read
different types of texts

------
bjourne
I print it and read it from cover to cover. I usually skip the preface, table
of contents and index though.

------
yesenadam
>if someone actually reads the manual

Uh, I thought everyone does.

>I don't see how manuals can be useful in the real sense

I'm...not sure how you can say this. Maybe you mean, reading a manual cover-
to-cover. I don't think "RTFM" means that. Don't read the whole thing if it's
boring! But I find once I'm well into using/learning some piece of software,
and want to know everything, reading the entire manual is fascinating. Plus
they vary in quality and readability. The python docs are extremely
readable..aren't they? (especially if you have a high tolerance for Monty
Python gags). Man pages mostly suck for learning software the first time, but
are brilliant for refreshing the memory. Mostly, I google lists of the best
books on a subject, and read as many of them as I can get my hands on. If I'm
not enjoying one, I turn to another.

~~~
JohnHaugeland
> > >if someone actually reads the manual

> Uh, I thought everyone does.

... have ... have you ever met another programmer?

~~~
AnimalMuppet
The old ones did this. Want to learn C? Read K&R. Want to learn Perl? Read the
Camel book. Want to learn C++? Read Stroustrup. That was _the way we learned_.

These days? Not so much. Stroustrup is now big enough to use in self-defense.
I'm not sure there ever was an equivalent book for Java. (There is one for Go,
however.) React? Angular? TypeScript? Do they have authoritative books? If
they do, is that the canonical way to learn them?

I think something changed 20 years ago. _The book_ used to be _the way_ to
learn, and now it's not. I don't know if the programmers changed, or if the
languages changed, or if the books changed, but something did.

~~~
JeremyBanks
FWIW Rust has "The Rust Book" as their primary long-form documentation,
separate from their reference documentation. It's a common starting point for
people new to the language. I read it in chunks as I was getting started.

I'm not sure how it compares to those works of the past (perhaps less
detailed?), but I found it much more approachable than most languages'
documentation and more in-depth than most languages' tutorials.

The old ways may not be entirely lost.

~~~
steveklabnik
All three of the books your parent mentions were explicit influences on TRPL.
So yes, it lives on :)

------
nradov
Why do you need to be interested in something in order to read the manual?
Sometimes part of being a professional is just forcing yourself to grind
through it.

------
PopeDotNinja
Don't worry about memorizing the manual. When I first got into programming,
focusing on Ruby, I would study the Ruby docs intensely. I got really good at
understanding the standard library. I read the heck out of the manual, and in
interviews that focused on how well I knew Ruby, I sounded really experienced.
But I struggled to build basic things.

There's a bunch of different types of documentation, and being able to skim
them enough to get a basic understanding is super helpful! A non-comprehensive
list of different types of documentation includes:

\- man pages

\- REST API docs

\- Language docs

\- RFCs

\- Tool specific docs

Let's get specific.

\- Say you need to find a way to filter text in a Bash shell, and you want to
read the man page for grep. Maybe you want to read
[https://www.tldp.org/HOWTO/Man-Page/q3.html](https://www.tldp.org/HOWTO/Man-
Page/q3.html) to start understanding this... 'grep
[-abcdDEFGHhIiJLlmnOopqRSsUVvwxZ] [-A num] [-B num] [-C[num]] [-e pattern] [-f
file] [--binary-files=value] [--color[=when]] [--colour[=when]]
[--context[=num]] [--label] [--line-buffered] [--null] [pattern] [file ...]'

\- Let's say you need to want to better understand how JSON works because you
are working on a networking library. Maybe scanning
[https://www.json.org/](https://www.json.org/) will help you read this
[https://tools.ietf.org/html/rfc8259](https://tools.ietf.org/html/rfc8259).

\- Let's say you're reading API docs for Artifactory, and they your not sure
how REST works, but they keep talking about it. Maybe scanning
[https://en.wikipedia.org/wiki/Representational_state_transfe...](https://en.wikipedia.org/wiki/Representational_state_transfer)
will help you read
[https://www.jfrog.com/confluence/display/RTF/Artifactory+RES...](https://www.jfrog.com/confluence/display/RTF/Artifactory+REST+API)

I identify with your pain. Reading docs is hard, especially when you're diving
into unfamiliar problems with unfamiliar tools. All I can say is that you just
keep pushing yourself to get better at it, and if you're lucky, maybe you'll
be fortunate enough to work with people who can help make the learning curve
less steep. There's no shortcut to getting to where you want to go.

A few tips & tricks that make things less painful for me:

\- getting high level context by watching short YouTube videos makes it easier
to read denser material that is hard to absorb

\- working on things that interest me makes reading dry documentation a lot
easier

\- building something at the same time I'm reading docs makes it a lot easier
to spot errors in the docs & gaps in my understanding

Keep pushing. It's always going to be hard. You just get better at working on
hard things :)

------
JohnHaugeland
> Ask HN: How to RTFM?

(blinks)

Open to page one. Engage eyes. Parse words.

