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.
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.
This may seem like splitting hairs, but both to you and to anyone in a similar situation, consider instead "skimming" the documentation rather than "reading" it. A lot of times the value of that first "reading" is just in getting a sense of what can be done and an idea about where it is documented. Certainly not memorizing how to do it on a simple read. There's a very popular unexamined idea that people retain things by reading them once and then will forever after retain it, but that idea is obviously stupid once I drag it out into the sunlight and point you at it. That's not the goal of a first read, and it's not what the vast majority of us get out of a first read. (Anyone who can operate that way is invited to make their own plans and let us normies discuss how to deal with our normal reading retention levels.)
I probably "skim" the bash man page once every couple of years and I still find new things that I blipped over every other time.
This is a great clarification. I actually do this a lot of the time (not always), but I do tend to skim the TOC and scan around before starting a new thing and it really is helpful.
As you said, it's a different than RTFM'ing, but it's an important clarification.
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.
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.
In general it is almost always better to learn using multiple styles instead of just one, if you prefer to do A then don't just do A but also try to do some B to improve your learning. Learning based on solving specific problems is good to get experience, but it is not good to get an overview of a field, you really want to get good at both the overview and the nitty gritty.
Also the purpose of reading a book isn't to become a master at implementing details, it is to get a good overview of the subject. You still have to practice implementations afterwards, but by having seen everything before your mind will now slot all problems much better and be more confident as you work through those implementations instead of looking up random advice on the internet.
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.
This is what I mean when I talk about different kinds of brains.
Some of us need a certain amount of clarity and structure before we can feel good. This a great! Especially if we're aware of what we need and figure out how to get it.
Others of us have trouble building from the roots, and we're more effective probing around in dimly lit fog with occasional bits of moonlight illuminating leaves.
Eventually, we may both find ourselves in a well-lit forest, but we approach from different starting points.
The important thing (for me, at least), is to know which path I need at a given point in time and for a given context.
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.
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.
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.
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.
The margins are infinitely expensive. "As much as possible" has no meaningful boundary, when working in a system that is too big to hold in your head.
Mastery is alluring - it's just not very effective and certainly really bad advice for new software devs, who are in the worst possible position to judge the margins and what is useful.
Exactly why new people, new to the job in general or just the system in question, need mentoring and leadership in doing so. And guess what you can do if you went through all of this? You can mentor and teach others, and if combined with doing, there is no better way to mastery than this, at least not one I am aware of.
Of the language? Propably not. The documentation for the piece of software written in C++ you are working on? Absolutely yes.
Edit: Regarding Linux, you are propably not touching every function or component of Linux neither. The less you are concerned, the less important it is for you. And less you uave to read it. That being said, a fulltime Linux OS dev propably should have a solid understanding of the complete OS to begin with.
You are obviously picking and choosing your documentation based on how easy it is to read. So your advice isnt universal. Clearly you don't fully follow it.
There's a lot of contrarian opinions here due entirely to the fact that people won't read certain documents for the same reason you avoid reading the c++ spec.
I don't need to read C++ docs, I am not concerned with it. If C++ is part of your, what's it called, stack, read the part of it that matters for your use case and read those parts directly related to your part of C++ or whatever other language you are using. Do that for every other language in your stack. I never said anything else, did I?
How deep and broad your understanding has to be depends on:
- your team, nobody can know everything alone, it is a team sport
- your specific use case, I cannot help you with that
- complexity of your use case
- your role, if you are responsible for graphics under Linux, sure as hell you read that part of the Linux documentation, front to end, multiple times and master it
- and, as always, know your system, stack, tools and documentation well enough to realize when you have to look stuff up and where
>your specific use case, I cannot help you with that
I don't need your help. You need it. I'm helping you realize your statement is wrong.
First you make a statement saying one should read all the docs. Now you say devs should read the relevant docs. Devs do the later anyway. Your argument just evolved into the point you're arguing against.
Clearly you didn't mean to do that. You just meant to read more docs then you normally would on topics a little further from the relevancy at hand. But people are responding to you based not off what you meant but what you said.
All the docs, if taking literally, would mean all the docs for everything you interact with in your life. Obviously impossible, isn't it?
Not every statement has to be taken literally, it seems so that on HN, more often than not, one has to be incredibly specific in ones comments. That is like talking to genie or something, really frustrating. I kind of assumed, and without going through all my comments I think I also mentioned it, that by "all the docs" the meaning was all the relevant docs, I even specified that explicitly later on, didn't I?
So, ehy exactly do you think that reading jib and task relevant documentation is not necessary, or even the comoletely wrong approach? Seriously curious, because I run into such people ever so often at work and usually fail to explain to them why they actually have to read that stuff if they want to be a usefull member of the team. Understanding why they have that opinion would really be helpful.
>All the docs, if taking literally, would mean all the docs for everything you interact with in your life. Obviously impossible, isn't it?
No but even if C++ is the central language of my stack your comment can reasonably be interpreted as suggesting me to read the entire C++ spec. That's not an outlandish interpretation given how many people interpreted what you said this way.
>So, ehy exactly do you think that reading jib and task relevant documentation is not necessary, or even the comoletely wrong approach?
Man, you just did. If your job is C++ development, yes, I absolutely expect you to be familiar with the full C++ documentation and master the parts relevant for your specific usage of it. If C++ is only part of your stack, replace familiarity with C++ specifically with familiarity of your whole stack.
I do the same with everyone, actually, myself included. Plumbers have to know the specs of their tools, materials and the regulations as well as principles of installation. And they do, the good ones at least.
And the easiest way to get that familiarity is reading the damn documenents. If you cannot be bothered with that, well, let me say I am happy I don't have to work with you.
>If your job is C++ development, yes, I absolutely expect you to be familiar with the full C++ documentation and master the parts relevant for your specific usage of it.
So you were unclear. You want someone to master only parts of of the stack but read the full spec. This is completely inconsistent with what you said earlier. You are moving the goal posts. Still it doesn't Make sense to read 1800 pages of the C++20 spec.
Do you read the English dictionary because you use English?
>And the easiest way to get that familiarity is reading the damn documenents. If you cannot be bothered with that, well, let me say I am happy I don't have to work with you.
Then you would be happy to not have to work with the overwhelming majority of programmers on the face of the earth. You being in the minority would make you the problem. Not others. Programmers in general read the spec and docs relevant to the task at hand. They do not generally read the full formal specifications and documentation of what they need.
How much is it possible to know about the systems? The app I work on now uses MariaDB (multiple versions at this point), postgres, Cassandra, and InfluxDB. Those are just the databases I can recall offhand; there may be others and there were others before my time at the company. And those are just the databases. I’m also responsible for hardware, networking, cloud infrastructure to include IaaS and container orchestration plus tons of services. Say it I should read the docs on all that is like a cruel joke. Not only are there not enough hours in the day, I doubt there are enough years in my life to imagine such a task. And it would be Sisyphean anyway because at any given moment one of them will make a “minor” update that breaks functionality and a bit of my knowledge will be useless. Welcome to the world of postmodern system administration; I guess we call it DevOps or SRE now or something; even that’s a philosophical debate these days.
Is it laziness or is it the fact that brains are different and many people (me included) can't absorb that much material and then retain it as well with so many other things going on in our work/lives. I would struggle just to read the entire docs, front to back, of anything in a sitting. Then to retain all that?
The point is not retaining it all so. The point is to remember where to look, and know exactly which parts of the documentation are relevant to you, and retain those. Added bonus if you know owns the stuff not relevant to you and if you understand how those parts are linked.
That is, honestly, something I expect from people in a professional environment.
The ability to retain information is mostly fueled by your interest towards the topic, and not by your inherent ability to retain in general. This is what neuroscience has figured out. And it confirms very much my own observations during my life time. Inherently uninteresting topics or things I was forced to learn but which never resonated with me were always difficult to impossible to remember. Things I care about, or which interest me greatly, were almost easy to learn. Reading a document about an interesting topic cover to cover is easy. Keep that in mind next time you think you have a hard time learning something.
I submit maintaining focus is also easier if the topic is inherently interesting. However, you sound like yu are describing something like ADHD, which probably needs a more specific approach.
Reading is actually cheap. You don’t have to understand everything, but being aware of the area map in general helps avoiding reinventing the wheel or looking for complex paths.
Systems are going to be increasingly complex
Coincidentally that’s where compensable expertise is.
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?
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.
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
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.
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.
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?
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.
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).
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.
> 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.
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.
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.
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
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.
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.
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.
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.
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.
> 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. :-)
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.
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.
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.