How can I get through very long and very dry, but also very useful technical documents when learning a new tool? Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?Evaluating resources for teaching myself reinforcement learningLearning in a developing fieldStrategies for self-learners to transition into working on larger projectsWhat does a person with an undergraduate degree in CS still need to learn to be employable as a developer?Computer Engineering student with Holes in my knowledge (i want to improve)In self-teaching, how can I move from basic tutorials to more complex work?How to retain technical information about new features?What can be the causes of the difference in student performance?How to convince students that self learning is an important skill?How can I remain a programmer and move into currently “hot” areas?

What does a straight horizontal line above a few notes, after a changed tempo mean?

"My boss was furious with me and I have been fired" vs. "My boss was furious with me and I was fired"

How do I prove this combinatorial identity

Will I lose my paid in full property

Check if a string is entirely made of the same substring

Crossed out red box fitting tightly around image

A Paper Record is What I Hamper

As an international instructor, should I openly talk about my accent?

Is Diceware more secure than a long passphrase?

Map material from china not allowed to leave the country

Israeli soda type drink

What is purpose of DB Browser(dbbrowser.aspx) under admin tool?

How much of a wave function must reside inside event horizon for it to be consumed by the black hole?

Why did C use the -> operator instead of reusing the . operator?

What is the term for a person whose job is to place products on shelves in stores?

Why didn't the Space Shuttle bounce back into space as many times as possible so as to lose a lot of kinetic energy up there?

How can I wire a 9-position switch so that each position turns on one more LED than the one before?

Is Electric Central Heating worth it if using Solar Panels?

Why do games have consumables?

How to not starve gigantic beasts

Retract an already submitted recommendation letter (written for an undergrad student)

Can you stand up from being prone using Skirmisher outside of your turn?

Long vowel quality before R

Why doesn't the standard consider a template constructor as a copy constructor?



How can I get through very long and very dry, but also very useful technical documents when learning a new tool?



Announcing the arrival of Valued Associate #679: Cesar Manara
Unicorn Meta Zoo #1: Why another podcast?Evaluating resources for teaching myself reinforcement learningLearning in a developing fieldStrategies for self-learners to transition into working on larger projectsWhat does a person with an undergraduate degree in CS still need to learn to be employable as a developer?Computer Engineering student with Holes in my knowledge (i want to improve)In self-teaching, how can I move from basic tutorials to more complex work?How to retain technical information about new features?What can be the causes of the difference in student performance?How to convince students that self learning is an important skill?How can I remain a programmer and move into currently “hot” areas?










24












$begingroup$


Vulkan is a very useful API for rendering projects, and I would like to learn how to use it as it opens up new possibilities for doing some rendering tricks much more efficiently than in OpenGl.



I am having significant trouble learning it, however. It is a very complex API with many essential details. These details, while useful, are not interesting enough in and of themself to reliably hold my attention for long periods, even if I put in significant effort. I find when I go through the written tutorials that I get very distracted by almost anything.



For example, when I was reading about its mechanism for selecting a GPU in a multi-GPU system instead of focusing on the syntax that I want to learn, I ended up thinking about all the implications of such a selection existing, compared to the fact that it does not in OpenGl. Distractions such as that end up drastically increasing the time that I need to spend on the reading, and skimming is not an option either as the details really are important.



There are also diminishing returns as my ability to use will power to remain focused diminishes much more quickly than I would like it to (I can only get through maybe ~10 pages of this reading in a single sitting while maintaining the focus that I feel is necessary.)



This problem is not unique to Vulkan. I had the same problem, but to a much lesser extent, when learning OpenGl. In that instance, I was able to find video tutorials that explained the necessary concepts very succinctly. This helped both because the explanations were more succinct, with only the necessary information (including theory when appropriate) to use the API (and I could look at written alternatives when I wanted more details).



When I attempted this for Vulkan, however, the only video tutorials that I could find were both outdated and contradicted the text tutorials in a few places, making me very weary of using them as I may pick up bad practices or outdated Vulkan. Video tutorials also work well for me as they keep on moving even if I get temporarily distracted, thus pulling my attention back. When reading, if I get distracted I automatically stop reading.



I would also like to note that this isn't an issue of lazyness; I am willing to put in significant time to do it, but I find that my ability to focus is quickly diminishing.



As such, I ask: How can I learn Vulkan (Ideally, the advice will be applicable to other similar tasks as well) reasonably efficiently and how can I counter the described road-blocks?










share|improve this question











$endgroup$











  • $begingroup$
    These aren't exactly answers (hence, a comment), but here's some discussion about similar academic questions: (1) How to stop hopping the learning chain and actually begin somewhere? (2) How to read papers without falling into a rabbit hole?
    $endgroup$
    – BurnsBA
    Mar 27 at 14:16















24












$begingroup$


Vulkan is a very useful API for rendering projects, and I would like to learn how to use it as it opens up new possibilities for doing some rendering tricks much more efficiently than in OpenGl.



I am having significant trouble learning it, however. It is a very complex API with many essential details. These details, while useful, are not interesting enough in and of themself to reliably hold my attention for long periods, even if I put in significant effort. I find when I go through the written tutorials that I get very distracted by almost anything.



For example, when I was reading about its mechanism for selecting a GPU in a multi-GPU system instead of focusing on the syntax that I want to learn, I ended up thinking about all the implications of such a selection existing, compared to the fact that it does not in OpenGl. Distractions such as that end up drastically increasing the time that I need to spend on the reading, and skimming is not an option either as the details really are important.



There are also diminishing returns as my ability to use will power to remain focused diminishes much more quickly than I would like it to (I can only get through maybe ~10 pages of this reading in a single sitting while maintaining the focus that I feel is necessary.)



This problem is not unique to Vulkan. I had the same problem, but to a much lesser extent, when learning OpenGl. In that instance, I was able to find video tutorials that explained the necessary concepts very succinctly. This helped both because the explanations were more succinct, with only the necessary information (including theory when appropriate) to use the API (and I could look at written alternatives when I wanted more details).



When I attempted this for Vulkan, however, the only video tutorials that I could find were both outdated and contradicted the text tutorials in a few places, making me very weary of using them as I may pick up bad practices or outdated Vulkan. Video tutorials also work well for me as they keep on moving even if I get temporarily distracted, thus pulling my attention back. When reading, if I get distracted I automatically stop reading.



I would also like to note that this isn't an issue of lazyness; I am willing to put in significant time to do it, but I find that my ability to focus is quickly diminishing.



As such, I ask: How can I learn Vulkan (Ideally, the advice will be applicable to other similar tasks as well) reasonably efficiently and how can I counter the described road-blocks?










share|improve this question











$endgroup$











  • $begingroup$
    These aren't exactly answers (hence, a comment), but here's some discussion about similar academic questions: (1) How to stop hopping the learning chain and actually begin somewhere? (2) How to read papers without falling into a rabbit hole?
    $endgroup$
    – BurnsBA
    Mar 27 at 14:16













24












24








24


7



$begingroup$


Vulkan is a very useful API for rendering projects, and I would like to learn how to use it as it opens up new possibilities for doing some rendering tricks much more efficiently than in OpenGl.



I am having significant trouble learning it, however. It is a very complex API with many essential details. These details, while useful, are not interesting enough in and of themself to reliably hold my attention for long periods, even if I put in significant effort. I find when I go through the written tutorials that I get very distracted by almost anything.



For example, when I was reading about its mechanism for selecting a GPU in a multi-GPU system instead of focusing on the syntax that I want to learn, I ended up thinking about all the implications of such a selection existing, compared to the fact that it does not in OpenGl. Distractions such as that end up drastically increasing the time that I need to spend on the reading, and skimming is not an option either as the details really are important.



There are also diminishing returns as my ability to use will power to remain focused diminishes much more quickly than I would like it to (I can only get through maybe ~10 pages of this reading in a single sitting while maintaining the focus that I feel is necessary.)



This problem is not unique to Vulkan. I had the same problem, but to a much lesser extent, when learning OpenGl. In that instance, I was able to find video tutorials that explained the necessary concepts very succinctly. This helped both because the explanations were more succinct, with only the necessary information (including theory when appropriate) to use the API (and I could look at written alternatives when I wanted more details).



When I attempted this for Vulkan, however, the only video tutorials that I could find were both outdated and contradicted the text tutorials in a few places, making me very weary of using them as I may pick up bad practices or outdated Vulkan. Video tutorials also work well for me as they keep on moving even if I get temporarily distracted, thus pulling my attention back. When reading, if I get distracted I automatically stop reading.



I would also like to note that this isn't an issue of lazyness; I am willing to put in significant time to do it, but I find that my ability to focus is quickly diminishing.



As such, I ask: How can I learn Vulkan (Ideally, the advice will be applicable to other similar tasks as well) reasonably efficiently and how can I counter the described road-blocks?










share|improve this question











$endgroup$




Vulkan is a very useful API for rendering projects, and I would like to learn how to use it as it opens up new possibilities for doing some rendering tricks much more efficiently than in OpenGl.



I am having significant trouble learning it, however. It is a very complex API with many essential details. These details, while useful, are not interesting enough in and of themself to reliably hold my attention for long periods, even if I put in significant effort. I find when I go through the written tutorials that I get very distracted by almost anything.



For example, when I was reading about its mechanism for selecting a GPU in a multi-GPU system instead of focusing on the syntax that I want to learn, I ended up thinking about all the implications of such a selection existing, compared to the fact that it does not in OpenGl. Distractions such as that end up drastically increasing the time that I need to spend on the reading, and skimming is not an option either as the details really are important.



There are also diminishing returns as my ability to use will power to remain focused diminishes much more quickly than I would like it to (I can only get through maybe ~10 pages of this reading in a single sitting while maintaining the focus that I feel is necessary.)



This problem is not unique to Vulkan. I had the same problem, but to a much lesser extent, when learning OpenGl. In that instance, I was able to find video tutorials that explained the necessary concepts very succinctly. This helped both because the explanations were more succinct, with only the necessary information (including theory when appropriate) to use the API (and I could look at written alternatives when I wanted more details).



When I attempted this for Vulkan, however, the only video tutorials that I could find were both outdated and contradicted the text tutorials in a few places, making me very weary of using them as I may pick up bad practices or outdated Vulkan. Video tutorials also work well for me as they keep on moving even if I get temporarily distracted, thus pulling my attention back. When reading, if I get distracted I automatically stop reading.



I would also like to note that this isn't an issue of lazyness; I am willing to put in significant time to do it, but I find that my ability to focus is quickly diminishing.



As such, I ask: How can I learn Vulkan (Ideally, the advice will be applicable to other similar tasks as well) reasonably efficiently and how can I counter the described road-blocks?







self-learning






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 26 at 22:00









Ben I.

18.4k740108




18.4k740108










asked Mar 26 at 19:01









john01davjohn01dav

22316




22316











  • $begingroup$
    These aren't exactly answers (hence, a comment), but here's some discussion about similar academic questions: (1) How to stop hopping the learning chain and actually begin somewhere? (2) How to read papers without falling into a rabbit hole?
    $endgroup$
    – BurnsBA
    Mar 27 at 14:16
















  • $begingroup$
    These aren't exactly answers (hence, a comment), but here's some discussion about similar academic questions: (1) How to stop hopping the learning chain and actually begin somewhere? (2) How to read papers without falling into a rabbit hole?
    $endgroup$
    – BurnsBA
    Mar 27 at 14:16















$begingroup$
These aren't exactly answers (hence, a comment), but here's some discussion about similar academic questions: (1) How to stop hopping the learning chain and actually begin somewhere? (2) How to read papers without falling into a rabbit hole?
$endgroup$
– BurnsBA
Mar 27 at 14:16




$begingroup$
These aren't exactly answers (hence, a comment), but here's some discussion about similar academic questions: (1) How to stop hopping the learning chain and actually begin somewhere? (2) How to read papers without falling into a rabbit hole?
$endgroup$
– BurnsBA
Mar 27 at 14:16










11 Answers
11






active

oldest

votes


















8












$begingroup$

As someone who has read through the OpenGL and Vulkan specifications, I've always found that it's best to digest them in bite-sized chunks. Never try to binge on the whole document in one day. Indeed, the kind of "distraction" you're talking about, thinking about the ramifications of a particular API, is a good thing; it helps the knowledge stick.



There are two ways to read something like this, depending entirely on your familiarity with the subject matter.



If you are unfamiliar with the subject (for this Vulkan example, you would be a person who doesn't have much of an idea on how 3D graphics works), it's best to just start at the beginning.



Read a chapter of the specification. As you're reading it, try to map the concepts it talks about to things you already know. Also, try to make note of what it has aluded to (specifications are not written like reference documentation; they will often talk about concepts not yet introduced), so that when you get to that part, you'll understand how it fits in. Lastly, think about the implications of what is said in that chapter; try to wrap your brain around what it all means.



The next day, read another chapter.



If you have some familiarity with the system, then I would say it's best to start with what is familiar to you, and branch out from there. For example, if you were a modern OpenGL user who is learning Vulkan, you might start with the chapter on drawing commands.



When you jump into the middle like this, you'll hear about a lot of concepts you don't know: devices, command buffers, pipeline stages, etc. But you'll also start noticing that some of them are similar to things you do know: shader stages, primitives, etc. That helps build a translation layer between what you know and what you don't, as well as giving you some places to start learning more.



Once you have a list of Vulkan topics you don't know, then you start following links to chapters and sections that talk about them. Go to the section on command buffers, and you'll find stuff about queues, devices, and that all important Vulkan topic, synchronization. Each of these steps should be its own session of investigation.



When you do this, it's best to treat these new topics as black boxes; don't try to speculate too much about what they do until you've actually read about them. Or at the very least, if you speculate about them, be willing to readjust your speculation based on any reality you later discover.



Oh, and regardless of which way you're doing it, you should take notes. That is always helpful when dealing with complex information like this. Write down what it is you think these complex things are. If you find out that something isn't how you thought it would be, change your notes.






share|improve this answer









$endgroup$




















    27












    $begingroup$

    Man, I'm right there with you. I understand completely your situation, as I've been there myself many times.



    The key, I find, is not reading the tutorials.



    Instead, I pick a few projects - starting with something that's "hello, world" level. I google and read enough to be able to do that. Then I pick a slightly harder project - for Vulkan, maybe pick a scene of intermediate difficulty, and google and read enough to do that.



    If you keep doing this, you very quickly obtain a practical base of knowledge. There are, however, disadvantages to this - obviously, there will be holes in your knowledge, and you could miss style guidelines depending on what you're looking at to write your code (e.g., when I first learned python, I came into it knowing how to program in javascript - so my first instinct was to write variable names in camelCase, and it was only after several years that I actually read PEP8 and changed to under_scores, though in my defense I didn't even realize style guides were a thing at the time).



    You might even wish to go through this approach, and then read through the tutorials with the perspective of someone who's "brushing up" - this might fill in the crevices the more trial and error method doesn't fill.



    If, however, you wish to fully work through the documentation straight off, I'd recommend reading a paragraph/section, and writing down something about how you'd use what you just learned about in a real program - i.e., mentally applying the small details. You want to build up a 'web' of details, with lots of connections between the nodes, so that every node is much easier to 'get to' (remember). The more you know, the more you remember (as odd/obvious as that sounds).






    share|improve this answer









    $endgroup$












    • $begingroup$
      This sounds like a really good idea, and something that is in line with my learning style. I do see one issue, however. That is that for Vulkan in particular there is a lot of background that is needed to do something even at a hello world level. I've seen posts that claim that you need over 1,000 lines of code to draw a triangle. This background makes an approach where I look for specific things less useful, as I won't know what specific things to look for.
      $endgroup$
      – john01dav
      Mar 27 at 1:37






    • 1




      $begingroup$
      @john01dav hmm, that is frustrating. I guess maybe you need to recalibrate what "hello world" looks like for vulkan, then? I don't know enough about Vulkan to be able to provide specific advice, but maybe you're doing something that doesn't draw anything on the screen, but sets something up in the background - anything, really (is there something in vulkan that acts as console.log or print for debugging?). It's just got to start small, so you can start seeing results quickly.
      $endgroup$
      – heather
      Mar 27 at 13:39










    • $begingroup$
      @john01dav these challenges are part of the reason why people build rendering/game/graphics engines on top of standards like Vulcan/OpenGL/DirectX. Its hard to understand and do all this stuff, and while knowledge is always useful, understanding exactly what goes into 1000 lines of boilerplate might have a lower payoff than something else.
      $endgroup$
      – mbrig
      Mar 27 at 21:32










    • $begingroup$
      @mbrig OpenGL takes nowhere near as much boilerplate, and can be easily encapsulated, it takes < 100 lines to draw a triangle with textures, I often find it easier to work in OpenGL than higherlevel engines, because now I not only need to know how what is going on with rendering, I have to understand this upper level API that restrict things (unless it is a framework that doesn't restrict access to rendering).
      $endgroup$
      – opa
      Mar 28 at 15:31






    • 1




      $begingroup$
      @lucasgcb: See this SO answer with the relevant quotes from PEP8.
      $endgroup$
      – heather
      Mar 29 at 13:28


















    9












    $begingroup$

    I've found that a useful trick is to have a specific project or end goal in mind. That helps to focus your attention on completing that project or goal, and gives you a purpose to think about what you're reading. It can also help you retain more of what you're reading, since you're always applying the new things you're learning.



    Frequently, you'll be able to find beginner oriented projects online that you could try to build, or maybe you have some vision or project that you want to use this new technology for.



    I find that having a project or goal really helps you 1) stay motivated to keep reading 2) retain the material (and have some code snippets to use later), and 3) not get lost down long rabbit holes (although this still requires some willpower).



    Good luck!






    share|improve this answer









    $endgroup$












    • $begingroup$
      +1. And it makes a huge difference if the project is something I really want to make, as opposed to some homework I assigned myself because I wanted to add something to my resume. When I'm passionate about the end goal, the dry documentation suddenly becomes fascinating.
      $endgroup$
      – TKK
      Mar 29 at 15:00


















    5












    $begingroup$

    The answers by heather and thesecretmaster are already spot-on: give yourself a project to work towards.



    APIs are tools. It doesn't really make sense to "learn an API" by itself, in the same way that it doesn't make sense to "learn a hammer" by itself. You should be figuring out how a specific tool solves a specific problem. For that, you need a problem first.



    Another suggestion I haven't seen in any of the existing answers is: write your own documentation as you read through the existing documentation.



    If you read through a page of their documentation, try to boil it down to a bare minimum. What was the takeaway? It's probably a sentence or two, or a snippet of code. Start your own documentation that collects these takeaways.



    When you have enough of these takeaways, you can start thinking about: How would you organize the documentation differently? What should "hello world" look like? What topic should come right after that?



    I highly recommend publishing your new and improved documentation somewhere: to a personal blog, as a pull request to the original documentation, or as answers on Stack Overflow. But even if you don't publish them, the process of coming up with them in the first place can be extremely educational.






    share|improve this answer









    $endgroup$




















      4












      $begingroup$

      I am right there with you; I find it incredibly difficult to work through something substantial and new without disappearing down many little rabbit holes.



      Here's a simple idea: have you considered just making a list of "questions to answer"? It would be for items that you want to explore in order to flesh out your understanding, but aren't in the main thread of your learning.



      Items on the list would resolve in one of four ways:



      1. It graduates to the main thread when you stop understanding what is going on.

      2. You come to understand it over time without doing an explicit research, just from context and osmosis.

      3. Through devoted time (perhaps at the end of a session, when your attention is starting to flag anyway), you eventually fill in the hole with some side-research.

      4. It turns out to be unimportant enough that it never comes up again, and can safely be ignored.

      The most important things, I think, are not to go down every rabbit hole you see right away, and to reserve some time to go through the list from time to time and fill in some of the missing puzzle pieces.






      share|improve this answer









      $endgroup$




















        3












        $begingroup$

        Almost all of my advice is from Courseras "Learning how to learn" which I highly recommend.



        1. Take breaks.
          Study for maybe 20 minutes then take a short break.
          Do something physical in these breaks if possible like some squats, push-ups or go for a short walk.


        2. Make sure you have plenty of fresh air.
          High levels of CO2 and low levels of O2 make us tired.


        3. Take notes.
          After reading a section write down what you learned.
          You might even make these a blog post or do a short talk about it.


        4. Do practical things.
          This was recommended by others: Instead of just brute force learning, pick a task and learn what you need to learn for that task.
          This helps with motivation and also by linking the knowledge to other experiences making it easier to remember.


        5. Take notes about what to learn.
          You mention getting sidetracked often by looking stuff up that is not directly related to what you are trying to learn right now.
          Use your notes to write down what you'd like to look up then look it up when the time is right.


        6. Repeat.
          We can't internalize complex knowledge directly.
          We need to repeat and practice it.
          With software APIs, katas are a proven way to do that.
          When you learn something new, make a tiny project putting the knowledge to use.
          This should take about 30min.
          Repeat this project after a short break.
          Then again maybe on the next day.
          Repetition with increasing time in between makes sure the knowledge ends up in long term memory.






        share|improve this answer









        $endgroup$




















          3












          $begingroup$

          One very simple technique I have found useful in processing information which I do not understand easily, is to review it multiple times, preferably in different sessions.



          You said:




          (I can only get through maybe ~10 pages of this reading in a single sitting while maintaining the focus that I feel is necessary.)




          and this implies to me that you consider the reading something to do once. I have found that reading the same material again and again (ideally with sleep periods between these sessions, but at least with some rest), allows me to understand things that I cannot understand on the first reading.



          I understand that this makes your reading process even longer, but it is one way to get the job done, and at least the enhanced understanding of subsequent reads can provide you with some more motivation to carry you through.



          One suggestion here could be to split your time between (a) reading at the "head" of your progress through the documentation, and (b) re-reading parts of the documentation you've already read previously, and then possibly (c) re-reading parts you've already re-read, i.e. re-re-reading.



          On second and third readings, you brain will be able to find deeper connections between the seemingly disparate details, and the material will seem less "dry".






          share|improve this answer









          $endgroup$




















            3












            $begingroup$

            I do read one time fully, without worrying about remembering. And then I pick a beginner project and start learning by doing. There is no way to read and remember all those dry details. But you will remember where to look when you get stuck in your projects. I was quite successful with this method, many times.






            share|improve this answer









            $endgroup$








            • 1




              $begingroup$
              Welcome to Computer Science Educators! This answer seems to have good potential. could you perhaps expand it with slightly more concrete examples? Either way, I personally find this to be quite a good answer. I sure hope we'll see more content such as this answer from you again :)
              $endgroup$
              – ItamarG3
              Mar 29 at 10:34











            • $begingroup$
              @ItamarG3 Thank you, flattered :) I think the answer already explains my approach totally I'm not sure how can I expand it. But if you have a question or you think something is unclear, I can gladly include an answer for it. Thanks for your time.
              $endgroup$
              – ferit
              Mar 29 at 17:52


















            3












            $begingroup$


            For example, when I was reading about its mechanism for selecting a
            GPU in a multi-GPU system instead of focusing on the syntax that I
            want to learn, I ended up thinking about all the implications of such
            a selection existing, compared to the fact that it does not in OpenGl.




            Yes humans can not be programmed. This is not a good way to learn. You are being distracted, because what you are reading is not useful. Syntax is not the important bit.



            As an experienced programmer, I just look it up as I go. I need to find something that gives me a good overview of what it does (not how), what the philosophy of it is. Then I just get on with it (very slowly at first), and look stuff up just-in-time. Sometimes I look stuff up more than once.






            share|improve this answer









            $endgroup$




















              2












              $begingroup$

              Suggestions:



              • Do not just read the API, but focus on actually doing what you want to do. I don't know Vulcan, but many other APIs, language specifications, protocol specifications etc. You can skim them quickly to see what the API has to offer (the general topics, architectural overview etc.). But then try to use the API. At first, you will immediately hit your first roadblocks. Then go and try to overcome each individual block, by delving into the dry documentation. Your carrot is the small goal you are currently trying to achieve. This is a good point for StackOverflow as well... if you have very concrete problems, you can just ask.

              • Avoid tutorials. Exceptions notwithstanding, they are the devil for building deep know-how, in my experience and strong opinion. They are often outdated; they represent the usual limited understanding of the author. They are specialized to whatever the author needed at the moment, and his opinions about how APIs should be used. About the only good case for tutorials is for a short "hello world"-style piece which gets you running from a blank slate (i.e., gives you the bare minimum commands to compile your first program or whatever you're doing). But as soon as you have even the slightest working bit of program, get rid of them ASAP.

              • Do not feel that you are somehow inferiour or whatever. In my long experience, most people do not want to, or actually cannot read specifications/reference documentation. You are in good company. But don't give up...

              Good luck.






              share|improve this answer











              $endgroup$








              • 1




                $begingroup$
                The comment about tutorials is valid for many hastily-put-together articles found on the web, often written by someone who is no expert and wants to share what he/she has just learned. But there are also tutorials that are very carefully designed, crafted, and reviewed by experts. You need to be able to recognise the difference.
                $endgroup$
                – Michael Kay
                Mar 27 at 10:21






              • 1




                $begingroup$
                @MichaelKay, I've added an "exceptions notwithstanding". As a counterexample to your counterexample I'll mention a once de-facto Ruby-on-Rails tutorial, which was in fact a very long and extremely well written e-book/website. Both didactically great; written in clean and well understandable tone. Exactly what you propose. The problem? It is for Rails 3. Rails 4+ are radically different. Most of the info in that tutorial is not only replaced by more modern stuff, but doesn't work anymore, outright. The problem? As it's so good, it still often turns up quite high in searches, and it is really...
                $endgroup$
                – AnoE
                Mar 27 at 12:17











              • $begingroup$
                ... tempting and easy to fall into the trap of using/studying it; eventually getting ever more and more confused due to the fact that things mysteriously fail to work over time. But really worst of all; even the parts that still work follow an outdated mode of operation for several parts of that ecosystem. All in all, a developer following that as his main source at the beginning sets out with a (in part radically) wrong understanding, laying plenty of obstacles in the way.
                $endgroup$
                – AnoE
                Mar 27 at 12:18










              • $begingroup$
                Yes, out-of-date information is always a problem on the web.
                $endgroup$
                – Michael Kay
                Mar 27 at 12:53


















              1












              $begingroup$

              You're not alone.



              Try to focus on "what do I need to know now?". On first reading, you need to understand the basic concepts. Try to find the sections of the document that explain them. (Many technical documents are bad at explaining them, or don't put the explanations in the obvious place.) If you find some text that you don't understand because you don't know what the words mean, stop reading (there's absolutely no point carrying on) and try and find where in the document the words are explained.



              If you find a section that's all about edge cases (how does the system handle division by zero), recognise that and skip it. You don't need to know that right now.



              On your first reading, try not just to absorb the content, but also to form an assessment of what kind of document you are reading. What kind of reader is it aimed at, and is that you? Which is going to be more useful, the examples, or the formal narrative? How careful is the writer about explaining things? Does it use terminology consistently and accurately? Understanding how the writer's mind is working can help your reading: if you come across a word like "specify" or "denote", are they using it carefully or carelessly?



              Think carefully about how to balance reading with hands-on experimentation. Some people start the hands-on too early, before they understand the concepts; that can lead to you drawing false conclusions about the system's behaviour, and to frustration that you can't make anything work. But if the documentation has "Hello world" examples to take you through things gently, then try them out. Not only will it give you confidence that you're following the text and making progress, it will keep you fresh and stop you falling asleep.






              share|improve this answer









              $endgroup$













                Your Answer








                StackExchange.ready(function()
                var channelOptions =
                tags: "".split(" "),
                id: "678"
                ;
                initTagRenderer("".split(" "), "".split(" "), channelOptions);

                StackExchange.using("externalEditor", function()
                // Have to fire editor after snippets, if snippets enabled
                if (StackExchange.settings.snippets.snippetsEnabled)
                StackExchange.using("snippets", function()
                createEditor();
                );

                else
                createEditor();

                );

                function createEditor()
                StackExchange.prepareEditor(
                heartbeatType: 'answer',
                autoActivateHeartbeat: false,
                convertImagesToLinks: false,
                noModals: true,
                showLowRepImageUploadWarning: true,
                reputationToPostImages: null,
                bindNavPrevention: true,
                postfix: "",
                imageUploader:
                brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
                contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
                allowUrls: true
                ,
                onDemand: true,
                discardSelector: ".discard-answer"
                ,immediatelyShowMarkdownHelp:true
                );



                );













                draft saved

                draft discarded


















                StackExchange.ready(
                function ()
                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcseducators.stackexchange.com%2fquestions%2f5492%2fhow-can-i-get-through-very-long-and-very-dry-but-also-very-useful-technical-doc%23new-answer', 'question_page');

                );

                Post as a guest















                Required, but never shown

























                11 Answers
                11






                active

                oldest

                votes








                11 Answers
                11






                active

                oldest

                votes









                active

                oldest

                votes






                active

                oldest

                votes









                8












                $begingroup$

                As someone who has read through the OpenGL and Vulkan specifications, I've always found that it's best to digest them in bite-sized chunks. Never try to binge on the whole document in one day. Indeed, the kind of "distraction" you're talking about, thinking about the ramifications of a particular API, is a good thing; it helps the knowledge stick.



                There are two ways to read something like this, depending entirely on your familiarity with the subject matter.



                If you are unfamiliar with the subject (for this Vulkan example, you would be a person who doesn't have much of an idea on how 3D graphics works), it's best to just start at the beginning.



                Read a chapter of the specification. As you're reading it, try to map the concepts it talks about to things you already know. Also, try to make note of what it has aluded to (specifications are not written like reference documentation; they will often talk about concepts not yet introduced), so that when you get to that part, you'll understand how it fits in. Lastly, think about the implications of what is said in that chapter; try to wrap your brain around what it all means.



                The next day, read another chapter.



                If you have some familiarity with the system, then I would say it's best to start with what is familiar to you, and branch out from there. For example, if you were a modern OpenGL user who is learning Vulkan, you might start with the chapter on drawing commands.



                When you jump into the middle like this, you'll hear about a lot of concepts you don't know: devices, command buffers, pipeline stages, etc. But you'll also start noticing that some of them are similar to things you do know: shader stages, primitives, etc. That helps build a translation layer between what you know and what you don't, as well as giving you some places to start learning more.



                Once you have a list of Vulkan topics you don't know, then you start following links to chapters and sections that talk about them. Go to the section on command buffers, and you'll find stuff about queues, devices, and that all important Vulkan topic, synchronization. Each of these steps should be its own session of investigation.



                When you do this, it's best to treat these new topics as black boxes; don't try to speculate too much about what they do until you've actually read about them. Or at the very least, if you speculate about them, be willing to readjust your speculation based on any reality you later discover.



                Oh, and regardless of which way you're doing it, you should take notes. That is always helpful when dealing with complex information like this. Write down what it is you think these complex things are. If you find out that something isn't how you thought it would be, change your notes.






                share|improve this answer









                $endgroup$

















                  8












                  $begingroup$

                  As someone who has read through the OpenGL and Vulkan specifications, I've always found that it's best to digest them in bite-sized chunks. Never try to binge on the whole document in one day. Indeed, the kind of "distraction" you're talking about, thinking about the ramifications of a particular API, is a good thing; it helps the knowledge stick.



                  There are two ways to read something like this, depending entirely on your familiarity with the subject matter.



                  If you are unfamiliar with the subject (for this Vulkan example, you would be a person who doesn't have much of an idea on how 3D graphics works), it's best to just start at the beginning.



                  Read a chapter of the specification. As you're reading it, try to map the concepts it talks about to things you already know. Also, try to make note of what it has aluded to (specifications are not written like reference documentation; they will often talk about concepts not yet introduced), so that when you get to that part, you'll understand how it fits in. Lastly, think about the implications of what is said in that chapter; try to wrap your brain around what it all means.



                  The next day, read another chapter.



                  If you have some familiarity with the system, then I would say it's best to start with what is familiar to you, and branch out from there. For example, if you were a modern OpenGL user who is learning Vulkan, you might start with the chapter on drawing commands.



                  When you jump into the middle like this, you'll hear about a lot of concepts you don't know: devices, command buffers, pipeline stages, etc. But you'll also start noticing that some of them are similar to things you do know: shader stages, primitives, etc. That helps build a translation layer between what you know and what you don't, as well as giving you some places to start learning more.



                  Once you have a list of Vulkan topics you don't know, then you start following links to chapters and sections that talk about them. Go to the section on command buffers, and you'll find stuff about queues, devices, and that all important Vulkan topic, synchronization. Each of these steps should be its own session of investigation.



                  When you do this, it's best to treat these new topics as black boxes; don't try to speculate too much about what they do until you've actually read about them. Or at the very least, if you speculate about them, be willing to readjust your speculation based on any reality you later discover.



                  Oh, and regardless of which way you're doing it, you should take notes. That is always helpful when dealing with complex information like this. Write down what it is you think these complex things are. If you find out that something isn't how you thought it would be, change your notes.






                  share|improve this answer









                  $endgroup$















                    8












                    8








                    8





                    $begingroup$

                    As someone who has read through the OpenGL and Vulkan specifications, I've always found that it's best to digest them in bite-sized chunks. Never try to binge on the whole document in one day. Indeed, the kind of "distraction" you're talking about, thinking about the ramifications of a particular API, is a good thing; it helps the knowledge stick.



                    There are two ways to read something like this, depending entirely on your familiarity with the subject matter.



                    If you are unfamiliar with the subject (for this Vulkan example, you would be a person who doesn't have much of an idea on how 3D graphics works), it's best to just start at the beginning.



                    Read a chapter of the specification. As you're reading it, try to map the concepts it talks about to things you already know. Also, try to make note of what it has aluded to (specifications are not written like reference documentation; they will often talk about concepts not yet introduced), so that when you get to that part, you'll understand how it fits in. Lastly, think about the implications of what is said in that chapter; try to wrap your brain around what it all means.



                    The next day, read another chapter.



                    If you have some familiarity with the system, then I would say it's best to start with what is familiar to you, and branch out from there. For example, if you were a modern OpenGL user who is learning Vulkan, you might start with the chapter on drawing commands.



                    When you jump into the middle like this, you'll hear about a lot of concepts you don't know: devices, command buffers, pipeline stages, etc. But you'll also start noticing that some of them are similar to things you do know: shader stages, primitives, etc. That helps build a translation layer between what you know and what you don't, as well as giving you some places to start learning more.



                    Once you have a list of Vulkan topics you don't know, then you start following links to chapters and sections that talk about them. Go to the section on command buffers, and you'll find stuff about queues, devices, and that all important Vulkan topic, synchronization. Each of these steps should be its own session of investigation.



                    When you do this, it's best to treat these new topics as black boxes; don't try to speculate too much about what they do until you've actually read about them. Or at the very least, if you speculate about them, be willing to readjust your speculation based on any reality you later discover.



                    Oh, and regardless of which way you're doing it, you should take notes. That is always helpful when dealing with complex information like this. Write down what it is you think these complex things are. If you find out that something isn't how you thought it would be, change your notes.






                    share|improve this answer









                    $endgroup$



                    As someone who has read through the OpenGL and Vulkan specifications, I've always found that it's best to digest them in bite-sized chunks. Never try to binge on the whole document in one day. Indeed, the kind of "distraction" you're talking about, thinking about the ramifications of a particular API, is a good thing; it helps the knowledge stick.



                    There are two ways to read something like this, depending entirely on your familiarity with the subject matter.



                    If you are unfamiliar with the subject (for this Vulkan example, you would be a person who doesn't have much of an idea on how 3D graphics works), it's best to just start at the beginning.



                    Read a chapter of the specification. As you're reading it, try to map the concepts it talks about to things you already know. Also, try to make note of what it has aluded to (specifications are not written like reference documentation; they will often talk about concepts not yet introduced), so that when you get to that part, you'll understand how it fits in. Lastly, think about the implications of what is said in that chapter; try to wrap your brain around what it all means.



                    The next day, read another chapter.



                    If you have some familiarity with the system, then I would say it's best to start with what is familiar to you, and branch out from there. For example, if you were a modern OpenGL user who is learning Vulkan, you might start with the chapter on drawing commands.



                    When you jump into the middle like this, you'll hear about a lot of concepts you don't know: devices, command buffers, pipeline stages, etc. But you'll also start noticing that some of them are similar to things you do know: shader stages, primitives, etc. That helps build a translation layer between what you know and what you don't, as well as giving you some places to start learning more.



                    Once you have a list of Vulkan topics you don't know, then you start following links to chapters and sections that talk about them. Go to the section on command buffers, and you'll find stuff about queues, devices, and that all important Vulkan topic, synchronization. Each of these steps should be its own session of investigation.



                    When you do this, it's best to treat these new topics as black boxes; don't try to speculate too much about what they do until you've actually read about them. Or at the very least, if you speculate about them, be willing to readjust your speculation based on any reality you later discover.



                    Oh, and regardless of which way you're doing it, you should take notes. That is always helpful when dealing with complex information like this. Write down what it is you think these complex things are. If you find out that something isn't how you thought it would be, change your notes.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Mar 27 at 19:16









                    Nicol BolasNicol Bolas

                    1963




                    1963





















                        27












                        $begingroup$

                        Man, I'm right there with you. I understand completely your situation, as I've been there myself many times.



                        The key, I find, is not reading the tutorials.



                        Instead, I pick a few projects - starting with something that's "hello, world" level. I google and read enough to be able to do that. Then I pick a slightly harder project - for Vulkan, maybe pick a scene of intermediate difficulty, and google and read enough to do that.



                        If you keep doing this, you very quickly obtain a practical base of knowledge. There are, however, disadvantages to this - obviously, there will be holes in your knowledge, and you could miss style guidelines depending on what you're looking at to write your code (e.g., when I first learned python, I came into it knowing how to program in javascript - so my first instinct was to write variable names in camelCase, and it was only after several years that I actually read PEP8 and changed to under_scores, though in my defense I didn't even realize style guides were a thing at the time).



                        You might even wish to go through this approach, and then read through the tutorials with the perspective of someone who's "brushing up" - this might fill in the crevices the more trial and error method doesn't fill.



                        If, however, you wish to fully work through the documentation straight off, I'd recommend reading a paragraph/section, and writing down something about how you'd use what you just learned about in a real program - i.e., mentally applying the small details. You want to build up a 'web' of details, with lots of connections between the nodes, so that every node is much easier to 'get to' (remember). The more you know, the more you remember (as odd/obvious as that sounds).






                        share|improve this answer









                        $endgroup$












                        • $begingroup$
                          This sounds like a really good idea, and something that is in line with my learning style. I do see one issue, however. That is that for Vulkan in particular there is a lot of background that is needed to do something even at a hello world level. I've seen posts that claim that you need over 1,000 lines of code to draw a triangle. This background makes an approach where I look for specific things less useful, as I won't know what specific things to look for.
                          $endgroup$
                          – john01dav
                          Mar 27 at 1:37






                        • 1




                          $begingroup$
                          @john01dav hmm, that is frustrating. I guess maybe you need to recalibrate what "hello world" looks like for vulkan, then? I don't know enough about Vulkan to be able to provide specific advice, but maybe you're doing something that doesn't draw anything on the screen, but sets something up in the background - anything, really (is there something in vulkan that acts as console.log or print for debugging?). It's just got to start small, so you can start seeing results quickly.
                          $endgroup$
                          – heather
                          Mar 27 at 13:39










                        • $begingroup$
                          @john01dav these challenges are part of the reason why people build rendering/game/graphics engines on top of standards like Vulcan/OpenGL/DirectX. Its hard to understand and do all this stuff, and while knowledge is always useful, understanding exactly what goes into 1000 lines of boilerplate might have a lower payoff than something else.
                          $endgroup$
                          – mbrig
                          Mar 27 at 21:32










                        • $begingroup$
                          @mbrig OpenGL takes nowhere near as much boilerplate, and can be easily encapsulated, it takes < 100 lines to draw a triangle with textures, I often find it easier to work in OpenGL than higherlevel engines, because now I not only need to know how what is going on with rendering, I have to understand this upper level API that restrict things (unless it is a framework that doesn't restrict access to rendering).
                          $endgroup$
                          – opa
                          Mar 28 at 15:31






                        • 1




                          $begingroup$
                          @lucasgcb: See this SO answer with the relevant quotes from PEP8.
                          $endgroup$
                          – heather
                          Mar 29 at 13:28















                        27












                        $begingroup$

                        Man, I'm right there with you. I understand completely your situation, as I've been there myself many times.



                        The key, I find, is not reading the tutorials.



                        Instead, I pick a few projects - starting with something that's "hello, world" level. I google and read enough to be able to do that. Then I pick a slightly harder project - for Vulkan, maybe pick a scene of intermediate difficulty, and google and read enough to do that.



                        If you keep doing this, you very quickly obtain a practical base of knowledge. There are, however, disadvantages to this - obviously, there will be holes in your knowledge, and you could miss style guidelines depending on what you're looking at to write your code (e.g., when I first learned python, I came into it knowing how to program in javascript - so my first instinct was to write variable names in camelCase, and it was only after several years that I actually read PEP8 and changed to under_scores, though in my defense I didn't even realize style guides were a thing at the time).



                        You might even wish to go through this approach, and then read through the tutorials with the perspective of someone who's "brushing up" - this might fill in the crevices the more trial and error method doesn't fill.



                        If, however, you wish to fully work through the documentation straight off, I'd recommend reading a paragraph/section, and writing down something about how you'd use what you just learned about in a real program - i.e., mentally applying the small details. You want to build up a 'web' of details, with lots of connections between the nodes, so that every node is much easier to 'get to' (remember). The more you know, the more you remember (as odd/obvious as that sounds).






                        share|improve this answer









                        $endgroup$












                        • $begingroup$
                          This sounds like a really good idea, and something that is in line with my learning style. I do see one issue, however. That is that for Vulkan in particular there is a lot of background that is needed to do something even at a hello world level. I've seen posts that claim that you need over 1,000 lines of code to draw a triangle. This background makes an approach where I look for specific things less useful, as I won't know what specific things to look for.
                          $endgroup$
                          – john01dav
                          Mar 27 at 1:37






                        • 1




                          $begingroup$
                          @john01dav hmm, that is frustrating. I guess maybe you need to recalibrate what "hello world" looks like for vulkan, then? I don't know enough about Vulkan to be able to provide specific advice, but maybe you're doing something that doesn't draw anything on the screen, but sets something up in the background - anything, really (is there something in vulkan that acts as console.log or print for debugging?). It's just got to start small, so you can start seeing results quickly.
                          $endgroup$
                          – heather
                          Mar 27 at 13:39










                        • $begingroup$
                          @john01dav these challenges are part of the reason why people build rendering/game/graphics engines on top of standards like Vulcan/OpenGL/DirectX. Its hard to understand and do all this stuff, and while knowledge is always useful, understanding exactly what goes into 1000 lines of boilerplate might have a lower payoff than something else.
                          $endgroup$
                          – mbrig
                          Mar 27 at 21:32










                        • $begingroup$
                          @mbrig OpenGL takes nowhere near as much boilerplate, and can be easily encapsulated, it takes < 100 lines to draw a triangle with textures, I often find it easier to work in OpenGL than higherlevel engines, because now I not only need to know how what is going on with rendering, I have to understand this upper level API that restrict things (unless it is a framework that doesn't restrict access to rendering).
                          $endgroup$
                          – opa
                          Mar 28 at 15:31






                        • 1




                          $begingroup$
                          @lucasgcb: See this SO answer with the relevant quotes from PEP8.
                          $endgroup$
                          – heather
                          Mar 29 at 13:28













                        27












                        27








                        27





                        $begingroup$

                        Man, I'm right there with you. I understand completely your situation, as I've been there myself many times.



                        The key, I find, is not reading the tutorials.



                        Instead, I pick a few projects - starting with something that's "hello, world" level. I google and read enough to be able to do that. Then I pick a slightly harder project - for Vulkan, maybe pick a scene of intermediate difficulty, and google and read enough to do that.



                        If you keep doing this, you very quickly obtain a practical base of knowledge. There are, however, disadvantages to this - obviously, there will be holes in your knowledge, and you could miss style guidelines depending on what you're looking at to write your code (e.g., when I first learned python, I came into it knowing how to program in javascript - so my first instinct was to write variable names in camelCase, and it was only after several years that I actually read PEP8 and changed to under_scores, though in my defense I didn't even realize style guides were a thing at the time).



                        You might even wish to go through this approach, and then read through the tutorials with the perspective of someone who's "brushing up" - this might fill in the crevices the more trial and error method doesn't fill.



                        If, however, you wish to fully work through the documentation straight off, I'd recommend reading a paragraph/section, and writing down something about how you'd use what you just learned about in a real program - i.e., mentally applying the small details. You want to build up a 'web' of details, with lots of connections between the nodes, so that every node is much easier to 'get to' (remember). The more you know, the more you remember (as odd/obvious as that sounds).






                        share|improve this answer









                        $endgroup$



                        Man, I'm right there with you. I understand completely your situation, as I've been there myself many times.



                        The key, I find, is not reading the tutorials.



                        Instead, I pick a few projects - starting with something that's "hello, world" level. I google and read enough to be able to do that. Then I pick a slightly harder project - for Vulkan, maybe pick a scene of intermediate difficulty, and google and read enough to do that.



                        If you keep doing this, you very quickly obtain a practical base of knowledge. There are, however, disadvantages to this - obviously, there will be holes in your knowledge, and you could miss style guidelines depending on what you're looking at to write your code (e.g., when I first learned python, I came into it knowing how to program in javascript - so my first instinct was to write variable names in camelCase, and it was only after several years that I actually read PEP8 and changed to under_scores, though in my defense I didn't even realize style guides were a thing at the time).



                        You might even wish to go through this approach, and then read through the tutorials with the perspective of someone who's "brushing up" - this might fill in the crevices the more trial and error method doesn't fill.



                        If, however, you wish to fully work through the documentation straight off, I'd recommend reading a paragraph/section, and writing down something about how you'd use what you just learned about in a real program - i.e., mentally applying the small details. You want to build up a 'web' of details, with lots of connections between the nodes, so that every node is much easier to 'get to' (remember). The more you know, the more you remember (as odd/obvious as that sounds).







                        share|improve this answer












                        share|improve this answer



                        share|improve this answer










                        answered Mar 27 at 0:51









                        heatherheather

                        3,958836




                        3,958836











                        • $begingroup$
                          This sounds like a really good idea, and something that is in line with my learning style. I do see one issue, however. That is that for Vulkan in particular there is a lot of background that is needed to do something even at a hello world level. I've seen posts that claim that you need over 1,000 lines of code to draw a triangle. This background makes an approach where I look for specific things less useful, as I won't know what specific things to look for.
                          $endgroup$
                          – john01dav
                          Mar 27 at 1:37






                        • 1




                          $begingroup$
                          @john01dav hmm, that is frustrating. I guess maybe you need to recalibrate what "hello world" looks like for vulkan, then? I don't know enough about Vulkan to be able to provide specific advice, but maybe you're doing something that doesn't draw anything on the screen, but sets something up in the background - anything, really (is there something in vulkan that acts as console.log or print for debugging?). It's just got to start small, so you can start seeing results quickly.
                          $endgroup$
                          – heather
                          Mar 27 at 13:39










                        • $begingroup$
                          @john01dav these challenges are part of the reason why people build rendering/game/graphics engines on top of standards like Vulcan/OpenGL/DirectX. Its hard to understand and do all this stuff, and while knowledge is always useful, understanding exactly what goes into 1000 lines of boilerplate might have a lower payoff than something else.
                          $endgroup$
                          – mbrig
                          Mar 27 at 21:32










                        • $begingroup$
                          @mbrig OpenGL takes nowhere near as much boilerplate, and can be easily encapsulated, it takes < 100 lines to draw a triangle with textures, I often find it easier to work in OpenGL than higherlevel engines, because now I not only need to know how what is going on with rendering, I have to understand this upper level API that restrict things (unless it is a framework that doesn't restrict access to rendering).
                          $endgroup$
                          – opa
                          Mar 28 at 15:31






                        • 1




                          $begingroup$
                          @lucasgcb: See this SO answer with the relevant quotes from PEP8.
                          $endgroup$
                          – heather
                          Mar 29 at 13:28
















                        • $begingroup$
                          This sounds like a really good idea, and something that is in line with my learning style. I do see one issue, however. That is that for Vulkan in particular there is a lot of background that is needed to do something even at a hello world level. I've seen posts that claim that you need over 1,000 lines of code to draw a triangle. This background makes an approach where I look for specific things less useful, as I won't know what specific things to look for.
                          $endgroup$
                          – john01dav
                          Mar 27 at 1:37






                        • 1




                          $begingroup$
                          @john01dav hmm, that is frustrating. I guess maybe you need to recalibrate what "hello world" looks like for vulkan, then? I don't know enough about Vulkan to be able to provide specific advice, but maybe you're doing something that doesn't draw anything on the screen, but sets something up in the background - anything, really (is there something in vulkan that acts as console.log or print for debugging?). It's just got to start small, so you can start seeing results quickly.
                          $endgroup$
                          – heather
                          Mar 27 at 13:39










                        • $begingroup$
                          @john01dav these challenges are part of the reason why people build rendering/game/graphics engines on top of standards like Vulcan/OpenGL/DirectX. Its hard to understand and do all this stuff, and while knowledge is always useful, understanding exactly what goes into 1000 lines of boilerplate might have a lower payoff than something else.
                          $endgroup$
                          – mbrig
                          Mar 27 at 21:32










                        • $begingroup$
                          @mbrig OpenGL takes nowhere near as much boilerplate, and can be easily encapsulated, it takes < 100 lines to draw a triangle with textures, I often find it easier to work in OpenGL than higherlevel engines, because now I not only need to know how what is going on with rendering, I have to understand this upper level API that restrict things (unless it is a framework that doesn't restrict access to rendering).
                          $endgroup$
                          – opa
                          Mar 28 at 15:31






                        • 1




                          $begingroup$
                          @lucasgcb: See this SO answer with the relevant quotes from PEP8.
                          $endgroup$
                          – heather
                          Mar 29 at 13:28















                        $begingroup$
                        This sounds like a really good idea, and something that is in line with my learning style. I do see one issue, however. That is that for Vulkan in particular there is a lot of background that is needed to do something even at a hello world level. I've seen posts that claim that you need over 1,000 lines of code to draw a triangle. This background makes an approach where I look for specific things less useful, as I won't know what specific things to look for.
                        $endgroup$
                        – john01dav
                        Mar 27 at 1:37




                        $begingroup$
                        This sounds like a really good idea, and something that is in line with my learning style. I do see one issue, however. That is that for Vulkan in particular there is a lot of background that is needed to do something even at a hello world level. I've seen posts that claim that you need over 1,000 lines of code to draw a triangle. This background makes an approach where I look for specific things less useful, as I won't know what specific things to look for.
                        $endgroup$
                        – john01dav
                        Mar 27 at 1:37




                        1




                        1




                        $begingroup$
                        @john01dav hmm, that is frustrating. I guess maybe you need to recalibrate what "hello world" looks like for vulkan, then? I don't know enough about Vulkan to be able to provide specific advice, but maybe you're doing something that doesn't draw anything on the screen, but sets something up in the background - anything, really (is there something in vulkan that acts as console.log or print for debugging?). It's just got to start small, so you can start seeing results quickly.
                        $endgroup$
                        – heather
                        Mar 27 at 13:39




                        $begingroup$
                        @john01dav hmm, that is frustrating. I guess maybe you need to recalibrate what "hello world" looks like for vulkan, then? I don't know enough about Vulkan to be able to provide specific advice, but maybe you're doing something that doesn't draw anything on the screen, but sets something up in the background - anything, really (is there something in vulkan that acts as console.log or print for debugging?). It's just got to start small, so you can start seeing results quickly.
                        $endgroup$
                        – heather
                        Mar 27 at 13:39












                        $begingroup$
                        @john01dav these challenges are part of the reason why people build rendering/game/graphics engines on top of standards like Vulcan/OpenGL/DirectX. Its hard to understand and do all this stuff, and while knowledge is always useful, understanding exactly what goes into 1000 lines of boilerplate might have a lower payoff than something else.
                        $endgroup$
                        – mbrig
                        Mar 27 at 21:32




                        $begingroup$
                        @john01dav these challenges are part of the reason why people build rendering/game/graphics engines on top of standards like Vulcan/OpenGL/DirectX. Its hard to understand and do all this stuff, and while knowledge is always useful, understanding exactly what goes into 1000 lines of boilerplate might have a lower payoff than something else.
                        $endgroup$
                        – mbrig
                        Mar 27 at 21:32












                        $begingroup$
                        @mbrig OpenGL takes nowhere near as much boilerplate, and can be easily encapsulated, it takes < 100 lines to draw a triangle with textures, I often find it easier to work in OpenGL than higherlevel engines, because now I not only need to know how what is going on with rendering, I have to understand this upper level API that restrict things (unless it is a framework that doesn't restrict access to rendering).
                        $endgroup$
                        – opa
                        Mar 28 at 15:31




                        $begingroup$
                        @mbrig OpenGL takes nowhere near as much boilerplate, and can be easily encapsulated, it takes < 100 lines to draw a triangle with textures, I often find it easier to work in OpenGL than higherlevel engines, because now I not only need to know how what is going on with rendering, I have to understand this upper level API that restrict things (unless it is a framework that doesn't restrict access to rendering).
                        $endgroup$
                        – opa
                        Mar 28 at 15:31




                        1




                        1




                        $begingroup$
                        @lucasgcb: See this SO answer with the relevant quotes from PEP8.
                        $endgroup$
                        – heather
                        Mar 29 at 13:28




                        $begingroup$
                        @lucasgcb: See this SO answer with the relevant quotes from PEP8.
                        $endgroup$
                        – heather
                        Mar 29 at 13:28











                        9












                        $begingroup$

                        I've found that a useful trick is to have a specific project or end goal in mind. That helps to focus your attention on completing that project or goal, and gives you a purpose to think about what you're reading. It can also help you retain more of what you're reading, since you're always applying the new things you're learning.



                        Frequently, you'll be able to find beginner oriented projects online that you could try to build, or maybe you have some vision or project that you want to use this new technology for.



                        I find that having a project or goal really helps you 1) stay motivated to keep reading 2) retain the material (and have some code snippets to use later), and 3) not get lost down long rabbit holes (although this still requires some willpower).



                        Good luck!






                        share|improve this answer









                        $endgroup$












                        • $begingroup$
                          +1. And it makes a huge difference if the project is something I really want to make, as opposed to some homework I assigned myself because I wanted to add something to my resume. When I'm passionate about the end goal, the dry documentation suddenly becomes fascinating.
                          $endgroup$
                          – TKK
                          Mar 29 at 15:00















                        9












                        $begingroup$

                        I've found that a useful trick is to have a specific project or end goal in mind. That helps to focus your attention on completing that project or goal, and gives you a purpose to think about what you're reading. It can also help you retain more of what you're reading, since you're always applying the new things you're learning.



                        Frequently, you'll be able to find beginner oriented projects online that you could try to build, or maybe you have some vision or project that you want to use this new technology for.



                        I find that having a project or goal really helps you 1) stay motivated to keep reading 2) retain the material (and have some code snippets to use later), and 3) not get lost down long rabbit holes (although this still requires some willpower).



                        Good luck!






                        share|improve this answer









                        $endgroup$












                        • $begingroup$
                          +1. And it makes a huge difference if the project is something I really want to make, as opposed to some homework I assigned myself because I wanted to add something to my resume. When I'm passionate about the end goal, the dry documentation suddenly becomes fascinating.
                          $endgroup$
                          – TKK
                          Mar 29 at 15:00













                        9












                        9








                        9





                        $begingroup$

                        I've found that a useful trick is to have a specific project or end goal in mind. That helps to focus your attention on completing that project or goal, and gives you a purpose to think about what you're reading. It can also help you retain more of what you're reading, since you're always applying the new things you're learning.



                        Frequently, you'll be able to find beginner oriented projects online that you could try to build, or maybe you have some vision or project that you want to use this new technology for.



                        I find that having a project or goal really helps you 1) stay motivated to keep reading 2) retain the material (and have some code snippets to use later), and 3) not get lost down long rabbit holes (although this still requires some willpower).



                        Good luck!






                        share|improve this answer









                        $endgroup$



                        I've found that a useful trick is to have a specific project or end goal in mind. That helps to focus your attention on completing that project or goal, and gives you a purpose to think about what you're reading. It can also help you retain more of what you're reading, since you're always applying the new things you're learning.



                        Frequently, you'll be able to find beginner oriented projects online that you could try to build, or maybe you have some vision or project that you want to use this new technology for.



                        I find that having a project or goal really helps you 1) stay motivated to keep reading 2) retain the material (and have some code snippets to use later), and 3) not get lost down long rabbit holes (although this still requires some willpower).



                        Good luck!







                        share|improve this answer












                        share|improve this answer



                        share|improve this answer










                        answered Mar 26 at 20:41









                        thesecretmasterthesecretmaster

                        3,24831044




                        3,24831044











                        • $begingroup$
                          +1. And it makes a huge difference if the project is something I really want to make, as opposed to some homework I assigned myself because I wanted to add something to my resume. When I'm passionate about the end goal, the dry documentation suddenly becomes fascinating.
                          $endgroup$
                          – TKK
                          Mar 29 at 15:00
















                        • $begingroup$
                          +1. And it makes a huge difference if the project is something I really want to make, as opposed to some homework I assigned myself because I wanted to add something to my resume. When I'm passionate about the end goal, the dry documentation suddenly becomes fascinating.
                          $endgroup$
                          – TKK
                          Mar 29 at 15:00















                        $begingroup$
                        +1. And it makes a huge difference if the project is something I really want to make, as opposed to some homework I assigned myself because I wanted to add something to my resume. When I'm passionate about the end goal, the dry documentation suddenly becomes fascinating.
                        $endgroup$
                        – TKK
                        Mar 29 at 15:00




                        $begingroup$
                        +1. And it makes a huge difference if the project is something I really want to make, as opposed to some homework I assigned myself because I wanted to add something to my resume. When I'm passionate about the end goal, the dry documentation suddenly becomes fascinating.
                        $endgroup$
                        – TKK
                        Mar 29 at 15:00











                        5












                        $begingroup$

                        The answers by heather and thesecretmaster are already spot-on: give yourself a project to work towards.



                        APIs are tools. It doesn't really make sense to "learn an API" by itself, in the same way that it doesn't make sense to "learn a hammer" by itself. You should be figuring out how a specific tool solves a specific problem. For that, you need a problem first.



                        Another suggestion I haven't seen in any of the existing answers is: write your own documentation as you read through the existing documentation.



                        If you read through a page of their documentation, try to boil it down to a bare minimum. What was the takeaway? It's probably a sentence or two, or a snippet of code. Start your own documentation that collects these takeaways.



                        When you have enough of these takeaways, you can start thinking about: How would you organize the documentation differently? What should "hello world" look like? What topic should come right after that?



                        I highly recommend publishing your new and improved documentation somewhere: to a personal blog, as a pull request to the original documentation, or as answers on Stack Overflow. But even if you don't publish them, the process of coming up with them in the first place can be extremely educational.






                        share|improve this answer









                        $endgroup$

















                          5












                          $begingroup$

                          The answers by heather and thesecretmaster are already spot-on: give yourself a project to work towards.



                          APIs are tools. It doesn't really make sense to "learn an API" by itself, in the same way that it doesn't make sense to "learn a hammer" by itself. You should be figuring out how a specific tool solves a specific problem. For that, you need a problem first.



                          Another suggestion I haven't seen in any of the existing answers is: write your own documentation as you read through the existing documentation.



                          If you read through a page of their documentation, try to boil it down to a bare minimum. What was the takeaway? It's probably a sentence or two, or a snippet of code. Start your own documentation that collects these takeaways.



                          When you have enough of these takeaways, you can start thinking about: How would you organize the documentation differently? What should "hello world" look like? What topic should come right after that?



                          I highly recommend publishing your new and improved documentation somewhere: to a personal blog, as a pull request to the original documentation, or as answers on Stack Overflow. But even if you don't publish them, the process of coming up with them in the first place can be extremely educational.






                          share|improve this answer









                          $endgroup$















                            5












                            5








                            5





                            $begingroup$

                            The answers by heather and thesecretmaster are already spot-on: give yourself a project to work towards.



                            APIs are tools. It doesn't really make sense to "learn an API" by itself, in the same way that it doesn't make sense to "learn a hammer" by itself. You should be figuring out how a specific tool solves a specific problem. For that, you need a problem first.



                            Another suggestion I haven't seen in any of the existing answers is: write your own documentation as you read through the existing documentation.



                            If you read through a page of their documentation, try to boil it down to a bare minimum. What was the takeaway? It's probably a sentence or two, or a snippet of code. Start your own documentation that collects these takeaways.



                            When you have enough of these takeaways, you can start thinking about: How would you organize the documentation differently? What should "hello world" look like? What topic should come right after that?



                            I highly recommend publishing your new and improved documentation somewhere: to a personal blog, as a pull request to the original documentation, or as answers on Stack Overflow. But even if you don't publish them, the process of coming up with them in the first place can be extremely educational.






                            share|improve this answer









                            $endgroup$



                            The answers by heather and thesecretmaster are already spot-on: give yourself a project to work towards.



                            APIs are tools. It doesn't really make sense to "learn an API" by itself, in the same way that it doesn't make sense to "learn a hammer" by itself. You should be figuring out how a specific tool solves a specific problem. For that, you need a problem first.



                            Another suggestion I haven't seen in any of the existing answers is: write your own documentation as you read through the existing documentation.



                            If you read through a page of their documentation, try to boil it down to a bare minimum. What was the takeaway? It's probably a sentence or two, or a snippet of code. Start your own documentation that collects these takeaways.



                            When you have enough of these takeaways, you can start thinking about: How would you organize the documentation differently? What should "hello world" look like? What topic should come right after that?



                            I highly recommend publishing your new and improved documentation somewhere: to a personal blog, as a pull request to the original documentation, or as answers on Stack Overflow. But even if you don't publish them, the process of coming up with them in the first place can be extremely educational.







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Mar 28 at 0:58









                            Kevin WorkmanKevin Workman

                            4,845419




                            4,845419





















                                4












                                $begingroup$

                                I am right there with you; I find it incredibly difficult to work through something substantial and new without disappearing down many little rabbit holes.



                                Here's a simple idea: have you considered just making a list of "questions to answer"? It would be for items that you want to explore in order to flesh out your understanding, but aren't in the main thread of your learning.



                                Items on the list would resolve in one of four ways:



                                1. It graduates to the main thread when you stop understanding what is going on.

                                2. You come to understand it over time without doing an explicit research, just from context and osmosis.

                                3. Through devoted time (perhaps at the end of a session, when your attention is starting to flag anyway), you eventually fill in the hole with some side-research.

                                4. It turns out to be unimportant enough that it never comes up again, and can safely be ignored.

                                The most important things, I think, are not to go down every rabbit hole you see right away, and to reserve some time to go through the list from time to time and fill in some of the missing puzzle pieces.






                                share|improve this answer









                                $endgroup$

















                                  4












                                  $begingroup$

                                  I am right there with you; I find it incredibly difficult to work through something substantial and new without disappearing down many little rabbit holes.



                                  Here's a simple idea: have you considered just making a list of "questions to answer"? It would be for items that you want to explore in order to flesh out your understanding, but aren't in the main thread of your learning.



                                  Items on the list would resolve in one of four ways:



                                  1. It graduates to the main thread when you stop understanding what is going on.

                                  2. You come to understand it over time without doing an explicit research, just from context and osmosis.

                                  3. Through devoted time (perhaps at the end of a session, when your attention is starting to flag anyway), you eventually fill in the hole with some side-research.

                                  4. It turns out to be unimportant enough that it never comes up again, and can safely be ignored.

                                  The most important things, I think, are not to go down every rabbit hole you see right away, and to reserve some time to go through the list from time to time and fill in some of the missing puzzle pieces.






                                  share|improve this answer









                                  $endgroup$















                                    4












                                    4








                                    4





                                    $begingroup$

                                    I am right there with you; I find it incredibly difficult to work through something substantial and new without disappearing down many little rabbit holes.



                                    Here's a simple idea: have you considered just making a list of "questions to answer"? It would be for items that you want to explore in order to flesh out your understanding, but aren't in the main thread of your learning.



                                    Items on the list would resolve in one of four ways:



                                    1. It graduates to the main thread when you stop understanding what is going on.

                                    2. You come to understand it over time without doing an explicit research, just from context and osmosis.

                                    3. Through devoted time (perhaps at the end of a session, when your attention is starting to flag anyway), you eventually fill in the hole with some side-research.

                                    4. It turns out to be unimportant enough that it never comes up again, and can safely be ignored.

                                    The most important things, I think, are not to go down every rabbit hole you see right away, and to reserve some time to go through the list from time to time and fill in some of the missing puzzle pieces.






                                    share|improve this answer









                                    $endgroup$



                                    I am right there with you; I find it incredibly difficult to work through something substantial and new without disappearing down many little rabbit holes.



                                    Here's a simple idea: have you considered just making a list of "questions to answer"? It would be for items that you want to explore in order to flesh out your understanding, but aren't in the main thread of your learning.



                                    Items on the list would resolve in one of four ways:



                                    1. It graduates to the main thread when you stop understanding what is going on.

                                    2. You come to understand it over time without doing an explicit research, just from context and osmosis.

                                    3. Through devoted time (perhaps at the end of a session, when your attention is starting to flag anyway), you eventually fill in the hole with some side-research.

                                    4. It turns out to be unimportant enough that it never comes up again, and can safely be ignored.

                                    The most important things, I think, are not to go down every rabbit hole you see right away, and to reserve some time to go through the list from time to time and fill in some of the missing puzzle pieces.







                                    share|improve this answer












                                    share|improve this answer



                                    share|improve this answer










                                    answered Mar 26 at 19:09









                                    Ben I.Ben I.

                                    18.4k740108




                                    18.4k740108





















                                        3












                                        $begingroup$

                                        Almost all of my advice is from Courseras "Learning how to learn" which I highly recommend.



                                        1. Take breaks.
                                          Study for maybe 20 minutes then take a short break.
                                          Do something physical in these breaks if possible like some squats, push-ups or go for a short walk.


                                        2. Make sure you have plenty of fresh air.
                                          High levels of CO2 and low levels of O2 make us tired.


                                        3. Take notes.
                                          After reading a section write down what you learned.
                                          You might even make these a blog post or do a short talk about it.


                                        4. Do practical things.
                                          This was recommended by others: Instead of just brute force learning, pick a task and learn what you need to learn for that task.
                                          This helps with motivation and also by linking the knowledge to other experiences making it easier to remember.


                                        5. Take notes about what to learn.
                                          You mention getting sidetracked often by looking stuff up that is not directly related to what you are trying to learn right now.
                                          Use your notes to write down what you'd like to look up then look it up when the time is right.


                                        6. Repeat.
                                          We can't internalize complex knowledge directly.
                                          We need to repeat and practice it.
                                          With software APIs, katas are a proven way to do that.
                                          When you learn something new, make a tiny project putting the knowledge to use.
                                          This should take about 30min.
                                          Repeat this project after a short break.
                                          Then again maybe on the next day.
                                          Repetition with increasing time in between makes sure the knowledge ends up in long term memory.






                                        share|improve this answer









                                        $endgroup$

















                                          3












                                          $begingroup$

                                          Almost all of my advice is from Courseras "Learning how to learn" which I highly recommend.



                                          1. Take breaks.
                                            Study for maybe 20 minutes then take a short break.
                                            Do something physical in these breaks if possible like some squats, push-ups or go for a short walk.


                                          2. Make sure you have plenty of fresh air.
                                            High levels of CO2 and low levels of O2 make us tired.


                                          3. Take notes.
                                            After reading a section write down what you learned.
                                            You might even make these a blog post or do a short talk about it.


                                          4. Do practical things.
                                            This was recommended by others: Instead of just brute force learning, pick a task and learn what you need to learn for that task.
                                            This helps with motivation and also by linking the knowledge to other experiences making it easier to remember.


                                          5. Take notes about what to learn.
                                            You mention getting sidetracked often by looking stuff up that is not directly related to what you are trying to learn right now.
                                            Use your notes to write down what you'd like to look up then look it up when the time is right.


                                          6. Repeat.
                                            We can't internalize complex knowledge directly.
                                            We need to repeat and practice it.
                                            With software APIs, katas are a proven way to do that.
                                            When you learn something new, make a tiny project putting the knowledge to use.
                                            This should take about 30min.
                                            Repeat this project after a short break.
                                            Then again maybe on the next day.
                                            Repetition with increasing time in between makes sure the knowledge ends up in long term memory.






                                          share|improve this answer









                                          $endgroup$















                                            3












                                            3








                                            3





                                            $begingroup$

                                            Almost all of my advice is from Courseras "Learning how to learn" which I highly recommend.



                                            1. Take breaks.
                                              Study for maybe 20 minutes then take a short break.
                                              Do something physical in these breaks if possible like some squats, push-ups or go for a short walk.


                                            2. Make sure you have plenty of fresh air.
                                              High levels of CO2 and low levels of O2 make us tired.


                                            3. Take notes.
                                              After reading a section write down what you learned.
                                              You might even make these a blog post or do a short talk about it.


                                            4. Do practical things.
                                              This was recommended by others: Instead of just brute force learning, pick a task and learn what you need to learn for that task.
                                              This helps with motivation and also by linking the knowledge to other experiences making it easier to remember.


                                            5. Take notes about what to learn.
                                              You mention getting sidetracked often by looking stuff up that is not directly related to what you are trying to learn right now.
                                              Use your notes to write down what you'd like to look up then look it up when the time is right.


                                            6. Repeat.
                                              We can't internalize complex knowledge directly.
                                              We need to repeat and practice it.
                                              With software APIs, katas are a proven way to do that.
                                              When you learn something new, make a tiny project putting the knowledge to use.
                                              This should take about 30min.
                                              Repeat this project after a short break.
                                              Then again maybe on the next day.
                                              Repetition with increasing time in between makes sure the knowledge ends up in long term memory.






                                            share|improve this answer









                                            $endgroup$



                                            Almost all of my advice is from Courseras "Learning how to learn" which I highly recommend.



                                            1. Take breaks.
                                              Study for maybe 20 minutes then take a short break.
                                              Do something physical in these breaks if possible like some squats, push-ups or go for a short walk.


                                            2. Make sure you have plenty of fresh air.
                                              High levels of CO2 and low levels of O2 make us tired.


                                            3. Take notes.
                                              After reading a section write down what you learned.
                                              You might even make these a blog post or do a short talk about it.


                                            4. Do practical things.
                                              This was recommended by others: Instead of just brute force learning, pick a task and learn what you need to learn for that task.
                                              This helps with motivation and also by linking the knowledge to other experiences making it easier to remember.


                                            5. Take notes about what to learn.
                                              You mention getting sidetracked often by looking stuff up that is not directly related to what you are trying to learn right now.
                                              Use your notes to write down what you'd like to look up then look it up when the time is right.


                                            6. Repeat.
                                              We can't internalize complex knowledge directly.
                                              We need to repeat and practice it.
                                              With software APIs, katas are a proven way to do that.
                                              When you learn something new, make a tiny project putting the knowledge to use.
                                              This should take about 30min.
                                              Repeat this project after a short break.
                                              Then again maybe on the next day.
                                              Repetition with increasing time in between makes sure the knowledge ends up in long term memory.







                                            share|improve this answer












                                            share|improve this answer



                                            share|improve this answer










                                            answered Mar 27 at 7:45









                                            Jens SchauderJens Schauder

                                            1313




                                            1313





















                                                3












                                                $begingroup$

                                                One very simple technique I have found useful in processing information which I do not understand easily, is to review it multiple times, preferably in different sessions.



                                                You said:




                                                (I can only get through maybe ~10 pages of this reading in a single sitting while maintaining the focus that I feel is necessary.)




                                                and this implies to me that you consider the reading something to do once. I have found that reading the same material again and again (ideally with sleep periods between these sessions, but at least with some rest), allows me to understand things that I cannot understand on the first reading.



                                                I understand that this makes your reading process even longer, but it is one way to get the job done, and at least the enhanced understanding of subsequent reads can provide you with some more motivation to carry you through.



                                                One suggestion here could be to split your time between (a) reading at the "head" of your progress through the documentation, and (b) re-reading parts of the documentation you've already read previously, and then possibly (c) re-reading parts you've already re-read, i.e. re-re-reading.



                                                On second and third readings, you brain will be able to find deeper connections between the seemingly disparate details, and the material will seem less "dry".






                                                share|improve this answer









                                                $endgroup$

















                                                  3












                                                  $begingroup$

                                                  One very simple technique I have found useful in processing information which I do not understand easily, is to review it multiple times, preferably in different sessions.



                                                  You said:




                                                  (I can only get through maybe ~10 pages of this reading in a single sitting while maintaining the focus that I feel is necessary.)




                                                  and this implies to me that you consider the reading something to do once. I have found that reading the same material again and again (ideally with sleep periods between these sessions, but at least with some rest), allows me to understand things that I cannot understand on the first reading.



                                                  I understand that this makes your reading process even longer, but it is one way to get the job done, and at least the enhanced understanding of subsequent reads can provide you with some more motivation to carry you through.



                                                  One suggestion here could be to split your time between (a) reading at the "head" of your progress through the documentation, and (b) re-reading parts of the documentation you've already read previously, and then possibly (c) re-reading parts you've already re-read, i.e. re-re-reading.



                                                  On second and third readings, you brain will be able to find deeper connections between the seemingly disparate details, and the material will seem less "dry".






                                                  share|improve this answer









                                                  $endgroup$















                                                    3












                                                    3








                                                    3





                                                    $begingroup$

                                                    One very simple technique I have found useful in processing information which I do not understand easily, is to review it multiple times, preferably in different sessions.



                                                    You said:




                                                    (I can only get through maybe ~10 pages of this reading in a single sitting while maintaining the focus that I feel is necessary.)




                                                    and this implies to me that you consider the reading something to do once. I have found that reading the same material again and again (ideally with sleep periods between these sessions, but at least with some rest), allows me to understand things that I cannot understand on the first reading.



                                                    I understand that this makes your reading process even longer, but it is one way to get the job done, and at least the enhanced understanding of subsequent reads can provide you with some more motivation to carry you through.



                                                    One suggestion here could be to split your time between (a) reading at the "head" of your progress through the documentation, and (b) re-reading parts of the documentation you've already read previously, and then possibly (c) re-reading parts you've already re-read, i.e. re-re-reading.



                                                    On second and third readings, you brain will be able to find deeper connections between the seemingly disparate details, and the material will seem less "dry".






                                                    share|improve this answer









                                                    $endgroup$



                                                    One very simple technique I have found useful in processing information which I do not understand easily, is to review it multiple times, preferably in different sessions.



                                                    You said:




                                                    (I can only get through maybe ~10 pages of this reading in a single sitting while maintaining the focus that I feel is necessary.)




                                                    and this implies to me that you consider the reading something to do once. I have found that reading the same material again and again (ideally with sleep periods between these sessions, but at least with some rest), allows me to understand things that I cannot understand on the first reading.



                                                    I understand that this makes your reading process even longer, but it is one way to get the job done, and at least the enhanced understanding of subsequent reads can provide you with some more motivation to carry you through.



                                                    One suggestion here could be to split your time between (a) reading at the "head" of your progress through the documentation, and (b) re-reading parts of the documentation you've already read previously, and then possibly (c) re-reading parts you've already re-read, i.e. re-re-reading.



                                                    On second and third readings, you brain will be able to find deeper connections between the seemingly disparate details, and the material will seem less "dry".







                                                    share|improve this answer












                                                    share|improve this answer



                                                    share|improve this answer










                                                    answered Mar 27 at 18:15









                                                    Luke GriffithsLuke Griffiths

                                                    1311




                                                    1311





















                                                        3












                                                        $begingroup$

                                                        I do read one time fully, without worrying about remembering. And then I pick a beginner project and start learning by doing. There is no way to read and remember all those dry details. But you will remember where to look when you get stuck in your projects. I was quite successful with this method, many times.






                                                        share|improve this answer









                                                        $endgroup$








                                                        • 1




                                                          $begingroup$
                                                          Welcome to Computer Science Educators! This answer seems to have good potential. could you perhaps expand it with slightly more concrete examples? Either way, I personally find this to be quite a good answer. I sure hope we'll see more content such as this answer from you again :)
                                                          $endgroup$
                                                          – ItamarG3
                                                          Mar 29 at 10:34











                                                        • $begingroup$
                                                          @ItamarG3 Thank you, flattered :) I think the answer already explains my approach totally I'm not sure how can I expand it. But if you have a question or you think something is unclear, I can gladly include an answer for it. Thanks for your time.
                                                          $endgroup$
                                                          – ferit
                                                          Mar 29 at 17:52















                                                        3












                                                        $begingroup$

                                                        I do read one time fully, without worrying about remembering. And then I pick a beginner project and start learning by doing. There is no way to read and remember all those dry details. But you will remember where to look when you get stuck in your projects. I was quite successful with this method, many times.






                                                        share|improve this answer









                                                        $endgroup$








                                                        • 1




                                                          $begingroup$
                                                          Welcome to Computer Science Educators! This answer seems to have good potential. could you perhaps expand it with slightly more concrete examples? Either way, I personally find this to be quite a good answer. I sure hope we'll see more content such as this answer from you again :)
                                                          $endgroup$
                                                          – ItamarG3
                                                          Mar 29 at 10:34











                                                        • $begingroup$
                                                          @ItamarG3 Thank you, flattered :) I think the answer already explains my approach totally I'm not sure how can I expand it. But if you have a question or you think something is unclear, I can gladly include an answer for it. Thanks for your time.
                                                          $endgroup$
                                                          – ferit
                                                          Mar 29 at 17:52













                                                        3












                                                        3








                                                        3





                                                        $begingroup$

                                                        I do read one time fully, without worrying about remembering. And then I pick a beginner project and start learning by doing. There is no way to read and remember all those dry details. But you will remember where to look when you get stuck in your projects. I was quite successful with this method, many times.






                                                        share|improve this answer









                                                        $endgroup$



                                                        I do read one time fully, without worrying about remembering. And then I pick a beginner project and start learning by doing. There is no way to read and remember all those dry details. But you will remember where to look when you get stuck in your projects. I was quite successful with this method, many times.







                                                        share|improve this answer












                                                        share|improve this answer



                                                        share|improve this answer










                                                        answered Mar 28 at 19:09









                                                        feritferit

                                                        1313




                                                        1313







                                                        • 1




                                                          $begingroup$
                                                          Welcome to Computer Science Educators! This answer seems to have good potential. could you perhaps expand it with slightly more concrete examples? Either way, I personally find this to be quite a good answer. I sure hope we'll see more content such as this answer from you again :)
                                                          $endgroup$
                                                          – ItamarG3
                                                          Mar 29 at 10:34











                                                        • $begingroup$
                                                          @ItamarG3 Thank you, flattered :) I think the answer already explains my approach totally I'm not sure how can I expand it. But if you have a question or you think something is unclear, I can gladly include an answer for it. Thanks for your time.
                                                          $endgroup$
                                                          – ferit
                                                          Mar 29 at 17:52












                                                        • 1




                                                          $begingroup$
                                                          Welcome to Computer Science Educators! This answer seems to have good potential. could you perhaps expand it with slightly more concrete examples? Either way, I personally find this to be quite a good answer. I sure hope we'll see more content such as this answer from you again :)
                                                          $endgroup$
                                                          – ItamarG3
                                                          Mar 29 at 10:34











                                                        • $begingroup$
                                                          @ItamarG3 Thank you, flattered :) I think the answer already explains my approach totally I'm not sure how can I expand it. But if you have a question or you think something is unclear, I can gladly include an answer for it. Thanks for your time.
                                                          $endgroup$
                                                          – ferit
                                                          Mar 29 at 17:52







                                                        1




                                                        1




                                                        $begingroup$
                                                        Welcome to Computer Science Educators! This answer seems to have good potential. could you perhaps expand it with slightly more concrete examples? Either way, I personally find this to be quite a good answer. I sure hope we'll see more content such as this answer from you again :)
                                                        $endgroup$
                                                        – ItamarG3
                                                        Mar 29 at 10:34





                                                        $begingroup$
                                                        Welcome to Computer Science Educators! This answer seems to have good potential. could you perhaps expand it with slightly more concrete examples? Either way, I personally find this to be quite a good answer. I sure hope we'll see more content such as this answer from you again :)
                                                        $endgroup$
                                                        – ItamarG3
                                                        Mar 29 at 10:34













                                                        $begingroup$
                                                        @ItamarG3 Thank you, flattered :) I think the answer already explains my approach totally I'm not sure how can I expand it. But if you have a question or you think something is unclear, I can gladly include an answer for it. Thanks for your time.
                                                        $endgroup$
                                                        – ferit
                                                        Mar 29 at 17:52




                                                        $begingroup$
                                                        @ItamarG3 Thank you, flattered :) I think the answer already explains my approach totally I'm not sure how can I expand it. But if you have a question or you think something is unclear, I can gladly include an answer for it. Thanks for your time.
                                                        $endgroup$
                                                        – ferit
                                                        Mar 29 at 17:52











                                                        3












                                                        $begingroup$


                                                        For example, when I was reading about its mechanism for selecting a
                                                        GPU in a multi-GPU system instead of focusing on the syntax that I
                                                        want to learn, I ended up thinking about all the implications of such
                                                        a selection existing, compared to the fact that it does not in OpenGl.




                                                        Yes humans can not be programmed. This is not a good way to learn. You are being distracted, because what you are reading is not useful. Syntax is not the important bit.



                                                        As an experienced programmer, I just look it up as I go. I need to find something that gives me a good overview of what it does (not how), what the philosophy of it is. Then I just get on with it (very slowly at first), and look stuff up just-in-time. Sometimes I look stuff up more than once.






                                                        share|improve this answer









                                                        $endgroup$

















                                                          3












                                                          $begingroup$


                                                          For example, when I was reading about its mechanism for selecting a
                                                          GPU in a multi-GPU system instead of focusing on the syntax that I
                                                          want to learn, I ended up thinking about all the implications of such
                                                          a selection existing, compared to the fact that it does not in OpenGl.




                                                          Yes humans can not be programmed. This is not a good way to learn. You are being distracted, because what you are reading is not useful. Syntax is not the important bit.



                                                          As an experienced programmer, I just look it up as I go. I need to find something that gives me a good overview of what it does (not how), what the philosophy of it is. Then I just get on with it (very slowly at first), and look stuff up just-in-time. Sometimes I look stuff up more than once.






                                                          share|improve this answer









                                                          $endgroup$















                                                            3












                                                            3








                                                            3





                                                            $begingroup$


                                                            For example, when I was reading about its mechanism for selecting a
                                                            GPU in a multi-GPU system instead of focusing on the syntax that I
                                                            want to learn, I ended up thinking about all the implications of such
                                                            a selection existing, compared to the fact that it does not in OpenGl.




                                                            Yes humans can not be programmed. This is not a good way to learn. You are being distracted, because what you are reading is not useful. Syntax is not the important bit.



                                                            As an experienced programmer, I just look it up as I go. I need to find something that gives me a good overview of what it does (not how), what the philosophy of it is. Then I just get on with it (very slowly at first), and look stuff up just-in-time. Sometimes I look stuff up more than once.






                                                            share|improve this answer









                                                            $endgroup$




                                                            For example, when I was reading about its mechanism for selecting a
                                                            GPU in a multi-GPU system instead of focusing on the syntax that I
                                                            want to learn, I ended up thinking about all the implications of such
                                                            a selection existing, compared to the fact that it does not in OpenGl.




                                                            Yes humans can not be programmed. This is not a good way to learn. You are being distracted, because what you are reading is not useful. Syntax is not the important bit.



                                                            As an experienced programmer, I just look it up as I go. I need to find something that gives me a good overview of what it does (not how), what the philosophy of it is. Then I just get on with it (very slowly at first), and look stuff up just-in-time. Sometimes I look stuff up more than once.







                                                            share|improve this answer












                                                            share|improve this answer



                                                            share|improve this answer










                                                            answered Mar 28 at 19:55









                                                            ctrl-alt-delorctrl-alt-delor

                                                            7,66131548




                                                            7,66131548





















                                                                2












                                                                $begingroup$

                                                                Suggestions:



                                                                • Do not just read the API, but focus on actually doing what you want to do. I don't know Vulcan, but many other APIs, language specifications, protocol specifications etc. You can skim them quickly to see what the API has to offer (the general topics, architectural overview etc.). But then try to use the API. At first, you will immediately hit your first roadblocks. Then go and try to overcome each individual block, by delving into the dry documentation. Your carrot is the small goal you are currently trying to achieve. This is a good point for StackOverflow as well... if you have very concrete problems, you can just ask.

                                                                • Avoid tutorials. Exceptions notwithstanding, they are the devil for building deep know-how, in my experience and strong opinion. They are often outdated; they represent the usual limited understanding of the author. They are specialized to whatever the author needed at the moment, and his opinions about how APIs should be used. About the only good case for tutorials is for a short "hello world"-style piece which gets you running from a blank slate (i.e., gives you the bare minimum commands to compile your first program or whatever you're doing). But as soon as you have even the slightest working bit of program, get rid of them ASAP.

                                                                • Do not feel that you are somehow inferiour or whatever. In my long experience, most people do not want to, or actually cannot read specifications/reference documentation. You are in good company. But don't give up...

                                                                Good luck.






                                                                share|improve this answer











                                                                $endgroup$








                                                                • 1




                                                                  $begingroup$
                                                                  The comment about tutorials is valid for many hastily-put-together articles found on the web, often written by someone who is no expert and wants to share what he/she has just learned. But there are also tutorials that are very carefully designed, crafted, and reviewed by experts. You need to be able to recognise the difference.
                                                                  $endgroup$
                                                                  – Michael Kay
                                                                  Mar 27 at 10:21






                                                                • 1




                                                                  $begingroup$
                                                                  @MichaelKay, I've added an "exceptions notwithstanding". As a counterexample to your counterexample I'll mention a once de-facto Ruby-on-Rails tutorial, which was in fact a very long and extremely well written e-book/website. Both didactically great; written in clean and well understandable tone. Exactly what you propose. The problem? It is for Rails 3. Rails 4+ are radically different. Most of the info in that tutorial is not only replaced by more modern stuff, but doesn't work anymore, outright. The problem? As it's so good, it still often turns up quite high in searches, and it is really...
                                                                  $endgroup$
                                                                  – AnoE
                                                                  Mar 27 at 12:17











                                                                • $begingroup$
                                                                  ... tempting and easy to fall into the trap of using/studying it; eventually getting ever more and more confused due to the fact that things mysteriously fail to work over time. But really worst of all; even the parts that still work follow an outdated mode of operation for several parts of that ecosystem. All in all, a developer following that as his main source at the beginning sets out with a (in part radically) wrong understanding, laying plenty of obstacles in the way.
                                                                  $endgroup$
                                                                  – AnoE
                                                                  Mar 27 at 12:18










                                                                • $begingroup$
                                                                  Yes, out-of-date information is always a problem on the web.
                                                                  $endgroup$
                                                                  – Michael Kay
                                                                  Mar 27 at 12:53















                                                                2












                                                                $begingroup$

                                                                Suggestions:



                                                                • Do not just read the API, but focus on actually doing what you want to do. I don't know Vulcan, but many other APIs, language specifications, protocol specifications etc. You can skim them quickly to see what the API has to offer (the general topics, architectural overview etc.). But then try to use the API. At first, you will immediately hit your first roadblocks. Then go and try to overcome each individual block, by delving into the dry documentation. Your carrot is the small goal you are currently trying to achieve. This is a good point for StackOverflow as well... if you have very concrete problems, you can just ask.

                                                                • Avoid tutorials. Exceptions notwithstanding, they are the devil for building deep know-how, in my experience and strong opinion. They are often outdated; they represent the usual limited understanding of the author. They are specialized to whatever the author needed at the moment, and his opinions about how APIs should be used. About the only good case for tutorials is for a short "hello world"-style piece which gets you running from a blank slate (i.e., gives you the bare minimum commands to compile your first program or whatever you're doing). But as soon as you have even the slightest working bit of program, get rid of them ASAP.

                                                                • Do not feel that you are somehow inferiour or whatever. In my long experience, most people do not want to, or actually cannot read specifications/reference documentation. You are in good company. But don't give up...

                                                                Good luck.






                                                                share|improve this answer











                                                                $endgroup$








                                                                • 1




                                                                  $begingroup$
                                                                  The comment about tutorials is valid for many hastily-put-together articles found on the web, often written by someone who is no expert and wants to share what he/she has just learned. But there are also tutorials that are very carefully designed, crafted, and reviewed by experts. You need to be able to recognise the difference.
                                                                  $endgroup$
                                                                  – Michael Kay
                                                                  Mar 27 at 10:21






                                                                • 1




                                                                  $begingroup$
                                                                  @MichaelKay, I've added an "exceptions notwithstanding". As a counterexample to your counterexample I'll mention a once de-facto Ruby-on-Rails tutorial, which was in fact a very long and extremely well written e-book/website. Both didactically great; written in clean and well understandable tone. Exactly what you propose. The problem? It is for Rails 3. Rails 4+ are radically different. Most of the info in that tutorial is not only replaced by more modern stuff, but doesn't work anymore, outright. The problem? As it's so good, it still often turns up quite high in searches, and it is really...
                                                                  $endgroup$
                                                                  – AnoE
                                                                  Mar 27 at 12:17











                                                                • $begingroup$
                                                                  ... tempting and easy to fall into the trap of using/studying it; eventually getting ever more and more confused due to the fact that things mysteriously fail to work over time. But really worst of all; even the parts that still work follow an outdated mode of operation for several parts of that ecosystem. All in all, a developer following that as his main source at the beginning sets out with a (in part radically) wrong understanding, laying plenty of obstacles in the way.
                                                                  $endgroup$
                                                                  – AnoE
                                                                  Mar 27 at 12:18










                                                                • $begingroup$
                                                                  Yes, out-of-date information is always a problem on the web.
                                                                  $endgroup$
                                                                  – Michael Kay
                                                                  Mar 27 at 12:53













                                                                2












                                                                2








                                                                2





                                                                $begingroup$

                                                                Suggestions:



                                                                • Do not just read the API, but focus on actually doing what you want to do. I don't know Vulcan, but many other APIs, language specifications, protocol specifications etc. You can skim them quickly to see what the API has to offer (the general topics, architectural overview etc.). But then try to use the API. At first, you will immediately hit your first roadblocks. Then go and try to overcome each individual block, by delving into the dry documentation. Your carrot is the small goal you are currently trying to achieve. This is a good point for StackOverflow as well... if you have very concrete problems, you can just ask.

                                                                • Avoid tutorials. Exceptions notwithstanding, they are the devil for building deep know-how, in my experience and strong opinion. They are often outdated; they represent the usual limited understanding of the author. They are specialized to whatever the author needed at the moment, and his opinions about how APIs should be used. About the only good case for tutorials is for a short "hello world"-style piece which gets you running from a blank slate (i.e., gives you the bare minimum commands to compile your first program or whatever you're doing). But as soon as you have even the slightest working bit of program, get rid of them ASAP.

                                                                • Do not feel that you are somehow inferiour or whatever. In my long experience, most people do not want to, or actually cannot read specifications/reference documentation. You are in good company. But don't give up...

                                                                Good luck.






                                                                share|improve this answer











                                                                $endgroup$



                                                                Suggestions:



                                                                • Do not just read the API, but focus on actually doing what you want to do. I don't know Vulcan, but many other APIs, language specifications, protocol specifications etc. You can skim them quickly to see what the API has to offer (the general topics, architectural overview etc.). But then try to use the API. At first, you will immediately hit your first roadblocks. Then go and try to overcome each individual block, by delving into the dry documentation. Your carrot is the small goal you are currently trying to achieve. This is a good point for StackOverflow as well... if you have very concrete problems, you can just ask.

                                                                • Avoid tutorials. Exceptions notwithstanding, they are the devil for building deep know-how, in my experience and strong opinion. They are often outdated; they represent the usual limited understanding of the author. They are specialized to whatever the author needed at the moment, and his opinions about how APIs should be used. About the only good case for tutorials is for a short "hello world"-style piece which gets you running from a blank slate (i.e., gives you the bare minimum commands to compile your first program or whatever you're doing). But as soon as you have even the slightest working bit of program, get rid of them ASAP.

                                                                • Do not feel that you are somehow inferiour or whatever. In my long experience, most people do not want to, or actually cannot read specifications/reference documentation. You are in good company. But don't give up...

                                                                Good luck.







                                                                share|improve this answer














                                                                share|improve this answer



                                                                share|improve this answer








                                                                edited Mar 27 at 12:14

























                                                                answered Mar 27 at 10:00









                                                                AnoEAnoE

                                                                1,13938




                                                                1,13938







                                                                • 1




                                                                  $begingroup$
                                                                  The comment about tutorials is valid for many hastily-put-together articles found on the web, often written by someone who is no expert and wants to share what he/she has just learned. But there are also tutorials that are very carefully designed, crafted, and reviewed by experts. You need to be able to recognise the difference.
                                                                  $endgroup$
                                                                  – Michael Kay
                                                                  Mar 27 at 10:21






                                                                • 1




                                                                  $begingroup$
                                                                  @MichaelKay, I've added an "exceptions notwithstanding". As a counterexample to your counterexample I'll mention a once de-facto Ruby-on-Rails tutorial, which was in fact a very long and extremely well written e-book/website. Both didactically great; written in clean and well understandable tone. Exactly what you propose. The problem? It is for Rails 3. Rails 4+ are radically different. Most of the info in that tutorial is not only replaced by more modern stuff, but doesn't work anymore, outright. The problem? As it's so good, it still often turns up quite high in searches, and it is really...
                                                                  $endgroup$
                                                                  – AnoE
                                                                  Mar 27 at 12:17











                                                                • $begingroup$
                                                                  ... tempting and easy to fall into the trap of using/studying it; eventually getting ever more and more confused due to the fact that things mysteriously fail to work over time. But really worst of all; even the parts that still work follow an outdated mode of operation for several parts of that ecosystem. All in all, a developer following that as his main source at the beginning sets out with a (in part radically) wrong understanding, laying plenty of obstacles in the way.
                                                                  $endgroup$
                                                                  – AnoE
                                                                  Mar 27 at 12:18










                                                                • $begingroup$
                                                                  Yes, out-of-date information is always a problem on the web.
                                                                  $endgroup$
                                                                  – Michael Kay
                                                                  Mar 27 at 12:53












                                                                • 1




                                                                  $begingroup$
                                                                  The comment about tutorials is valid for many hastily-put-together articles found on the web, often written by someone who is no expert and wants to share what he/she has just learned. But there are also tutorials that are very carefully designed, crafted, and reviewed by experts. You need to be able to recognise the difference.
                                                                  $endgroup$
                                                                  – Michael Kay
                                                                  Mar 27 at 10:21






                                                                • 1




                                                                  $begingroup$
                                                                  @MichaelKay, I've added an "exceptions notwithstanding". As a counterexample to your counterexample I'll mention a once de-facto Ruby-on-Rails tutorial, which was in fact a very long and extremely well written e-book/website. Both didactically great; written in clean and well understandable tone. Exactly what you propose. The problem? It is for Rails 3. Rails 4+ are radically different. Most of the info in that tutorial is not only replaced by more modern stuff, but doesn't work anymore, outright. The problem? As it's so good, it still often turns up quite high in searches, and it is really...
                                                                  $endgroup$
                                                                  – AnoE
                                                                  Mar 27 at 12:17











                                                                • $begingroup$
                                                                  ... tempting and easy to fall into the trap of using/studying it; eventually getting ever more and more confused due to the fact that things mysteriously fail to work over time. But really worst of all; even the parts that still work follow an outdated mode of operation for several parts of that ecosystem. All in all, a developer following that as his main source at the beginning sets out with a (in part radically) wrong understanding, laying plenty of obstacles in the way.
                                                                  $endgroup$
                                                                  – AnoE
                                                                  Mar 27 at 12:18










                                                                • $begingroup$
                                                                  Yes, out-of-date information is always a problem on the web.
                                                                  $endgroup$
                                                                  – Michael Kay
                                                                  Mar 27 at 12:53







                                                                1




                                                                1




                                                                $begingroup$
                                                                The comment about tutorials is valid for many hastily-put-together articles found on the web, often written by someone who is no expert and wants to share what he/she has just learned. But there are also tutorials that are very carefully designed, crafted, and reviewed by experts. You need to be able to recognise the difference.
                                                                $endgroup$
                                                                – Michael Kay
                                                                Mar 27 at 10:21




                                                                $begingroup$
                                                                The comment about tutorials is valid for many hastily-put-together articles found on the web, often written by someone who is no expert and wants to share what he/she has just learned. But there are also tutorials that are very carefully designed, crafted, and reviewed by experts. You need to be able to recognise the difference.
                                                                $endgroup$
                                                                – Michael Kay
                                                                Mar 27 at 10:21




                                                                1




                                                                1




                                                                $begingroup$
                                                                @MichaelKay, I've added an "exceptions notwithstanding". As a counterexample to your counterexample I'll mention a once de-facto Ruby-on-Rails tutorial, which was in fact a very long and extremely well written e-book/website. Both didactically great; written in clean and well understandable tone. Exactly what you propose. The problem? It is for Rails 3. Rails 4+ are radically different. Most of the info in that tutorial is not only replaced by more modern stuff, but doesn't work anymore, outright. The problem? As it's so good, it still often turns up quite high in searches, and it is really...
                                                                $endgroup$
                                                                – AnoE
                                                                Mar 27 at 12:17





                                                                $begingroup$
                                                                @MichaelKay, I've added an "exceptions notwithstanding". As a counterexample to your counterexample I'll mention a once de-facto Ruby-on-Rails tutorial, which was in fact a very long and extremely well written e-book/website. Both didactically great; written in clean and well understandable tone. Exactly what you propose. The problem? It is for Rails 3. Rails 4+ are radically different. Most of the info in that tutorial is not only replaced by more modern stuff, but doesn't work anymore, outright. The problem? As it's so good, it still often turns up quite high in searches, and it is really...
                                                                $endgroup$
                                                                – AnoE
                                                                Mar 27 at 12:17













                                                                $begingroup$
                                                                ... tempting and easy to fall into the trap of using/studying it; eventually getting ever more and more confused due to the fact that things mysteriously fail to work over time. But really worst of all; even the parts that still work follow an outdated mode of operation for several parts of that ecosystem. All in all, a developer following that as his main source at the beginning sets out with a (in part radically) wrong understanding, laying plenty of obstacles in the way.
                                                                $endgroup$
                                                                – AnoE
                                                                Mar 27 at 12:18




                                                                $begingroup$
                                                                ... tempting and easy to fall into the trap of using/studying it; eventually getting ever more and more confused due to the fact that things mysteriously fail to work over time. But really worst of all; even the parts that still work follow an outdated mode of operation for several parts of that ecosystem. All in all, a developer following that as his main source at the beginning sets out with a (in part radically) wrong understanding, laying plenty of obstacles in the way.
                                                                $endgroup$
                                                                – AnoE
                                                                Mar 27 at 12:18












                                                                $begingroup$
                                                                Yes, out-of-date information is always a problem on the web.
                                                                $endgroup$
                                                                – Michael Kay
                                                                Mar 27 at 12:53




                                                                $begingroup$
                                                                Yes, out-of-date information is always a problem on the web.
                                                                $endgroup$
                                                                – Michael Kay
                                                                Mar 27 at 12:53











                                                                1












                                                                $begingroup$

                                                                You're not alone.



                                                                Try to focus on "what do I need to know now?". On first reading, you need to understand the basic concepts. Try to find the sections of the document that explain them. (Many technical documents are bad at explaining them, or don't put the explanations in the obvious place.) If you find some text that you don't understand because you don't know what the words mean, stop reading (there's absolutely no point carrying on) and try and find where in the document the words are explained.



                                                                If you find a section that's all about edge cases (how does the system handle division by zero), recognise that and skip it. You don't need to know that right now.



                                                                On your first reading, try not just to absorb the content, but also to form an assessment of what kind of document you are reading. What kind of reader is it aimed at, and is that you? Which is going to be more useful, the examples, or the formal narrative? How careful is the writer about explaining things? Does it use terminology consistently and accurately? Understanding how the writer's mind is working can help your reading: if you come across a word like "specify" or "denote", are they using it carefully or carelessly?



                                                                Think carefully about how to balance reading with hands-on experimentation. Some people start the hands-on too early, before they understand the concepts; that can lead to you drawing false conclusions about the system's behaviour, and to frustration that you can't make anything work. But if the documentation has "Hello world" examples to take you through things gently, then try them out. Not only will it give you confidence that you're following the text and making progress, it will keep you fresh and stop you falling asleep.






                                                                share|improve this answer









                                                                $endgroup$

















                                                                  1












                                                                  $begingroup$

                                                                  You're not alone.



                                                                  Try to focus on "what do I need to know now?". On first reading, you need to understand the basic concepts. Try to find the sections of the document that explain them. (Many technical documents are bad at explaining them, or don't put the explanations in the obvious place.) If you find some text that you don't understand because you don't know what the words mean, stop reading (there's absolutely no point carrying on) and try and find where in the document the words are explained.



                                                                  If you find a section that's all about edge cases (how does the system handle division by zero), recognise that and skip it. You don't need to know that right now.



                                                                  On your first reading, try not just to absorb the content, but also to form an assessment of what kind of document you are reading. What kind of reader is it aimed at, and is that you? Which is going to be more useful, the examples, or the formal narrative? How careful is the writer about explaining things? Does it use terminology consistently and accurately? Understanding how the writer's mind is working can help your reading: if you come across a word like "specify" or "denote", are they using it carefully or carelessly?



                                                                  Think carefully about how to balance reading with hands-on experimentation. Some people start the hands-on too early, before they understand the concepts; that can lead to you drawing false conclusions about the system's behaviour, and to frustration that you can't make anything work. But if the documentation has "Hello world" examples to take you through things gently, then try them out. Not only will it give you confidence that you're following the text and making progress, it will keep you fresh and stop you falling asleep.






                                                                  share|improve this answer









                                                                  $endgroup$















                                                                    1












                                                                    1








                                                                    1





                                                                    $begingroup$

                                                                    You're not alone.



                                                                    Try to focus on "what do I need to know now?". On first reading, you need to understand the basic concepts. Try to find the sections of the document that explain them. (Many technical documents are bad at explaining them, or don't put the explanations in the obvious place.) If you find some text that you don't understand because you don't know what the words mean, stop reading (there's absolutely no point carrying on) and try and find where in the document the words are explained.



                                                                    If you find a section that's all about edge cases (how does the system handle division by zero), recognise that and skip it. You don't need to know that right now.



                                                                    On your first reading, try not just to absorb the content, but also to form an assessment of what kind of document you are reading. What kind of reader is it aimed at, and is that you? Which is going to be more useful, the examples, or the formal narrative? How careful is the writer about explaining things? Does it use terminology consistently and accurately? Understanding how the writer's mind is working can help your reading: if you come across a word like "specify" or "denote", are they using it carefully or carelessly?



                                                                    Think carefully about how to balance reading with hands-on experimentation. Some people start the hands-on too early, before they understand the concepts; that can lead to you drawing false conclusions about the system's behaviour, and to frustration that you can't make anything work. But if the documentation has "Hello world" examples to take you through things gently, then try them out. Not only will it give you confidence that you're following the text and making progress, it will keep you fresh and stop you falling asleep.






                                                                    share|improve this answer









                                                                    $endgroup$



                                                                    You're not alone.



                                                                    Try to focus on "what do I need to know now?". On first reading, you need to understand the basic concepts. Try to find the sections of the document that explain them. (Many technical documents are bad at explaining them, or don't put the explanations in the obvious place.) If you find some text that you don't understand because you don't know what the words mean, stop reading (there's absolutely no point carrying on) and try and find where in the document the words are explained.



                                                                    If you find a section that's all about edge cases (how does the system handle division by zero), recognise that and skip it. You don't need to know that right now.



                                                                    On your first reading, try not just to absorb the content, but also to form an assessment of what kind of document you are reading. What kind of reader is it aimed at, and is that you? Which is going to be more useful, the examples, or the formal narrative? How careful is the writer about explaining things? Does it use terminology consistently and accurately? Understanding how the writer's mind is working can help your reading: if you come across a word like "specify" or "denote", are they using it carefully or carelessly?



                                                                    Think carefully about how to balance reading with hands-on experimentation. Some people start the hands-on too early, before they understand the concepts; that can lead to you drawing false conclusions about the system's behaviour, and to frustration that you can't make anything work. But if the documentation has "Hello world" examples to take you through things gently, then try them out. Not only will it give you confidence that you're following the text and making progress, it will keep you fresh and stop you falling asleep.







                                                                    share|improve this answer












                                                                    share|improve this answer



                                                                    share|improve this answer










                                                                    answered Mar 27 at 10:16









                                                                    Michael KayMichael Kay

                                                                    33614




                                                                    33614



























                                                                        draft saved

                                                                        draft discarded
















































                                                                        Thanks for contributing an answer to Computer Science Educators Stack Exchange!


                                                                        • Please be sure to answer the question. Provide details and share your research!

                                                                        But avoid


                                                                        • Asking for help, clarification, or responding to other answers.

                                                                        • Making statements based on opinion; back them up with references or personal experience.

                                                                        Use MathJax to format equations. MathJax reference.


                                                                        To learn more, see our tips on writing great answers.




                                                                        draft saved


                                                                        draft discarded














                                                                        StackExchange.ready(
                                                                        function ()
                                                                        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcseducators.stackexchange.com%2fquestions%2f5492%2fhow-can-i-get-through-very-long-and-very-dry-but-also-very-useful-technical-doc%23new-answer', 'question_page');

                                                                        );

                                                                        Post as a guest















                                                                        Required, but never shown





















































                                                                        Required, but never shown














                                                                        Required, but never shown












                                                                        Required, but never shown







                                                                        Required, but never shown

































                                                                        Required, but never shown














                                                                        Required, but never shown












                                                                        Required, but never shown







                                                                        Required, but never shown







                                                                        Popular posts from this blog

                                                                        Færeyskur hestur Heimild | Tengill | Tilvísanir | LeiðsagnarvalRossið - síða um færeyska hrossið á færeyskuGott ár hjá færeyska hestinum

                                                                        He _____ here since 1970 . Answer needed [closed]What does “since he was so high” mean?Meaning of “catch birds for”?How do I ensure “since” takes the meaning I want?“Who cares here” meaningWhat does “right round toward” mean?the time tense (had now been detected)What does the phrase “ring around the roses” mean here?Correct usage of “visited upon”Meaning of “foiled rail sabotage bid”It was the third time I had gone to Rome or It is the third time I had been to Rome

                                                                        Slayer Innehåll Historia | Stil, komposition och lyrik | Bandets betydelse och framgångar | Sidoprojekt och samarbeten | Kontroverser | Medlemmar | Utmärkelser och nomineringar | Turnéer och festivaler | Diskografi | Referenser | Externa länkar | Navigeringsmenywww.slayer.net”Metal Massacre vol. 1””Metal Massacre vol. 3””Metal Massacre Volume III””Show No Mercy””Haunting the Chapel””Live Undead””Hell Awaits””Reign in Blood””Reign in Blood””Gold & Platinum – Reign in Blood””Golden Gods Awards Winners”originalet”Kerrang! Hall Of Fame””Slayer Looks Back On 37-Year Career In New Video Series: Part Two””South of Heaven””Gold & Platinum – South of Heaven””Seasons in the Abyss””Gold & Platinum - Seasons in the Abyss””Divine Intervention””Divine Intervention - Release group by Slayer””Gold & Platinum - Divine Intervention””Live Intrusion””Undisputed Attitude””Abolish Government/Superficial Love””Release “Slatanic Slaughter: A Tribute to Slayer” by Various Artists””Diabolus in Musica””Soundtrack to the Apocalypse””God Hates Us All””Systematic - Relationships””War at the Warfield””Gold & Platinum - War at the Warfield””Soundtrack to the Apocalypse””Gold & Platinum - Still Reigning””Metallica, Slayer, Iron Mauden Among Winners At Metal Hammer Awards””Eternal Pyre””Eternal Pyre - Slayer release group””Eternal Pyre””Metal Storm Awards 2006””Kerrang! Hall Of Fame””Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Bullet-For My Valentine booed at Metal Hammer Golden Gods Awards””Unholy Aliance””The End Of Slayer?””Slayer: We Could Thrash Out Two More Albums If We're Fast Enough...””'The Unholy Alliance: Chapter III' UK Dates Added”originalet”Megadeth And Slayer To Co-Headline 'Canadian Carnage' Trek”originalet”World Painted Blood””Release “World Painted Blood” by Slayer””Metallica Heading To Cinemas””Slayer, Megadeth To Join Forces For 'European Carnage' Tour - Dec. 18, 2010”originalet”Slayer's Hanneman Contracts Acute Infection; Band To Bring In Guest Guitarist””Cannibal Corpse's Pat O'Brien Will Step In As Slayer's Guest Guitarist”originalet”Slayer’s Jeff Hanneman Dead at 49””Dave Lombardo Says He Made Only $67,000 In 2011 While Touring With Slayer””Slayer: We Do Not Agree With Dave Lombardo's Substance Or Timeline Of Events””Slayer Welcomes Drummer Paul Bostaph Back To The Fold””Slayer Hope to Unveil Never-Before-Heard Jeff Hanneman Material on Next Album””Slayer Debut New Song 'Implode' During Surprise Golden Gods Appearance””Release group Repentless by Slayer””Repentless - Slayer - Credits””Slayer””Metal Storm Awards 2015””Slayer - to release comic book "Repentless #1"””Slayer To Release 'Repentless' 6.66" Vinyl Box Set””BREAKING NEWS: Slayer Announce Farewell Tour””Slayer Recruit Lamb of God, Anthrax, Behemoth + Testament for Final Tour””Slayer lägger ner efter 37 år””Slayer Announces Second North American Leg Of 'Final' Tour””Final World Tour””Slayer Announces Final European Tour With Lamb of God, Anthrax And Obituary””Slayer To Tour Europe With Lamb of God, Anthrax And Obituary””Slayer To Play 'Last French Show Ever' At Next Year's Hellfst””Slayer's Final World Tour Will Extend Into 2019””Death Angel's Rob Cavestany On Slayer's 'Farewell' Tour: 'Some Of Us Could See This Coming'””Testament Has No Plans To Retire Anytime Soon, Says Chuck Billy””Anthrax's Scott Ian On Slayer's 'Farewell' Tour Plans: 'I Was Surprised And I Wasn't Surprised'””Slayer””Slayer's Morbid Schlock””Review/Rock; For Slayer, the Mania Is the Message””Slayer - Biography””Slayer - Reign In Blood”originalet”Dave Lombardo””An exclusive oral history of Slayer”originalet”Exclusive! Interview With Slayer Guitarist Jeff Hanneman”originalet”Thinking Out Loud: Slayer's Kerry King on hair metal, Satan and being polite””Slayer Lyrics””Slayer - Biography””Most influential artists for extreme metal music””Slayer - Reign in Blood””Slayer guitarist Jeff Hanneman dies aged 49””Slatanic Slaughter: A Tribute to Slayer””Gateway to Hell: A Tribute to Slayer””Covered In Blood””Slayer: The Origins of Thrash in San Francisco, CA.””Why They Rule - #6 Slayer”originalet”Guitar World's 100 Greatest Heavy Metal Guitarists Of All Time”originalet”The fans have spoken: Slayer comes out on top in readers' polls”originalet”Tribute to Jeff Hanneman (1964-2013)””Lamb Of God Frontman: We Sound Like A Slayer Rip-Off””BEHEMOTH Frontman Pays Tribute To SLAYER's JEFF HANNEMAN””Slayer, Hatebreed Doing Double Duty On This Year's Ozzfest””System of a Down””Lacuna Coil’s Andrea Ferro Talks Influences, Skateboarding, Band Origins + More””Slayer - Reign in Blood””Into The Lungs of Hell””Slayer rules - en utställning om fans””Slayer and Their Fans Slashed Through a No-Holds-Barred Night at Gas Monkey””Home””Slayer””Gold & Platinum - The Big 4 Live from Sofia, Bulgaria””Exclusive! Interview With Slayer Guitarist Kerry King””2008-02-23: Wiltern, Los Angeles, CA, USA””Slayer's Kerry King To Perform With Megadeth Tonight! - Oct. 21, 2010”originalet”Dave Lombardo - Biography”Slayer Case DismissedArkiveradUltimate Classic Rock: Slayer guitarist Jeff Hanneman dead at 49.”Slayer: "We could never do any thing like Some Kind Of Monster..."””Cannibal Corpse'S Pat O'Brien Will Step In As Slayer'S Guest Guitarist | The Official Slayer Site”originalet”Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Kerrang! Awards 2006 Blog: Kerrang! Hall Of Fame””Kerrang! Awards 2013: Kerrang! Legend”originalet”Metallica, Slayer, Iron Maien Among Winners At Metal Hammer Awards””Metal Hammer Golden Gods Awards””Bullet For My Valentine Booed At Metal Hammer Golden Gods Awards””Metal Storm Awards 2006””Metal Storm Awards 2015””Slayer's Concert History””Slayer - Relationships””Slayer - Releases”Slayers officiella webbplatsSlayer på MusicBrainzOfficiell webbplatsSlayerSlayerr1373445760000 0001 1540 47353068615-5086262726cb13906545x(data)6033143kn20030215029