How can I get through very long and very dry, but also very useful technical documents when learning a new tool?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?
Blender 2.8 I can't see vertices, edges or faces in edit mode
Alternative to sending password over mail?
What is the formal way to express the meaning of a variable?
Assassin's bullet with mercury
Expand and Contract
Why "Having chlorophyll without photosynthesis is actually very dangerous" and "like living with a bomb"?
What mechanic is there to disable a threat instead of killing it?
I'm going to France and my passport expires June 19th
How much of data wrangling is a data scientist's job?
Ambiguity in the definition of entropy
What about the virus in 12 Monkeys?
CAST throwing error when run in stored procedure but not when run as raw query
Is it possible to create a QR code using text?
A category-like structure without composition?
Why is the ratio of two extensive quantities always intensive?
A reference to a well-known characterization of scattered compact spaces
table going outside the page
Forgetting the musical notes while performing in concert
How to blend text to background so it looks burned in paint.net?
Do scales need to be in alphabetical order?
Twin primes whose sum is a cube
What is the word for reserving something for yourself before others do?
Is it possible to download Internet Explorer on my Mac running OS X El Capitan?
What exploit are these user agents trying to use?
How can I get through very long and very dry, but also very useful technical documents when learning a new tool?
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?
$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?
self-learning
$endgroup$
add a comment |
$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?
self-learning
$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
add a comment |
$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?
self-learning
$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
self-learning
edited Mar 26 at 22:00
Ben I.♦
18.2k740108
18.2k740108
asked Mar 26 at 19:01
john01davjohn01dav
21316
21316
$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
add a comment |
$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
add a comment |
11 Answers
11
active
oldest
votes
$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.
$endgroup$
add a comment |
$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).
$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
|
show 2 more comments
$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!
$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
add a comment |
$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.
$endgroup$
add a comment |
$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:
- It graduates to the main thread when you stop understanding what is going on.
- You come to understand it over time without doing an explicit research, just from context and osmosis.
- 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.
- 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.
$endgroup$
add a comment |
$begingroup$
Almost all of my advice is from Courseras "Learning how to learn" which I highly recommend.
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.Make sure you have plenty of fresh air.
High levels of CO2 and low levels of O2 make us tired.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.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.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.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.
$endgroup$
add a comment |
$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".
$endgroup$
add a comment |
$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.
New contributor
$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
add a comment |
$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.
$endgroup$
add a comment |
$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.
$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
add a comment |
$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.
$endgroup$
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
return StackExchange.using("mathjaxEditing", function ()
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
);
);
, "mathjax-editing");
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
$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.
$endgroup$
add a comment |
$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.
$endgroup$
add a comment |
$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.
$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.
answered Mar 27 at 19:16
Nicol BolasNicol Bolas
1863
1863
add a comment |
add a comment |
$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).
$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
|
show 2 more comments
$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).
$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
|
show 2 more comments
$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).
$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).
answered Mar 27 at 0:51
heatherheather
3,943835
3,943835
$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
|
show 2 more comments
$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
|
show 2 more comments
$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!
$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
add a comment |
$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!
$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
add a comment |
$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!
$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!
answered Mar 26 at 20:41
thesecretmaster♦thesecretmaster
3,24931043
3,24931043
$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
add a comment |
$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
add a comment |
$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.
$endgroup$
add a comment |
$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.
$endgroup$
add a comment |
$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.
$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.
answered Mar 28 at 0:58
Kevin WorkmanKevin Workman
4,825418
4,825418
add a comment |
add a comment |
$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:
- It graduates to the main thread when you stop understanding what is going on.
- You come to understand it over time without doing an explicit research, just from context and osmosis.
- 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.
- 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.
$endgroup$
add a comment |
$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:
- It graduates to the main thread when you stop understanding what is going on.
- You come to understand it over time without doing an explicit research, just from context and osmosis.
- 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.
- 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.
$endgroup$
add a comment |
$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:
- It graduates to the main thread when you stop understanding what is going on.
- You come to understand it over time without doing an explicit research, just from context and osmosis.
- 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.
- 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.
$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:
- It graduates to the main thread when you stop understanding what is going on.
- You come to understand it over time without doing an explicit research, just from context and osmosis.
- 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.
- 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.
answered Mar 26 at 19:09
Ben I.♦Ben I.
18.2k740108
18.2k740108
add a comment |
add a comment |
$begingroup$
Almost all of my advice is from Courseras "Learning how to learn" which I highly recommend.
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.Make sure you have plenty of fresh air.
High levels of CO2 and low levels of O2 make us tired.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.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.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.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.
$endgroup$
add a comment |
$begingroup$
Almost all of my advice is from Courseras "Learning how to learn" which I highly recommend.
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.Make sure you have plenty of fresh air.
High levels of CO2 and low levels of O2 make us tired.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.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.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.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.
$endgroup$
add a comment |
$begingroup$
Almost all of my advice is from Courseras "Learning how to learn" which I highly recommend.
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.Make sure you have plenty of fresh air.
High levels of CO2 and low levels of O2 make us tired.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.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.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.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.
$endgroup$
Almost all of my advice is from Courseras "Learning how to learn" which I highly recommend.
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.Make sure you have plenty of fresh air.
High levels of CO2 and low levels of O2 make us tired.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.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.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.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.
answered Mar 27 at 7:45
Jens SchauderJens Schauder
1313
1313
add a comment |
add a comment |
$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".
$endgroup$
add a comment |
$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".
$endgroup$
add a comment |
$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".
$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".
answered Mar 27 at 18:15
Luke GriffithsLuke Griffiths
1311
1311
add a comment |
add a comment |
$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.
New contributor
$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
add a comment |
$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.
New contributor
$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
add a comment |
$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.
New contributor
$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.
New contributor
New contributor
answered Mar 28 at 19:09
feritferit
1313
1313
New contributor
New contributor
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
add a comment |
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
add a comment |
$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.
$endgroup$
add a comment |
$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.
$endgroup$
add a comment |
$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.
$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.
answered Mar 28 at 19:55
ctrl-alt-delorctrl-alt-delor
7,58631547
7,58631547
add a comment |
add a comment |
$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.
$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
add a comment |
$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.
$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
add a comment |
$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.
$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.
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
add a comment |
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
add a comment |
$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.
$endgroup$
add a comment |
$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.
$endgroup$
add a comment |
$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.
$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.
answered Mar 27 at 10:16
Michael KayMichael Kay
33614
33614
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
$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