How to stop hopping the learning chain and actually begin somewhere?

Question

Here is what I feel whenever I find something interesting and feel like pursuing it :

1. Oh so I like X (Computer Graphics), let me read up papers/books about it.
2. Ok let me begin with reading up Y (OpenGL)
3. But Y needs W (Linear Algebra)
4. Well reading up Z (Probability) first makes more sense.
5. Umm, you shouldn't jump to Z without learning U (Permutation/Combination).
6. And how come I forget about reading V (Number theory)
7. And what not..

I always end up searching and reading up "Best books to begin A/B/C/D.." instead of actually making myself begin somewhere. This consumes all my energy and I never really start.

Q. Have others faced this ? Q. How do you handle this and actually begin somewhere ?

Any help would be really appreciated.

Background : I am a working professional, with Masters in Computer Science (fascinated with Computer Graphics etc). Its been two years since my masters but I still kind of miss academia, my thesis work and other interesting stuff I did there. My current work is also pretty interesting and partially overlaps with my interest areas. However, other than work, I would really want to continue doing things related to my masters side by side (and MAY BE take up a Phd somewhere down the line). But the never ending feeling of not knowing anything takes over.

Its not that I am being forced to study any of this. Its purely for my personal interests that I want to pursue it.

---

Update 1 :

Thank you so much everyone for such overwhelming response. I really like several answers and points raised but haven't marked any yet because I am in the process of trying some and would update if something actually works for me. Meanwhile, I also found this talk really helpful :

https://www.ted.com/talks/tim_urban_inside_the_mind_of_a_master_procrastinator

Answer 1

Dan's answer is very good, and I want to add one more point:

Accept that on the first pass you will not be able to fully understand the topic. Appreciate that there are decades and sometimes centuries (for the math, at least) of research supporting the topic you're learning. Thinking you can "get to the bottom" of it in a few months, let alone a week or two, is not realistic. Choose a topic and try to understand that as much as possible. Keep notes on other interesting topics along the way, but don't get distracted by them; just accept them as assumptions as this point and move on. You can get back to them later.

Answer 2

This is a common problem. Self-directed learning, with no boundaries or focus, can easily become aimless and unproductive.

To overcome it, try to find some sort of replacement for the structure that would come in a formal education program. This could take various forms, but here are a few examples of things you could try:

• Make a plan for yourself. You could start off by brainstorming all the related topics you are interested in (sort of like you did in your question). Then take this list and start prioritizing. What are the topics you are most interested in? How much time do you realistically have to spend? Whittle it down to a list of a few books or resources that you hope to complete within the next few months.
• Set a concrete goal. This might simply flow from the plan you have made: "I will read these four books this summer". Or it could be a starting point for your learning that sets the direction you choose to take. "I will learn how X works." It could be a project, like "I will create a small working example of software that does Y".
• Use online learning resources. There are many free online courses on computer graphics and related topics. Alternatively, many college professors post their syllabi online, which you could simply use as a reading list.

Answer 3

If you are actually new to a topic then the papers on it are probably out of your reach.

When I want to open a truly new topic I would start with the lowest level textbook I can get. Perhaps I find that a first year undergrad textbook is not challenging enough to be interesting, but its worth checking each chapter to see if there is anything new. If there is new content then it will definitely be possible to understand without any prerequisites. Then I move on to a slightly higher level textbook, etc.

This should bring you smoothly up to the level of papers, and any periphery knowledge (from other subjects) needed will probably be presented at a level that is easy to access.

(full disclosure, I have only ever done this with topics in maths, perhaps it doesn't work well elsewhere)

Answer 4

Create something and learn in the process

If I want to learn a new programming language or framework, maybe I'll do a quick tutorial but then I immediately have to find something useful and/or fun to do with it. There's no end to the knowledge that you can get on any topic, but if you don't do something with it, at some point you'll just stop. If you create a need for yourself to learn in order to create something specific, chances are you'll get farther. It also serves as a stop gap, when you have enough knowledge to achieve your goal, you continue working on the project until you get stuck again.

Maybe this is less suitable for very theoretical fields but certainly it works for practical fields like computer science, certainly computer graphics.

Answer 5

I totally experienced the same thing both in academia (MSEE) and work life, especially early on:

1. Life is not an academic knowledge competition, so no need to feel inadequate. There will always be people smarter or more knowledgeable than you in any specific topic/niche (see 6. below), with more letters after their name. Go for breadth-first, not depth-first (as @NateEldredge said).
2. Be guided by learning the minimum you need to know to get a specific task done. Always have a specific application in mind, and skip everything that's not relevant to achieving it (Be strategically lazy, in a goal-directed sense). If you don't have a goal, you will just go in circles. You can always bookmark the paper/documentation/textbook and come back and read it later as/ when/ ever you need to know more. Don't try to memorize anything you don't need to, which is 99.99% of what you will ever read.
3. Papers: Textbooks can be better than papers. Webpages can be better than papers. Online tutorials can be better than papers. Webinars, whitepapers, sales demos (the good ones, at least) can be better than papers. Going to a Meetup or talking to a smart friend over a drink can be better than papers. Often, papers are a posturing exercise in showing how clever, name-dropping or connected the writer is (or even bragging about their funding or the size of their servers), not in delivering concise timely accessible information to a lay audience (and I say all this as someone who published papers in my MSEE, and read/skimmed at least 10,000 papers from multiple disciplines). Even when the writer is genuinely attempting to get to the point, they may still not be as good at communicating as the other channels I mention above. If I read a paper and the author starts throwing dense jargon at me for no particular reason and citing bookshelves of erudite publications, I ask myself whether it's worth my while to dig into it, or try to find a dummy's notes, or even poll Google/citeseer/Google Scholar for the wisdom-of-the-crowd on whether a certain technology/algorithm/API/whatever is useful, relevant, applicable and competitive.
4. Ten 5-minute lightning talks or poster sessions can be better than one 1hr talk. Often, information density is proportional to log(duration). Commercial conferences can be better than academic ones (sometimes). Hallway conversations can be better than lectures.
5. Use the right resource. Mailing-lists, user forums and asking your question at a Meetup event are all great ways to source a quick wisdom-of-the-crowd opinion. As long as you show you've done your basic homework first and you're not a help vampire. (Conversely, give back, too, whenever you can)
6. Find strategies to deal with information overload/impostor syndrome. In general, become aware of and reject all of that, inadequacy, guilt, grief, existential angst, information overload for not reading all the footnotes and citations and wading through the proofs line-by-line. Information is being generated orders of magnitude faster than we can ever process in our lifetime, and accelerating. All we can do is filter the ever-diminishing sliver we need to get on with life. "I will always choose a lazy person for a difficult job. Because, he will find an easy way to do it" - Bill Gates. Personally I know one guy who trained an ML suite to automatically summarize the 10,000s of pages of quarterly technical reports he had to stay on top of in his field (IT security). He's a brilliant guy. This wasn't even in his job description. Always try to cut corners, automate, generalize, abstract, use third-party open-source libraries.
7. Friendships, professional acquaintances and contacts matter. Get to know smart people and shun useless people ('lazy' != 'useless'). Work your network. Never eat lunch alone (TM). And so on. Now you can tap on 1000 people all distilling information and experience. Again, don't overuse it, give back as much as you take, and keep a running note of what you can do to help each of those people. A fresh pair of eyes, support, encouragement, or even some relaxing activity getting your mind off the problem, or exercise, all add up.
8. Perfectionism. Don't let the perfect be the enemy of the good. Surprisingly often, the 'right' way to do something is not apparent or documented, or it's moot, or context-dependent. You have to strike a balance between trying stuff out, prototyping ("code beats arguments"), breaking, failing and learning quickly, vs researching the answer. Academia tends to bias us to the latter and away from the former. v0.1 code is not usually about optimality (although in the occasional cases where near-optimality can be simply and quickly achieved then we should strive for that). By all means come back and polish/simplify/generalize the code as necessary, later, as priorities allow.

Answer 6

A key point is to realise that you can never understand everything and that, to understand a particular topic, you don't need to fully understand its prerequisites.

Your approach is to say that you want to learn A, but A uses aspects of B, so you will learn B first. And then you find that B uses aspects of C, so you will learn C first. Oh, dear, but C uses aspects of D which uses aspect of E which...

You don't need to fully understand B to understand A. You probably just need the basics of B and maybe a couple of sub-areas in more detail. To understand those, you probably need hardly any of C and so little of D that you can, for now, just consider the couple of facts you need there as being knowledge given to you by the gods, which you might never understand.

Notice that we've turned the divergent series A + B + C + D + ... into the convergent series A + B/10 + C/100 + D/1000 + ... .

Later on, if you want to do actual research in A, you'll probably find you need to know a bit more about B, which might mean you need a tiny bit more about C, and maybe you'll have to ask the gods to reveal to you a couple more of the mysteries of D. It's very unlikely that you'll ever need to know that E even exists.

Answer 7

Like Donald Rumsfeld said:

"[T]here are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – there are things we do not know we don't know."

It is important to know what you don't know. Engineers, e.g., work with a lot of formulas and approximations without questioning every single fact behind it. If you want to work productively, don't question all at once.

You don't need to be an expert in number theory if you want to be good at computer graphics. But you might need Linear Algebra basics and good knowledge of OpenGL. So your numbered list could be used as prioritization. If you pursue your PhD, your goal is to be an expert in your field. And the thing in your list above that interests you most might be that field. Not all at once.

Answer 8

It's rather simple:

• Take an introductory textbook on X.
• Read it (and do the exercises).
• Hard part: Don't switch to another textbook/online guide/etc on any underlying or related subject until you're done with the book. It contains enough of what you need.

Now, choosing a good textbook is not always an easy task but that's a subject for another question. Perhaps get a knowledgeable friend to recommend one that covers underlying/related subjects to some extent so that you wont feel you're learning in a "contextual vacuum".

Answer 9

Any answer to this question is necessarily going to be somewhat subjective, as it's ultimately about motivating particular behaviour in yourself.

I certainly wrestle from time to time with "reading vs doing" - reading about new things is fun, but ultimately it's not very helpful (and, to be honest, results in fairly superficial understanding) unless you're doing something with that new knowledge.

For me, what helps with that is choosing something specific I'm going to do with that knowledge. (Let's face it; "Learning about X" isn't a very well-defined task.) Now, sometimes it takes a little bit of casting around to figure out something interesting to do in that area, but I can generally find something interesting and tractable-seeming without getting too lost in the weeds. It could be:

• Reproducing the work in some paper which seems interesting
• If the paper authors already have made code available, playing with it and trying to extend it in some straightforward way, or fix a bug in it
• Committing to teaching some people about a package/technique/paper - coworkers, give a talk at a Meetup or a Papers We Love event, or the like
• Choose a set of well defined topics (overview of a couple of recent related papers, a technique, a package) and commit to writing some blog posts about them

etc. Then it becomes much clearer to me how much time I have to spend digging into related material: "will this help me write the code/patch the code/write the tutorial/write the blog post?"

An added benefit of especially the last three items on the list is that you're now contributing something to the wider community, and making useful contributions is a good way to establish yourself in a research area if you do decide to pursue a Ph.D. or even just do further work. And yes, paper summaries (particularly compare/contrast recent papers), tutorials, bug fix PRs, etc are useful contributions - just look at how many citations review papers get, or how many people follow Adrian Colyer's tireless work on The Morning Paper.

Answer 10

My strategy when I want to learn something new:

1) Think about what you want to accomplish (have the end in mind). For you this might be an animation or game, etc.

2) Go as far as you can on your own. At the beginning this might be nothing, and that's OK.

3) Learn only as much as you need to get to the next step, then go back to step 2. Repeat the cycle.

I find that spending too much time on learning background material results in excessive cognitive overhead. It's often best to start simple and approach learning as a "just in time" process (borrowing from the lean manufacturing principle). Perhaps this is slightly oversimplified, but you probably get the idea.

Answer 11

I'm facing this problem in computing all the time.

My personal approach is to decide on something really reasonable I want to achive (like printing "hello world" on screen), chose things that help me towards the bigger goal.

Then I pull all available sources to make that work first. Sources are books, tutorials, stackoverflow searches, youtube videos (a great resource!) or asking someone to help me do it (while I document all steps so that Ican redo it on your own). If I need outside help to solve the problem, I will redo it again from scratch once the person who helped is away!

This gives me either a quick success - or a quick reason to delay or give up!

If I manage, I now decide to attempt to either understand what I did or I set the next goal. Ususally getting things to run involves using code I don't fully understand. I don't mind for the time, because I now have a cookbook example to fall back to. Usually, if I re-read book on the topic after getting something to run, I understand why it's working. Having working code is also helpul if I want to talk about this with somebody else who might be able to help to improve it.

Answer 12

I used to get this problem when I was first learning programming. I still get it now sometimes because I have a tendency to want to know everything about a given topic all at once.

Over time though, I've found that the best approach is to learn as little as you can possibly get away with in each subject and then iteratively refine your knowledge as you go.

Your current thought process is

'I need to know all of V before I can learn U'

implying you think you need to learn these topics sequentially and that you think you need to learn each topic in depth before moving on.

What I am proposing is to learn parts of the topics simultaneously or in rotation, i.e.

'I will learn a bit of V and then apply that knowledge to U to learn how the two things are related'

For example, you want to learn computer graphics so you decide to focus on OpenGL. OpenGL requires knowledge of vectors and matrices. Vectors consist of many sub-topics (addition, subtraction, dot product, cross product, scaling) as do Matrices (addition, multiplication, determinants).

Instead of learning all of these topics before attempting OpenGL, learn a sub-topic and then apply that knowledge directly to OpenGL. Learn what a vector is and how to add/subtract them, then define a vector using OpenGL and test out some addition and subtraction. Move on to the dot product, test in OpenGL, learn about the cross product, test in OpenGL etc.

By connecting the two parts at each stage, you end up learning the implementation alongside the theory in small chunks. By the time you get halfway, instead of knowing all about vectors and nothing about OpenGL, you know a bit about vectors and how to apply that knowledge in OpenGL, meaning you can do more earlier.

Answer 13

As a different take on it, this also describes classic ADHD (ADD) behaviour (not saying that's you, but its how that condition typically affects people as well), so there are also coping mechanisms from that direction too. A good book on managing distraction might have helpful tips. Maybe as simple as a post-it?

Basically, you have to decide if you are doing these because you need them, or because they interest you. Most people don't need linear algebra to use or enjoy computer graphics code. If you want to, or its for pure interest then more power to you, let your focus wander where it likes. But if you want to do a specific topic, and this is a distraction looking back, then draw a line at some point and know whether or not you want to follow "wherever it goes" or to learn and do something at the first level.

If you have 2 topics (graphics and linear algebra) then you might find you don't need to learn one or know "how it relates" to the other.

If you feel you need this to learn a subject, then the advice given by others is also good - pick a specific target task, and do only what's needed to achieve it. This will teach you some aspects of the toolset you need. After a few tasks you'll get quite adept with tools without distraction.

Answer 14

Yes it does happen all the time - it happened to me a PhD, an academic career, and an industry career notwithstanding.

Please realize that the main value a formal academic training provides in our days of online resources is exactly what you are struggling with here: creating a workflow from learning the basics to gain control of the advanced stuff - all the while juggling inter-dependencies - that will lead you to master your desired skill.

However, it is clear that if you wanted to go back to school, you would already have done so.

So you'll have to go the way we all go after college: start from the very end and practice the simple stuff of the skill you would like to master. Realize you don't really know what you are doing, study it a bit and try cracking the nut again. You'll think you got it, while all of a sudden a new problem will have you face the harsh truth there's so much you don't know yet. Back to a book, crack a new problem, hit the wall with another one. Live, die, repeat. Don't obsess with going over all nine hundred pages of computer graphics bible. You'll probably need only two or three chapters anyway.

That's the way it goes in adult age. Luckily with computers-related problems, there's plenty of companies that are willing to pay for you to learn all of this. Unlike academia :)

Answer 15

This is meeeeee, oh, man. I'm such a dilettante. I forgive myself for it if it's hobbyist stuff and it just turns out not to be a real passion. It doesn't always feel good, though, and I get you. When I'm doing that, I also complicate matters by holding myself to the standards of what I think other people can do. For instance, I keep trying to tell myself that, if I were really interested or capable, it should be easy to make myself do it and stick with one thing. That's not true, though, so I've learned to treat it differently. Pick a very specific topic that interests you. Go ahead and do some Googling, but sit down and tell yourself, "I'm going to find a good book to learn about [that very specific thing] and buy it." Don't put it on your Amazon wish list. Go ahead and order it. Then, when it comes, make yourself a rough plan for how you want to go through the book. Come up with at least an idea of how often you want to work on it, and be conservative so it's easy to maintain. Then, dig out a bag, get yourself a clean notepad and pen or pencil, and put those and your book in the bag. That's now your school bag. Nothing else goes in it except your wallet, phone, and keys. At the times you've set out, take your bag and go to a coffee shop or library for a limited period of time (plan on an hour the first time and see how you feel, but decide the period ahead of time and stick to it).

People like us have a tendency to burn ourselves out, both in the planning and in the execution, so if you work on avoiding burnout, you'll go a long way towards being able to accomplish your goals. I'll add that I've also had a lot of success with MOOCs, because they keep me on track.