Ask HN: Do you get impatient when learning new things? | Hacker News Reader

Ask HN: Do you get impatient when learning new things?

96 pointscsbro79 comments

I get really impatient when learning new things. I tend to want to finish reading the book as fast as possible, which means I end up not doing the practice exercises. Sometimes I just give up because the book is too long. Also, because I'm always thinking of the million other things I need to learn, I can't really focus on what I'm learning. Every time that happens it makes me depressed. How would you deal with this issue?

View on HN

TL;DR: Just start.

I've this too. When I learn something new like a language I often want to do it right, like be "pythonic" when learning Python. It can take long for me to write some simple piece of code because I'm constantly doubting if my code is pythonic. And when it takes to long I lose focus and I stop.

The same thing applies when I started a little Go web app, Go was rather new for me. I decided to use Docker and wanted to have a perfect solution with 3 containers(Nginx as reverse proxy , web app and API), auto rebuild and autoreload in developement mode etc. Than I started with writing in Go and everyone had to be tested perfectly, so I was looking for how to test things and how to run tests automatically after saving a file.

These things slowed me down to a point I where stopped. What did I want? I wanted to learn Go. What did I achieve? I learned how to create have production setup for a web app and api in Docker, I learned something about test suites in Go and I was frustrated because another learning project failed.

My advice, just start your project. You can't do it perfect because you want to learn it!

> I've this too. When I learn something new like a language I often want to do it right, like be "pythonic" when learning Python. It can take long for me to write some simple piece of code because I'm constantly doubting if my code is pythonic. And when it takes to long I lose focus and I stop.

Exactly my current situation with Clojure.

Mine as well.

I totally agree. If all you care about is to learn the language, just write code. Don't worry about all the other things that you may want to do. Just to Add on to it: If you want to learn python, don't start with django. If you want to learn javascript, use simple libraries like jquery. Basically start simple. My usual technique is to get the most basic knowledge about the language or a framework and then spend time building something (simple todo app, a wiki etc) and learn more about it in the process. I rarely start with a book. I try to find a succinct tutorial so I an read it quick, and start on building simple apps.

Keep focus: Learn or do one thing at a time (apply your iterative philosophy on top).

Agreed wholeheartedly.

There are times when you should read and learn every detail before actually starting a new activity. (e.g. ground school before flying) This is usually when the cost of failure is unacceptably high.

However, this is usually not the case, especially with things like programming, if that's what OP is talking about.

Advice to "just do it" may seem simple, but it is surprisingly effective. When you learn by doing, you setup a feedback loop where you try something, see if it works or not, and if it does not, find out why/where it went wrong and retry it. For most people, this is mentally stimulating and provides the necessary psychological rewards to keep you going. If you get stuck/frustrated, this is when you should take a break and perhaps go back to reading/researching after a while.

Don't worry about whether you're doing it the absolutely correct way, or whether what you've done is worthwhile to others. (What is "absolutely correct" is often subjective, anyways) Focus on the knowledge you gain, and take notes.

For example, I've also been recently learning Golang. I wrote a simple Golang game server (using a SockJS library) to serve as a backend for a simple, multiplayer online game. Looking back, the initial code I wrote was horrible and needs to be refactored; but that in and of itself will be another learning exercise. Did I need to use Golang for this, or is this the best use of Golang? Probably not - I could have written it using Java or Node.js much faster, but wouldn't learned as much.

Stop thinking of learning as something you do before you can do what you want to be able to do. Think of it as a range of things you practise over and over again in order to develop a skill. For some skills that learning process is something you might do forever (in my opinion coding is firmly in that category).

For example, if the skill you want to learn is mountain climbing it's useful to read a few books before you climb a mountain - but what you get from a book is information to think about, not the skill to actually go out and do it. You learn mountain climbing by practising climbing mountains over and over again (preferably with a mentor). Every skill is like that - if you want to be good at it, keep doing it.

One more thing: If you really enjoy something you'll enjoy the process of getting better more than the end result, so if you don't enjoy it while you're rubbish at it you won't enjoy it when you're good at it either. Don't struggle with learning something hoping that you'll love it later. You probably won't.

All the time. I deal with almost constant anxiety over how my time is spent, even to the point where I can't always enjoy leisure activities. I don't know what drives this. I am not an overly competitive person and already have a decent job where people respect me and my abilities as a programmer, yet I rarely spend a waking moment not thinking about all the things I could be grokking.

I guess what it boils down to is that a lot of my self esteem is derived from being knowledgable and resourceful. It really embarrasses me when I don't even have a shallow depth of knowledge about a subject matter that could be potentially useful.

I don't really have much advice for you because I haven't really solved this one for myself, but one thing I try to do is concentrate on very short term goals. For example, when I was learning Angular a few years ago, I knew going into it that I wouldn't "get it" right away. After a few frustrating days I decided to break-up my learning into small goals, e.g. "what are promises and how do they work?" "What is the syntax?" "When should they be used?" I tried to avoid unrelated documentation and stack overflow posts because I knew that it would lead me into rabbit-hole after rabbit-hole. I wasn't 100% successful, but it did help me block out some of the cognitive dissonance.

The only other thing I'd say is that even though this is frustrating, I like to think that your anxiety is actually a good thing if you learn to channel it constructively. It's a good thing to want to know about a lot of stuff!

I'm right there with you. My motivation comes from a combination of self-esteem and a large amount of curiosity.

I've found that constant progress is key to keeping engaged with learning. It's tempting to try and learn multiple things at once but each new thing slows down progress exponentially. It's much easier to focus on one thing and get a constant stream of little victories.

The trick that helps me is to do a iterative deepening learning. For example when you are reading a long book on a complicated topic, don't try to study every chapter perfectly before you move on to the next chapter. Things will fall off your head pretty quickly anyway. Instead, I would quickly skim through the book, get familiar with the main ideas and concepts (but not too deep into the details). Then on the next iteration I'd go deeper. You'll find that some chapters will require more iterations and some not. Also try to identify the important parts of knowledge that you need to learn and focus on that.

I don't know, this somehow seems to ignore the case when chapters rely on something that should be clear from previous chapters. It happened to me a lot when I was at University that I'd think to just skim over a chapter, poorly understand the following one and that would snowball as soon as I reached the end of the book.

That would mean you went deeper in this chapter than in the previous one. The first fast iteration is really to get familiar with the main ideas and terminology. For example if it's a book on algorithms, you skim through it and understand what is linkedlist, what is tree, what is graph, their running time but not the details of implementation and certainly not exercises. Then on the next one you try to understand basic implementation, but still not doing any exercises. Then on the next one you try to implement them and do some exercises. That's fun, keep you moving, refreshing your memory and it doesn't feel like you've been reading this book forever and still on the 3 chapter.

Well, that's when you try to use skimming as a foundation for actually learning the next concept. If I'm just trying to get an outline, all I really have to understand is that -for example- the Jungian and Freudian models of the mind are very different, but were foundational for much of psychology. On the next pass, I learn more about what they are, and I retain it better because I remember the skimmed materials from later lessons that relate to particulars of those psychological models.

Yeah that seems to have worked for me.

Also it's a great idea to call it iterative deepening. Lower memory requirements but gets the job done anyway! I used to judge myself harshly for not getting something on the first read around, but going through multiple times is normal for me now.

Progress is made by consistently working at a thing every day. If I were you, I would choose one topic (for example, a specific programming book) and keep track of what that one thing is that you make progress on every day. Have a good reason for choosing that book so that you can be motivated; remember why you started that book or whatever it is. If you try to learn other things besides that the rest of the day, and those things change with your mood, that's fine. Just have that one topic you're learning be something that you don't change, or at least change consciously when it's the right time (finished book, or your reason for starting it is no longer true). Spend at least 1 minute every day on that. (I mention only 1 minute because it builds the habit, and you'll usually end up doing more. But if you don't do at least 1 minute, you could go years without doing it, or not do it at all.) You might want to make that 1 thing something you do first thing in the morning, if you're a morning person. There is less chance that something will disrupt your routine that way.

I should start following this advice myself.

Find a little project you want to do using the technology. For example if you are learning Python, come up with a little program/website idea you want to make, and do it in Python. It's always easier to learn "as you go" rather than just reading a book in isolation.

Agree. Throw the book out. Do a project, and if you really care, at the end make it more perfect.

But don't make it more perfect - do the next project. Make your focus to make some money, get more customers, etc.

The beautiful code will follow from that. It doesn't matter how beautiful the code is if no one uses it. (Well, maybe if you need to pass an exam or open source the code or something like that, slightly different goals for the code to 'succeed'.)

This would be my recommended approach as well.

Think of a project you can build with the technology you want to learn, and then learn the technology through actually building the project.

I generally feel more motivated with this approach because at the end of the effort, I'll actually have something to show for my time. If the project idea is good enough, you might even be able to turn it into a business, but don't let the lack of good ideas stop you, because your primary goal is still learning, and for that, even clones of existing products can work (and you might be able to find a good twist on it that can differentiate your own project as you build it).

And for me personally, no amount of reading and exercises can compare with real usage if I wanted to become truly proficient at a technology.

For a skilled programmer who is fluent in a couple of other languages, I actually think that is counter-productive. Better take your time to learn that new technology properly in its entirety and then start playing with it. This way you will have a complete mental model of that technology in your head and you will be more likely to do stuff properly from the first try.

No man. The OP has it dead right: find a small project, write it in your new language, struggle a bit but get it finished. Then go back and see where you could be more idiomatic and improve those parts. Or do another small project but with more knowledge behind you this time around. This is the philosophy behind for example, SICP: "you don't learn Scheme, you use it."

In my experience, a combination is best. Reading gives you the broad scope, doing gives you detail, repetition and context.

How would you start learning a technology would playing with it? I couldn't imagine sitting down and reading huge amounts before trying anything - I want hands on experience as soon as possible.

I didn't really mean to exclude any experimentation while you are learning. Fiddling with the possible expressions that a language would allow in a REPL is OK, but I am against starting pointless little projects before you have grasped something entirely. GitHub is full of these and they are mostly not pretty.

Starting projects before you grasp something entirely is how you get to grasp it entirely. Sashaying it with others, e.g. via github, is often a useful part of that. You aren't entitled to a github with only projects that interest you, and not pretty work is part of the learning process.

This is what I recommend to EVERYBODY who says to me "I've been thinking of learning x language."

I get incredibly frustrated with 1) people who "design" (and I use the term very, very loosely) the actual tools you're learning, and 2) then even more so for the people who teach the tools, as though it's the only thing that existed - even though any member of the target audience has to know a thousand very closely related things, so that honestly you could just point out the 5 tricky things.

For point 1 - things should be like Python, not like resolving dependency hell in the 90's. Installation should be a double-click. Errors should not be easy to make, it should be obvious what things do, and error messages should be obvious. The people who design tools don't care about any of this stuff.

For point 2 - honestly, 99% of people - as in, 99 out of 100 people, who pick up a Rust tutorial have programmed literally 4 other languages - they have written working lines of code in 4 other languages. Look at this shit: https://doc.rust-lang.org/book/ (open the menu at top-left) - Guessing Game! The Dining Philosophers! "Let’s set up a new project. Go to your projects directory. Remember how we had to create our directory structure and a Cargo.toml for hello_world?" in just as many words that your poor audience has to read through you could have said: "semicolons terminate statements; blocks in curly braces; module import is use module::submodule::symbol; comment with // or /* */ which can nest." Look very very closely at my two strings in this paragraph: they contain literally just as many characters.

You could start by summarizing go in a sentence and get people going, not trace it back to the ENIAC. I hate this GOBS and GOBS of time people assume we have.

And back to point 1, tool writers assume we have like infinite time to follow 27-point directions that could be 100% automated. And tutorial writers assume we have infinite time to read all about the history of the world. I have to watch YouTube videos at 2x speed so that they're sounding like they're rapping, just so I can get to all the stuff I don't need.

Get to the point, people. Not everyone has a picnic following directions that shouldn't even exist.

1, tool writers assume we have like infinite time to follow 27-point directions that could be 100% automated. And tutorial writers assume we have infinite time to read all about the history of the world.

An alternative explanation is that their audience is wider than your stated 99%.

Somewhat ironically, if you scroll down ~20 lines on the Rust book page you linked there is the deep water you are demanding.

I don't think, for example, "semicolons terminate statements; blocks in curly braces; module import is use module::submodule::symbol; comment with // or /* */ which can nest." is deep water. The tutorial has to make a decision: does its audience know what a loop is, or how to even think about an algorithm that would use it? If the audience doesn't, then it's not a Rust programming language book, it's a Beginning Programming with Rust book. If the audience does, then they just need to be told the syntax.

Even when they ostensibly do that, "The main concept that makes Rust unique is called ‘ownership’. Consider this small example:" could be better-stated as a difference between Rust and (list the languages that don't have it.)

Tutorial authors and tool authors also waste INCREDIBLE amounts of time through dishonesty. For example, Functional Programming like Haskell is largely defined by the hoops you have to jump through syntactically and in program structure due to what it avoids. But a Haskell tutorial will NEVER make it obvious within the first two minutes that you are doing something fundamental different from C, Java, Python, C#, Perl, whatever - and that it has a whole concept, monads, just to get around this artificially imposed self-limitation.

They're just dishonest, waste incredible gobs of time, and don't get to the point.

When was the last time you picked up a language book that made it completely obvious in the first minute what it was and wasn't suited for, how many hours you would need to practice it before you made progress, and what the absolute bare minimum number of minutes you would need to invest before you could start doing anything in it was? It's a guessing game. "Wow, this only took me two minutes!" (json). "Wow this took me two weeks and I still can't do shit!" (haskell)

I Googled "I tried learning haskell for" to report on what I found. There happens to be one hit on that exact syntax. Guess how long the guy "tried" learning haskell for? A few months.

This gets back to the thing where the author (probably necessarily) has to write for a wide audience.

Someone who enjoyed math in various school classes will probably understand the basics of functional programming faster than someone who only worked their way through it. So one of them might be just as angry as you are at the bad advice in the front matter of the book.

From the Rust book intro: "After reading this introduction, you’ll want to dive into either ‘Learn Rust’ or ‘Syntax and Semantics’, depending on your preference: ‘Learn Rust’ if you want to dive in with a project, or ‘Syntax and Semantics’ if you prefer to start small, and learn a single concept thoroughly before moving onto the next. Copious cross-linking connects these parts together."

It sounds like you should have started at "Syntax and Semantics". For me, I really enjoyed starting in "Learn Rust" because I'm more of a "learn by doing" kind of person, and I find that I cannot retain any information from pages of syntax descriptions.

Neither of us are wrong, we're just both different when it comes to learning.

I didn't read through that book, I've never tried learning Rust so that's why I googled Rust tutorial so I would have an unbiased opinion on the first thing I found. You've just LITERALLY made my point for me by quoting instructions that sound like they expect to spend 20 hours on this thing right now, including referencing two other tutorials. Imagine if the first time you used a hammer it came with a reference to three different books you should read about it. That would be stupid - nobody would use a hammer then.

They should replace their expectation of 20 hours with 20 well-chosen lines anyone can use to start. If the language doesn't do that because it's too high-context, change the language so it's easier. Baby steps in Rust, or any other language, shouldn't take any number of days.

You can use a saw to cut a stick in half, but you can also use it to create joinery. Learning something as complex as joinery -- and doing it well -- is necessarily going to take some time... even though you could probably teach an ape to use a saw.

Different learning resources have different goals. This is a book that is meant to be comprehensive, but also provides two different ways to approach learning the language. The target audience of this book was never intended to be someone who only wants to devote 20 lines of effort to learning a programming language. If that's what you want, read http://learnxinyminutes.com/docs/rust/

Edit: But when you realize you can't grok language semantics like borrow checking or sum types for results, you might have to spend more than 20 lines of code to understand the usage and benefits of those concepts. This is when you move from sawing to joinery.

except it's more like, "we have joinery equipment that is smart enough to safely drive a car in the place of a human driver - but we still won't let you just ask it to cut a stick in half. Learn a new trade, become a joiner if you want to cut wood!"

Because my gripe isn't that joinery exists as a trade - it's that equipment that is so smart still won't do simple things for the user - on principle. People actively design their tools so they won't do something simple. Yes, really.

I get impatient with learning materials in video rather than text form.

I can read considerably faster than you can speak. Please just give me written materials.

I have sth similar. Only noticed after I've seen how my wife learns. She does it depth-first (won't move to another subject till she knows every little detail from the first subject), I learn breadth-first (a little of everything, skimming the books, then I try to do sth and look up the details as needed).

I think for IT breadth-first is better at the beggining, but you can stay half-competent for too long if you never bother to look up the detais that weren't needed so far (my main problem).

I did a great course earlier this year on Coursera called "Learning How To Learn"

It's pretty short but covers some good strategies for learning that are backed up by current Neurobiology research.

https://www.coursera.org/learn/learning-how-to-learn

Could you share some of those strategies?

Sure. There are loads of things to cover but I'll outline the ones I found most useful. Some of them are common sense but sometimes that ain't so common ;)

Avoid procrastination 1 - Set aside time to study a little and often rather than trying to do huge sessions. Cramming doesn't work, your brain doesn't like it. 2 - Turn off your phone, shut down those facebook/email/reddit/imgur tabs so they're not tempting you. 3 - Don't get disheartened by thinking about the whole topic at once. How do you eat an elephant? One little bite at a time. 4 - Just get started, even for a few mins. You'll get into the flow after just a few mins.

Take your breaks 1 - Recall is greatly improved by taking a short breaks to let your brain digest the material you're learning. 2 - Try the pomodoro technique. Focussed work with zero distractions for 25 mins, then a 5 min break, repeat. For coding I prefer a longer work period to load the problem into my noggin but YMMV.

As part of the course we had to do up a few small blog entries explaining the material. Another good point: re-explaining the subject cements your understanding of it. Feel free to take a look at mine, I go into a bit more detail on the above items http://learnsmarternotharder.blogspot.ie/2015/01/so-much-to-...

THANK YOU SO MUCH FOR THIS SUGGESTION!

I have the same problem. What I do when learning new techniques by studing a book I progress a project in the same pace as I read the book. For example right now i'm learning about the MEAN-stack, so I picked up a book that seemed good and read the first chapter about setting up and creating a dynamic site with express and node and I didn't continue reading before I was done with my own site for my project. This forces you to really studie each chapter and it's more fun then just reading the book!

When studying more general subjects it's not always easy to come up with a fun project and the books are usually not structured in a way that this techniques works. In those cases I try to find a good course online with a lot of reading material or a recommended course book because just watching videos and doing exercises is usually not enough to really learn the subject for me.

I am surprised that no one has mentioned ADD/ADHD yet in this thread, but maybe that takes patience. If all the ADD/ADHD self-rating scales were boiled down to just one question, that question would be "Are you easily distracted?" If you are easily distracted, focus your attention long enough to see if a medical appointment might be helpful for you.

How I come to give this advice here is that years ago, a participant here on HN described how his programming career struggled until he got medical treatment for adult ADD. Now he can learn more effectively on the job, and he makes a lot more money with a much more stable employment history. You owe it yourself and to anyone else who has helped you develop as much as you have so far to check your attention regulation so that you can be as healthy and happy as possible.

Maybe try a more iterative approach to your learning? Try to skim a chapter and then start on the practice problems. When you get stuck go back to the chapter and find the relevant passage.

It might not be as efficient as reading the chapter all at once but I think you'll feel like you're making continual progress by tackling the practice problems sooner.

As someone who has an extremely low attention span I've found that continual progress is the key to sticking with something. This is also why I try to only learn one thing at a time since you progress much faster than trying to learn multiple things at once.

I have this trouble with mathematical topics in isolation. It bit me in school as I was very good in most of my classes, but when I had to learn (for example) trig identities, and various rules in calculus in order to slog through problem sets, free of visualizations or some kind of real-world problem, my eyes would tend to glaze over. It has hit me in Haskell because I have tried very hard to understand some of the mathematical formalisms associated with monads, etc. but learning those in the abstract, from a page, without actually writing code to solve a specific problem, was very difficult for me. It's frustrating because I'd _like_ to be the kind of guy who can and does work through a pure math textbook on category theory or linear algebra or whatever, just for fun. But apparently I'm not. I learn best by actively beating my head against a real programming problem. If this is a programming thing you're trying to learn, my suggestion is to keep it tied to a real program.

If it is really severe, consider being evaluated for adult ADD. I probably have this in mild form and also what might be considered the opposite, obsessive compulsive personality disorder, which results in me veering between wanting to understand _everything_ and working obsessively on _one_ thing trying to get it textbook-perfect and understand it completely. This combination often intersects well with the requirements for my work but sometimes... not so much, as I either insist on solving a problem better that is already working well enough, or considering a whole range of possible approaches when I really just need to complete one, and quickly.

I struggle with this as well. I have difficulty maintaining high arousal and curiosity with mathematical topics in isolation. I think it is harder because I can't always see a path to applying the concepts to interesting problems.

I had the same problem. How did I solve it? First of all, I don't learn new stuff just for sake of learning new things - I am always trying to solve a problem, even the simplest one. Create simple requirements and keep trying to achieve your goal as soon as possible. Once your tests (even ugly ones) pass, you can start refactoring and make your code idiomatic for a given technology/language. At least it's my way of doing things.

Sounds familiar. Nowadays when I really want to learn something I write everything down to a notebook, sometimes copying paragraphs verbatim. Seems to work for me.

Have you heard of mindfulness, or Zen meditation? It's the practice of sitting, quietly, without thought, focused on your breathing. The general idea is to quiet the mind and to be focused on the moment we're in.

I've found that when I meditate for even just a few minutes a day, I'm much more focused and less distracted -- more focused on what I'm presently doing, right now.

Sounds like you're broken. I was once too. Couldn't focus on anything. This is a good cure from experience:

http://www.open.edu/openlearn/education/learning-how-learn/c...

I used to be exactly like that. As a consequence I never really picked up any in-depth knowledge through school because hitting the basics was usually enough to "get the grade" and there was precious little "reward" (of whatever form) for pushing it further.

When I was 18 a tutor - who I didn't really know well - said to me in passing, and seemingly pretty randomly, "Your problem is that you want to run before you can walk with everything."

I had an epiphany over that and slowed down my "gets" for small, insignificant objectives and spent the time trying to really understand things.

From that point on I actually learned how to program properly rather than just doing enough to get by, for example.

As I've gotten older I've learned that my chasing the "gets" was a self-imposed restriction because there was always a small but sufficient reward for the accumulating of praise, etc. I've taught myself to very stringently prioritise (recent book suggestion: Procrastinate on Purpose) and categorise the things I "have to" do and instead of doing a hundred things that don't really matter (but they were easy and I get a "thanks") I work out which things I "have to" do will actually add value and make a difference, even if achieving them will take much more effort.

As my career has developed I've moved into being a specialist and now find myself coming back out into being a generalist but the "real" grounding in my skills sets me apart from "career generalists" and "credential whores" that my industry is plagued with nowadays.

EDIT: thinking about it, this "get" behaviour started when I was in junior school. I used to read encyclopaedias for facts and tell people. My parents used to praise me for what I knew, and my friends jokingly called me an "information magnet". I liked my cursory knowledge of "everything" and I guess I became addicted to it.

It really helps me when I am learning something that is a ton of fun to learn. The OSCP cert may not be exactly your area of interest, but I guarantee you will have fun and gain a ton of confidence in your technical skills. OSCP teaches you how to do security pen testing. It has been so much fun and so addicting that I often struggle to pull myself away from the computer until 3AM. Many of the tools I use are written in python and ruby. It will also teach you to take the responsibility to write secure code very seriously.

https://www.offensive-security.com/information-security-cert...

Why are you thinking of "a million other things" you need to learn?

That's the core obstacle these days to picking up new skills and knowledge.

Mastery of any subject-matter ALWAYS takes practice and repetition. Simple, but those things require sustained repeated investments of your time and attention.

Here's what I do... I have a relatively-simple pet project that I understand thoroughly. When I decide to learn a new language, I do so by reimplementing the project in the new language. That way, I have a structure to the learning based on the project I fully understand. I then read/skip-through/hop-around books and other learning resources as I need to understand various components of the language to implement the features on the project. Here's one example implementation of it, which I need to write anew to learn Swift: https://itunes.apple.com/us/app/pyramids/id589550650?mt=12

My strategy is more or less to start by figuring out the structure of a text. This may be in the table of contents, introduction, index, chapter sections, or subsections. I generally scan the text as fast as possible to find all the essential points of interest, marking them down for future reference. What I do after this point is likely different than most. As every text I read is digitally formatted, I don't actually try to remember or deeply understand much at all on my second pass through the material. Instead, I will open a text editor and copy and paste the passages that strike me as most essential, retaining as much context as necessary to retain the original meaning. On my third pass, I will restructure the extracted content, cutting out the redundant parts, re-mixing, or re-expressing them until each chunk I want to remember is accessible and concise. This completes what I'd call the conceptual phase of my reading, which takes a fraction of the time it would take if I were attempting to understand the work using a more linear or comprehensive approach.

There is still much I don't understand at this point. This is natural since I haven't had an opportunity to apply the information to a personally meaningful context. This is the point at which I begin the practical phase. As most of what I need to know is documented in my notes, I will keep it on hand as a memory queue as I engage with specific questions or problems that interest me. And so when an issue comes up that I can't settle, I refer to the notes and also search around online to find out how I should apply the content in that particular problem situation. It's over the course of this process that I internalize the most vital details. That's where the learning happens, at least for me.

Another advantage to this approach is that you will have a type of mnemonic device to reboot your knowledge. As most people forget practically everything shortly after moving on to new subjects, it's critical to have a way to index the information you don't want to forget in the future. Something along the lines of a "memex" (or external memory system) is a good metaphor for what I'm talking about.

I'm currently learning Clojure by reading the Clojure Programming book. Its really been a struggle. You're right about the impatience part. I think everyone goes through it at one point or another.

Especially with learning a Lisp language, you can be really frustrated by having to read so much before you can actually create something.

But slowly and surely I'm learning. I just re-read the chapter(s) I don't understand over and over again.

So my advice is don't try to skim over a whole book. Try reading as slow as possible, and if you don't understand something, take a break and then get back to that same shit once more. And of course, write some code as soon as possible.

Just pretend that you are back in school and have exams at the end of the semester.

my 2c - I'm a very passionate learner - a softtop engineer (eg no education) who got where I am through the blood sweat and tears of personal drive and learning on the go. I'm a decent engineer now, and have really figured out what works for me so this is my current perspective on approaching learning.

The practice is important. I plow through books too but you need a project to become proficient. I bought a laptop and started working on some small scala projects on my laptop and reading books. That was enough to let me submit some janky scala for an interview and land a job as a scala engineer.

Some material is harder to learn, some of it is easy. I think it's better to defer reading books for a bit and get some familiarity with the basics so you have a point of reference while reading. The other day I was assigned a pretty big feature with a piece of the domain I wasn't too familiar with. I spent a few days writing a parser to get closer to the spec before starting to work on design docs etc. Having the familiarity then allows me to make sense of the research and existing design documentation so I think having a point of reference is a really important part of the reading/learning. If it's too far away from my current experience, I can't draw new pathways so it just falls out of my head. If I have that basic seed, I can grow some new pathways and expand my position with reading etc.

Ultimately, I think the best way to learn is to actually present the information again to other people. This is the culmination of practice and research together. To write a detailed article on a topic, you'll have to both write the code and also do a lot of reading. Any gaps in your knowledge you'll identify while you're writing and then it's a simple bit of google-fu to get a really solid level of understanding on a topic as you fill out your article.

Re-implementing things is also a terrific way to expand your knowledge. If you read a pattern book, you'll have some high level understanding of how the patterns fit together. Once you apply the pattern once, though, you'll never forget it and you'll see how it works at a very different level. So couple that with writing an article, etc, and it's a super effective approach to learning.

Same problem here. I want to read so many things that i come to learn nothing :(

I would try to reduce the pressure. Are you genuinely interested in the things you need to learn? Doing the exercises will significantly increase the things you'll be able to recall. Maybe Mindfulness meditation can help you https://www.youtube.com/watch?v=3nwwKbM_vJc

https://www.youtube.com/watch?v=ITTxTCz4Ums&t=21m30s

Maybe book learning isn't for you? Try an online resource such as Code Academy or Coursera. You might enjoy the immediate feedback from each lesson as you make progress.

While being able to learn from books, I find that online courses with deadlines are a tremendous help to stay on track. I think I just need a little pressure. Maybe OP needs the same.

I have a problem with doing the exercises, either in a textbook, or for an online course. I always expect to have the right answer straight away (whether a quiz or a coding problem), and get really frustrated if I don't. I guess 16 years of school conditions you to think like that. I also get a lot of anxiety when learning new stuff, wondering "what if I just can't understand this subject matter, period".

I think the "just can't" part can be mitigated by remembering your past successes. I don't think there was a time where I could never understand something (if I really tried) no matter how hard I tried. Might take a long time, but, eventually at least kinda got it. Now, understand some things in depth... definitely not, but get familiar, sure.

I'm studying for the CCIE exam at the moment. A solution I have found is- if you are in flow state keep working until you burn out. That can be at 2 at night or 7 in the morning. Also try to take on information from different media types- video, books, notes, practice questions, reading blogs. I think the various approaches to problems is what forms the cross networks in your head.

Take some challenges. Maybe 2 hours to write some specific piece of code and try hard. Fix your errors. Learn another part. Repeat.

Just calm down, sit your butt down and read (pertinent to a book). I can understand a million other ideas bouncing up and down constantly but then to make other million ideas happen, you've got to do this.

Why?

Well, logically, if you've started learning something I'm guessing its because you want to do something with it? So have some patience.

Break the thing you want to learn into the smallest possible pieces, and set mini-goals of mastering each one.

The fastest way to learn, say, Python, isn't to read a Python book as fast as possible. It's a lot of little steps in the form of "be able to write an if statement without referencing the documentation."

First off I just wanted to say that there's a lot of great advice from lots of people. My own story is that I've tried, failed and given up, and tried again many times on many things. Learning to first code, finishing a project, etc.

I get impatient reading about people who get impatient learning new things :) But honestly, if you suffer such impatience, try learning something more tactile like playing the guitar. You'll learn patience as well as learning the guitar.

Turn what you're doing into an applied project. Lines in a book are that, in a book. Run a mini-project using the skills you want to learn, and discover much deeper knowledge and understanding.

I don't necessarily do the practice exercises, but I'm not impatient. For me, the only good way to learn something is to start playing with it, using it. I learn from struggling.

If this is a common pattern in your life, a doctor or counselor might be able to help provide a plan of action tailored to your more precise needs.

Somewhat expensive, but worth it, I've found.

I guess you need to watch Scott Hanselman talk "It's not what you read, it's what you ignore" very good description about your situation.

It has a lot to do with the wide choice you have. A lot of research has covered this topic. Look up "The Paradox of Choice".

If I have a deadline I get impatient.

If I'm just cruising through things at my own pace, it's all good.

i have the same problems rather than reading i start thinking i will finished first 5 chapter than next days another x chapters and i end up reading and learning nothing.

Sometimes.

This is a pretty big question. Learning has many flavours of frustrations that go with it. Here's one:

Learning itself is pleasant. I think we're wire to enjoy it. If you had a judo lesson now and learned a simple trip, you would have fun. Give most people their first programming lesson and they'll enjoy jumbling up letters or whatever you do.

Not knowing is unpleasant. In your first lesson you have no expectation. In the second, you double your knowledge. On the 20th, you are dealing with forgetting and you've accumulated bits you find difficult. You are still a beginner, but now you have expectations.

You can trip or throw a cooperative opponent but you keep repeating mistakes, frustration. There is still a gulf between where you are and scoring on an uncooperative opponent. You can jumble words, add numbers or record form data in your db. But, the gulf between doing that and writing your spaced learning iWatch app is big. Basically, you suck and you are judging your performance by the standards of a programmer, judo player or whatnot. Sucking.. sucks.

I'm about 5 weeks into learning a language and I'm in this spot right now. week one was really fun. Every lesson meaningfully improved my vocal, grammar, etc. I know about 1200 words and a decent amount of the basic grammar. You need about 2500 words before you can understand a simple paragraph or video snippet. I'm nearly useless outside of the context f a lesson translating single sentences. I can't think in the language (I translate) which means (A) it's difficult and frustrating and (B) I might understand your first sentence as you wrap up your third…even if I know all the words. None of the gammer is natural to me. etc. etc.

Basically, there's a massive gap between where I am and where it felt like I would now after the first lesson. Massive. Even if I conjure up discipline I didn't need in week 1 and push hard this week, I'll still suck. My vocal might go up to 1500, but I'll regress on something. It's whack-a-mole time where revision is 75% of the work and 50 new words is a drop in the ocean.

Thinking of it, I realize I might have taken the wrong side of the debate. Learnings sucks. I hate it.

But, for the sake of it I'll keep arguing this point. This expectation/reality gap is as irrational as it is inevitable. You know it how long it will to learn things in advance. I know I can't get fluent in a language in 25 hours of practice, but it does create frustration.

Since I'm not going with the "learning sucks, I hate it" conclusion, lets wrap up with stoicism. Good as any, ne? Do thy duty though the the skies fall down upon thee. Seek not vain pleasures of the moment. Rather, take comfort each day knowing that thou hath done thy work. Focusing on your goals to much can make learning emotionally hard (frustrating, etc.), unless your goal can be achieved very quick. If your goal requires 100 hours over 2 months, when you are 46 hours deep, you feel like you aren't making any progress. You are probably wrong, but it doesn't feel like it. Don't focus on the end goal, just do your 2 hours and pat yourself on the head. Good stoic. Nice stoic. Here's a Senecan biscuit. Well done.

Yeah I get that daily too. I find reading is just a difficult task for me, so I try and watch lectures when I can (e.g. on my lunch break in work).

At home, I just try to work on my own projects as much as possible, but I don't have much time every day. It is hard. I exercise (gym) religiously as I find it helps to keep my mind somewhat in check.

Time is my biggest problem really, so this leads to the frustration you have described.

I also like to play challenging games (LoL) - and that is a HUGE time warp... :(

Do, or do not - there is no "learn".

Reply on news.ycombinator.com