6 ms·

Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. It takes more time the first time, but it saves you time

Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. It takes more time the first time, but it saves you time for the rest of your life. You will look like a genius because you'll have an encyclopedic knowledge of everything. You will avoid problems early that come from the subtle knowledge every piece of tech has, buried deep in the docs. You will learn to solve your own problems faster rather than asking other people about something, because the docs often have the answer. Read the source code of popular software you use (including the libraries of your favorite language). You can learn esoteric knowledge about programming just by looking at other people's code. One benefit of OSS is that many eyeballs can shave code down to very efficient forms, and you can take those forms for your code.

Waterluvian 3y ago
Most documentation is not worth reading. It’s reference material to be reviewed on-demand. The “introductory” section that gives an overview is often useful, though. But that leads to the other problem: knowledge is not intelligence. You’ve studied some Python module but never learned that you ought to use a different one instead.
- ChrisLTD 3y ago
  Agreed. Documentation isn't a novel or essay that you need to read to the end for it all to make sense.
mewpmewp2 3y ago
Which documentation? If I read everything, it would take a lifetime.
BoppreH 3y ago
Reading source code also helps steering you away from unfit projects. I've decided to replace dependencies after trying to submit a PR and realizing the code was not as robust as I hoped, or was doing too much.
random_kris 3y ago
These two points (docs and looking at source code) Started working for me only few years into the career, when I had a really good grasp of foundations
jstummbillig 3y ago
Well, at least it's obvious where this is coming from. > You will look like a genius because you'll have an encyclopedic knowledge > You can learn esoteric knowledge about programming – and you will pay an incredibly steep price for it. If you want to be effective, stay clear of this one. Systems are going to be increasingly complex to the point where it's absolutely impossible for any one person to understand it all and your best bet is getting efficient at poking them to figure out what's going on.
- hef19898 3y ago
  How so? Knowing as much as possible about the systems should be the norm, it is a super power because most people are too lazy to be bothered with this. Knowing the system makes it very easy to poke the relevant people, find the relevant people and have meaningful discussions with those. Heck, it might even turn you into a meaningful person yourself. The alternative is stumblong aimlessly around and parroting input from others without understanding the smallest thing about it. This is something LLMs excel at, for free. The former not so much.
  - danielbln 3y ago
    Because mental capacity is finite, and knowing as much as possible doesn't work for everyone, especially if it's disconnected from actual problem solving. Reading a book cover to cover and have everything in there stick in the mind is great if it works for you, but there are plenty where it does not.
    - jackphilson 3y ago
      The problem isn't that mental capacity is finite, it's not (or the limit is too high to be relevant). The problem is that by spending time learning esoteric knowledge, you're only displacing time for more applicable knowledge.
      - Jensson 3y ago
        It saves you time, reading is quick, debugging without a good understanding is extremely slow.
cpursley 3y ago
> encyclopedic knowledge This only works for people with excellent long term memory. I constantly need to look things up in docs and even my own readmes.
- hef19898 3y ago
  But you know where to look it up, right?
- raincole 3y ago
  About once in a month, I google something and find a StackOverflow question about the exact thing... which is asked by myself years ago.
  - cpursley 3y ago
    Ha, same. And sometimes I come across a friends issue on github or SO. Always amusing.
gwervc 3y ago
Might work for a toy programming language and framework, but not for anything like C# and the .NET framework (especially when considering the different implementations), Java, etc.
- TheHumanist 3y ago
  Advice like that above is honestly terrible for newer developers, I believe. It feels insurmountable for many people, myself included. I simply don't have the brain capacity to: A. Read an entire language's docs front to back. As you mentioned, maybe if it is some small, silly thing but for something like Python, Java, JS, etc... no fucking way. My brain would constantly glaze my eyes over. There is so much. B. Retain the information I just attempted to read. Again, there is so much. It's insanely unrealistic for most people, I would think. New developers see advice like this and immediately feel like they aren't cut out for this because people make this nonsense sound like something 'YOU MUST DO' to be a good developer. It's toxic, in my opinion. Maybe not intentionally so, but it really can kill a person's excitement.
  - baq 3y ago
    My usual recommendation is to read the table of contents of the manual. This is especially important for any database you might be using. Language... meh, maybe...? But the DB - please do.
- aleph_minus_one 3y ago
  > Might work for a toy programming language and framework, but not for anything like C# and the .NET framework (especially when considering the different implementations), Java, etc. This is rather an argument against C#, .NET framework, and Java. :-)
  - raincole 3y ago
    Good luck telling your boss/client that you don't write C#/Java because "the document is too long to read cover to cover."
wruza 3y ago
it saves you time for the rest of your life Also saves you from fragmented knowledge. When it is good enough, it will remain half-assed till your end.
ensocode 3y ago
Work fragmented my brain so much as I am into so many things at one time and I am sure a lot of us feel like this. This comment makes me think on how to actually do that and how much time and efficiency this would cost. Nevertheless there is truth in it. How do you manage this?
- hef19898 3y ago
  Not OP, but that's how I do it (non-software stuff, but tech documentation is complex for any product, and if it is not there is no real problem): - get someone on the team to give an introduction to get some basic knowledge of the system in question, where to find things and what portion of the system affects you - read the documents relevant as per the previous point - read cited documents - start working, and look up stuff everytime you have to, dig as deep as possible - unless you are 100% sure about something, look it up - rinse and repeat, that grows your knowledge from immediately relevant stuff, to related stuff to general knowledge of the system - ask question, always, be curious, listen, read and ask questions It is a team sport, you don't have to know everything, master your stuff, and your interfaces with others (functions, sub-systems, teams and people, get a solid understabning of the overall system and relly on other like you for there parts. Going alone, based on gut feeling and assumptions is not something I'd advice.
  - TheHumanist 3y ago
    Right, but the original commenter is saying read all the docs, front to back. That's just nonsense.
    - hef19898 3y ago
      Maybe hyperbole, because reading the docs front to end is what I do. Starting with the ones identified as immediately important and taking it from there. Nobody said this is to be done in one session so, it takes time (I am currently in month 6 of such an excersice and can't even tell what I didn't read yet, unkown unknowns and such).
anymouse123456 3y ago
There are some brains that do very well with this advice, but mine is not one of them. I only seem to learn by moving back and forth between solving a real problem and finding just enough information to move forward one step. After some period of this, I'm usually able to read (and understand) a book or two on the subject, but never before. Maybe I'm a tactile learner? Not sure what to call it, but if you're not sure what kind of learner you are, try a variety of approaches and don't be discouraged if manuals don't work for you.
- danielbln 3y ago
  Same here. If I were to read docs cover to cover, not much would stick in my brain. I need top down research, start high level, and drill down where ever I touch base with practical applications. It's why I find interacting with LLMs so pleasant (ignoring their shortcomings), because I can learn exactly the way I want to and the way that works well for me.
  - Double_a_92 3y ago
    The knowledge from reading all the docs won't be really "usable" but it gives you a vague, almost subconscious idea of all the things that exist and how they interact with eachother.
- gglitch 3y ago
  I think of this as bottom-up vs top-down learning. I get frustrated working bottom-up one bite at a time; I need a map, I need to know the lay of the land and where I'm going. The older I get, the more I sense that bottom-up learners have an advantage, some sort of worse-is-better just-get-started kind of thing.
  - Double_a_92 3y ago
    > I need a map, I need to know the lay of the land and where I'm going. My visual image is a tree. I first need a rough shape of the trunk and branches, before I can start adding smaller branches and leaves. Bottom-up then feels like having a bag of random leaves, instead of a tree.
codethief 3y ago
> It takes more time the first time, but it saves you time for the rest of your life It saves you time until the next version of the software gets released, or until the software is superceded by some other, shinier software.
- hef19898 3y ago
  Until the piece of software, or the system, in question is migrating, why would that matter?
- bsdpufferfish 3y ago
  Examples of things where this has worked for me: linux man pages, internet RFCs, ECMAScript spec, RDMS knowledge, math and science theory.
TheHumanist 3y ago
Many people's brains cannot absorb that much information. If I sat down and read full docs front to back I would remember maybe 3 things. I don't think this is overall practical advice. Then reading the source code too for all this stuff I like? I don't understand where one finds the time for all this? I'm not putting you down, I just genuinely am confused. I barely get my stuff done as it is each day haha
- ethanwillis 3y ago
  This is surely an exaggeration. 3 things? Really? Surely you would remember much more than that. And I don't mean this in a snide way. I think I just have a much more optimistic view of what the average person is capable of in regards to reading. I think there is plenty of time but maybe not in the types of work environments that are the norm nowadays.
mightybyte 3y ago
> Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. I think there are times when this works and there are times when it will be a huge waste of time. In general, I think it's often very hard to tell which approach will be more efficient for you. As some sibling comments have mentioned, I think the way each person's individual brain works is a significant factor, but I think there are other potentially unknowable factors that are significant as well. The best thing I've come up with to deal with this is to use an iterative-deepening-like approach. There's a reason this algorithm (pre AlphaGo) was the most common approach for many game playing programs. The general idea is to go a ways down a particular path but always keep in mind some notion of the global suitability of this path and when it starts to look too hard, back up and investigate some other approaches to at least a shallow (but a little bit deeper than before) depth. This lets you avoid potentially costly dead-ends for relatively low overhead. (These thoughts inspired from this nice talk: https://www.youtube.com/watch?v=Z8KcCU-p8QA https://www.youtube.com/watch?v=Z8KcCU-p8QA)
- roland35 3y ago
  I think a better approach is to be prepared to read the documentation a few times. For me, the first time I mostly glance through and see the entire scope of things. I normally need to work with things at least a little bit first to really be ready for a more indepth read later.
  - mightybyte 3y ago
    Oh yeah, memory is not perfect, and I think that very often you'll have to work with a concept multiple times to fully absorb it. I think we're saying very similar things.
hnfong 3y ago
C++ 20 - Number of pages : 1853 ( https://www.iso.org/standard/79358.html https://www.iso.org/standard/79358.html ) Python language - Number of pages: ~206 ( https://docs.python.org/3/download.html https://docs.python.org/3/download.html ) Python standard library - Number of pages: ~2337 ( https://docs.python.org/3/download.html https://docs.python.org/3/download.html ) I don't know, but I have a suspicion you haven't read these cover to cover. Or maybe you have, for the latest version 10+ years ago. Is your advice to read the diffs when they update?
- strken 3y ago
  I've read the Go spec. It's short and sweet and doesn't include the standard library, though. https://go.dev/ref/spec https://go.dev/ref/spec Also the ecmascript-262 spec version 5.1, also known as es5. https://262.ecma-international.org/5.1/ https://262.ecma-international.org/5.1/ They were actually pretty interesting reads, and not too long. Maybe I should see if there's a PDF of the Node.js and Go standard libraries.
  - dgritsko 3y ago
    Looks like this might be what you want at least for Node.js: https://nodejs.org/docs/latest-v17.x/api/all.html https://nodejs.org/docs/latest-v17.x/api/all.html
- throwawaaarrgh 3y ago
  Is your career in programming in Python? Then perhaps taking 4 weeks to read the Python docs a few hours a day, is worth the 30+ years you will be using that knowledge 40 hours every week (60,000 hours of work). And yeah, changelogs are there for a reason.
myaccountonhn 3y ago
While I am not this extreme, I do think that there is value to having a set of tools that you really know and have read the manual for (for me it's git, common unix commands, Postgres and your "main" programming language). If anything, it gives you an appreciation for programming languages that are not only simple to write but also simple to reason about.
strken 3y ago
I think it's better to read the docs for software you have to touch or are especially interested in rather than everything everywhere in your stack, and this is especially true if you are a beginner. Reading about what you touch makes you a better programmer, while reading about what you like makes you a happier one because your future work will often be in your area of expertise. If you read at random it tends to send you down rabbit holes, unless you're grounded by applying your knowledge or you have the gist of the subject already. Rabbit holes are delightful if you're interested in them, not so much if you're going down them out of duty.
raincole 3y ago
You probably severely underestimated how long documents are today. Also reading something cover by cover is not enough to retain the information. Not even close.
- AlotOfReading 3y ago
  Yeah, one of the documents I regularly refer to is 1600 pages on its own. It refers to dozens of other documents that are 1000+ pages each. That's just the hardware though. The languages running on it each have standards docs, which are further hundreds to thousands of pages of material I regularly refer to. Those languages are used to implement software standards, which might be thousands of pages per volume, and have dozens of volumes. It doesn't matter how fast you read, you're not going to be able to read or retain all of that info.
JTbane 3y ago
This. People don't RTFM, I make wikis that are intended to be used by the team and new hires, I make them as short as humanly possible, even suspending grammar and using sentence fragments. Yet no one reads them.
- rsanek 3y ago
  this might be a discoverability problem. my wiki readers went way up when I linked to it from code as well as relevant internal admin surfaces.
eschneider 3y ago
Reading the docs is a bit of a superpower, but life's too short to read everything cover-to-cover. What's worked better for me is to skim everything so I have some idea what's in there. Then, when I need to do "X", I know to check in the docs. There's a balance to be found here that's likely different for everyone.
deleted 3y ago
[deleted]

Waterluvian 3y ago

Most documentation is not worth reading. It’s reference material to be reviewed on-demand. The “introductory” section that gives an overview is often useful, though. But that leads to the other problem: knowledge is not intelligence. You’ve studied some Python module but never learned that you ought to use a different one instead.

ChrisLTD 3y ago
Agreed. Documentation isn't a novel or essay that you need to read to the end for it all to make sense.

mewpmewp2 3y ago

Which documentation? If I read everything, it would take a lifetime.

BoppreH 3y ago

Reading source code also helps steering you away from unfit projects. I've decided to replace dependencies after trying to submit a PR and realizing the code was not as robust as I hoped, or was doing too much.

random_kris 3y ago

These two points (docs and looking at source code) Started working for me only few years into the career, when I had a really good grasp of foundations

jstummbillig 3y ago

Well, at least it's obvious where this is coming from. > You will look like a genius because you'll have an encyclopedic knowledge > You can learn esoteric knowledge about programming – and you will pay an incredibly steep price for it. If you want to be effective, stay clear of this one. Systems are going to be increasingly complex to the point where it's absolutely impossible for any one person to understand it all and your best bet is getting efficient at poking them to figure out what's going on.

hef19898 3y ago
How so? Knowing as much as possible about the systems should be the norm, it is a super power because most people are too lazy to be bothered with this. Knowing the system makes it very easy to poke the relevant people, find the relevant people and have meaningful discussions with those. Heck, it might even turn you into a meaningful person yourself. The alternative is stumblong aimlessly around and parroting input from others without understanding the smallest thing about it. This is something LLMs excel at, for free. The former not so much.
- danielbln 3y ago
  Because mental capacity is finite, and knowing as much as possible doesn't work for everyone, especially if it's disconnected from actual problem solving. Reading a book cover to cover and have everything in there stick in the mind is great if it works for you, but there are plenty where it does not.
  - jackphilson 3y ago
    The problem isn't that mental capacity is finite, it's not (or the limit is too high to be relevant). The problem is that by spending time learning esoteric knowledge, you're only displacing time for more applicable knowledge.
    - Jensson 3y ago
      It saves you time, reading is quick, debugging without a good understanding is extremely slow.

cpursley 3y ago

> encyclopedic knowledge This only works for people with excellent long term memory. I constantly need to look things up in docs and even my own readmes.

hef19898 3y ago
But you know where to look it up, right?
raincole 3y ago
About once in a month, I google something and find a StackOverflow question about the exact thing... which is asked by myself years ago.
- cpursley 3y ago
  Ha, same. And sometimes I come across a friends issue on github or SO. Always amusing.

gwervc 3y ago

Might work for a toy programming language and framework, but not for anything like C# and the .NET framework (especially when considering the different implementations), Java, etc.

TheHumanist 3y ago
Advice like that above is honestly terrible for newer developers, I believe. It feels insurmountable for many people, myself included. I simply don't have the brain capacity to: A. Read an entire language's docs front to back. As you mentioned, maybe if it is some small, silly thing but for something like Python, Java, JS, etc... no fucking way. My brain would constantly glaze my eyes over. There is so much. B. Retain the information I just attempted to read. Again, there is so much. It's insanely unrealistic for most people, I would think. New developers see advice like this and immediately feel like they aren't cut out for this because people make this nonsense sound like something 'YOU MUST DO' to be a good developer. It's toxic, in my opinion. Maybe not intentionally so, but it really can kill a person's excitement.
- baq 3y ago
  My usual recommendation is to read the table of contents of the manual. This is especially important for any database you might be using. Language... meh, maybe...? But the DB - please do.
aleph_minus_one 3y ago
> Might work for a toy programming language and framework, but not for anything like C# and the .NET framework (especially when considering the different implementations), Java, etc. This is rather an argument against C#, .NET framework, and Java. :-)
- raincole 3y ago
  Good luck telling your boss/client that you don't write C#/Java because "the document is too long to read cover to cover."

wruza 3y ago

it saves you time for the rest of your life Also saves you from fragmented knowledge. When it is good enough, it will remain half-assed till your end.

ensocode 3y ago

Work fragmented my brain so much as I am into so many things at one time and I am sure a lot of us feel like this. This comment makes me think on how to actually do that and how much time and efficiency this would cost. Nevertheless there is truth in it. How do you manage this?

hef19898 3y ago
Not OP, but that's how I do it (non-software stuff, but tech documentation is complex for any product, and if it is not there is no real problem): - get someone on the team to give an introduction to get some basic knowledge of the system in question, where to find things and what portion of the system affects you - read the documents relevant as per the previous point - read cited documents - start working, and look up stuff everytime you have to, dig as deep as possible - unless you are 100% sure about something, look it up - rinse and repeat, that grows your knowledge from immediately relevant stuff, to related stuff to general knowledge of the system - ask question, always, be curious, listen, read and ask questions It is a team sport, you don't have to know everything, master your stuff, and your interfaces with others (functions, sub-systems, teams and people, get a solid understabning of the overall system and relly on other like you for there parts. Going alone, based on gut feeling and assumptions is not something I'd advice.
- TheHumanist 3y ago
  Right, but the original commenter is saying read all the docs, front to back. That's just nonsense.
  - hef19898 3y ago
    Maybe hyperbole, because reading the docs front to end is what I do. Starting with the ones identified as immediately important and taking it from there. Nobody said this is to be done in one session so, it takes time (I am currently in month 6 of such an excersice and can't even tell what I didn't read yet, unkown unknowns and such).

anymouse123456 3y ago

There are some brains that do very well with this advice, but mine is not one of them. I only seem to learn by moving back and forth between solving a real problem and finding just enough information to move forward one step. After some period of this, I'm usually able to read (and understand) a book or two on the subject, but never before. Maybe I'm a tactile learner? Not sure what to call it, but if you're not sure what kind of learner you are, try a variety of approaches and don't be discouraged if manuals don't work for you.

danielbln 3y ago
Same here. If I were to read docs cover to cover, not much would stick in my brain. I need top down research, start high level, and drill down where ever I touch base with practical applications. It's why I find interacting with LLMs so pleasant (ignoring their shortcomings), because I can learn exactly the way I want to and the way that works well for me.
- Double_a_92 3y ago
  The knowledge from reading all the docs won't be really "usable" but it gives you a vague, almost subconscious idea of all the things that exist and how they interact with eachother.
gglitch 3y ago
I think of this as bottom-up vs top-down learning. I get frustrated working bottom-up one bite at a time; I need a map, I need to know the lay of the land and where I'm going. The older I get, the more I sense that bottom-up learners have an advantage, some sort of worse-is-better just-get-started kind of thing.
- Double_a_92 3y ago
  > I need a map, I need to know the lay of the land and where I'm going. My visual image is a tree. I first need a rough shape of the trunk and branches, before I can start adding smaller branches and leaves. Bottom-up then feels like having a bag of random leaves, instead of a tree.

codethief 3y ago

> It takes more time the first time, but it saves you time for the rest of your life It saves you time until the next version of the software gets released, or until the software is superceded by some other, shinier software.

hef19898 3y ago
Until the piece of software, or the system, in question is migrating, why would that matter?
bsdpufferfish 3y ago
Examples of things where this has worked for me: linux man pages, internet RFCs, ECMAScript spec, RDMS knowledge, math and science theory.

TheHumanist 3y ago

Many people's brains cannot absorb that much information. If I sat down and read full docs front to back I would remember maybe 3 things. I don't think this is overall practical advice. Then reading the source code too for all this stuff I like? I don't understand where one finds the time for all this? I'm not putting you down, I just genuinely am confused. I barely get my stuff done as it is each day haha

ethanwillis 3y ago
This is surely an exaggeration. 3 things? Really? Surely you would remember much more than that. And I don't mean this in a snide way. I think I just have a much more optimistic view of what the average person is capable of in regards to reading. I think there is plenty of time but maybe not in the types of work environments that are the norm nowadays.

mightybyte 3y ago

> Read the documentation. Don't skip over it to the part you want; read the whole thing, cover to cover. I think there are times when this works and there are times when it will be a huge waste of time. In general, I think it's often very hard to tell which approach will be more efficient for you. As some sibling comments have mentioned, I think the way each person's individual brain works is a significant factor, but I think there are other potentially unknowable factors that are significant as well. The best thing I've come up with to deal with this is to use an iterative-deepening-like approach. There's a reason this algorithm (pre AlphaGo) was the most common approach for many game playing programs. The general idea is to go a ways down a particular path but always keep in mind some notion of the global suitability of this path and when it starts to look too hard, back up and investigate some other approaches to at least a shallow (but a little bit deeper than before) depth. This lets you avoid potentially costly dead-ends for relatively low overhead. (These thoughts inspired from this nice talk: https://www.youtube.com/watch?v=Z8KcCU-p8QA https://www.youtube.com/watch?v=Z8KcCU-p8QA)

roland35 3y ago
I think a better approach is to be prepared to read the documentation a few times. For me, the first time I mostly glance through and see the entire scope of things. I normally need to work with things at least a little bit first to really be ready for a more indepth read later.
- mightybyte 3y ago
  Oh yeah, memory is not perfect, and I think that very often you'll have to work with a concept multiple times to fully absorb it. I think we're saying very similar things.

hnfong 3y ago

C++ 20 - Number of pages : 1853 ( https://www.iso.org/standard/79358.html https://www.iso.org/standard/79358.html ) Python language - Number of pages: ~206 ( https://docs.python.org/3/download.html https://docs.python.org/3/download.html ) Python standard library - Number of pages: ~2337 ( https://docs.python.org/3/download.html https://docs.python.org/3/download.html ) I don't know, but I have a suspicion you haven't read these cover to cover. Or maybe you have, for the latest version 10+ years ago. Is your advice to read the diffs when they update?

strken 3y ago
I've read the Go spec. It's short and sweet and doesn't include the standard library, though. https://go.dev/ref/spec https://go.dev/ref/spec Also the ecmascript-262 spec version 5.1, also known as es5. https://262.ecma-international.org/5.1/ https://262.ecma-international.org/5.1/ They were actually pretty interesting reads, and not too long. Maybe I should see if there's a PDF of the Node.js and Go standard libraries.
- dgritsko 3y ago
  Looks like this might be what you want at least for Node.js: https://nodejs.org/docs/latest-v17.x/api/all.html https://nodejs.org/docs/latest-v17.x/api/all.html
throwawaaarrgh 3y ago
Is your career in programming in Python? Then perhaps taking 4 weeks to read the Python docs a few hours a day, is worth the 30+ years you will be using that knowledge 40 hours every week (60,000 hours of work). And yeah, changelogs are there for a reason.

myaccountonhn 3y ago

While I am not this extreme, I do think that there is value to having a set of tools that you really know and have read the manual for (for me it's git, common unix commands, Postgres and your "main" programming language). If anything, it gives you an appreciation for programming languages that are not only simple to write but also simple to reason about.

strken 3y ago

I think it's better to read the docs for software you have to touch or are especially interested in rather than everything everywhere in your stack, and this is especially true if you are a beginner. Reading about what you touch makes you a better programmer, while reading about what you like makes you a happier one because your future work will often be in your area of expertise. If you read at random it tends to send you down rabbit holes, unless you're grounded by applying your knowledge or you have the gist of the subject already. Rabbit holes are delightful if you're interested in them, not so much if you're going down them out of duty.

raincole 3y ago

You probably severely underestimated how long documents are today. Also reading something cover by cover is not enough to retain the information. Not even close.

AlotOfReading 3y ago
Yeah, one of the documents I regularly refer to is 1600 pages on its own. It refers to dozens of other documents that are 1000+ pages each. That's just the hardware though. The languages running on it each have standards docs, which are further hundreds to thousands of pages of material I regularly refer to. Those languages are used to implement software standards, which might be thousands of pages per volume, and have dozens of volumes. It doesn't matter how fast you read, you're not going to be able to read or retain all of that info.

JTbane 3y ago

This. People don't RTFM, I make wikis that are intended to be used by the team and new hires, I make them as short as humanly possible, even suspending grammar and using sentence fragments. Yet no one reads them.

rsanek 3y ago
this might be a discoverability problem. my wiki readers went way up when I linked to it from code as well as relevant internal admin surfaces.

eschneider 3y ago

Reading the docs is a bit of a superpower, but life's too short to read everything cover-to-cover. What's worked better for me is to skim everything so I have some idea what's in there. Then, when I need to do "X", I know to check in the docs. There's a balance to be found here that's likely different for everyone.

deleted 3y ago

[deleted]