Ask HN: How to RTFM? | Hacker News Reader

Ask HN: How to RTFM?

51 pointsrja90744 comments

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't have an eidetic memory, so I don'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...

View on HN

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.

> 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.

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.

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.

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.

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.

> 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.

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.

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”

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.

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.

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.

> 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..."

> 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.

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.

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.

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.

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.

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

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

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).

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.

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...

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>

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

> 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.

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.

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.

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.

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?

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.

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".

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

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

>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.

The projects that clearly care about good thorough documentation are relatively rare but worth their weight in gold.

One of my favourites is Symfony, their documentation is phenomenal (right up to the ability to generate a beautifully formatted ebook straight from the docs).

https://symfony.com/doc/current/index.html#gsc.tab=0

The structure is inviting, nicely thought out, makes it easy to get into from multiple points and well written.

Also I really appreciate they have a good "Best Practices" section, too many frameworks give you a lot of flexibility without any overarching "We suggest you structure it this way" which means that you can pick up two projects based on the 'same' framework and they bare little actual resemblance to each other.

That matters when you inherit someones codebase/decisions.

> > >if someone actually reads the manual

> Uh, I thought everyone does.

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

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.

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.

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

Haha... well, in person, probably not. I've been programming since the 80s, and most of the 'voices' I've heard have been writers on programming, besides more recently online on here, SE etc. Not programming professionally, just doing whatever I wanted. I got a copy of Stroustrup 20 years ago, but never read most of it. Have a few other massive C++ books, and a few smaller ones, that I consulted constantly though.

Recently I got into LaTeX, read almost every book on LaTeX + TeX available (a couple of dozen), all very good. Got into Prolog, (about a dozen books), all very good... All the books on AWK are great. Same with Lisp. Sure, Stack Exchange is a wonderful resource, hard to imagine doing without it. It's like having a teacher - read the books, then consult the teacher for questions that you can't immediately find answers for in the book. Some things are done better online: bash has a few great websites, and w3schools is great for css/js/html.

> Uh, I thought everyone does.

I thought no-one does!

:-)

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.

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 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/ will help you read this 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... will help you read https://www.jfrog.com/confluence/display/RTF/Artifactory+RES...

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 :)