3 ms·
You should try this for C++ and Linux. Read the spec of each cover to cover.
by corethree 3y ago
You should try this for C++ and Linux. Read the spec of each cover to cover.
- hef19898 3y agoOf 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.
- corethree 3y agoProbably not? So your advice is wrong. 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.
- hef19898 3y agoI 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
- corethree 3y ago>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.
- hef19898 3y agoAll 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.
- corethree 3y ago>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? Did I say this? No.