Ask HN: Do you get impatient when learning new things?
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?
83 comments
[ 612 ms ] story [ 1358 ms ] threadBut 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'.)
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.
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... :(
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!
Exactly my current situation with Clojure.
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.
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.
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).
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.
https://www.youtube.com/watch?v=ITTxTCz4Ums&t=21m30s
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.
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
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-...
If you then still can't focus or make enough effort, you simply don't want to learn it.
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.
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.
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.
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.
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.
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.
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.
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.
https://www.offensive-security.com/information-security-cert...
I can read considerably faster than you can speak. Please just give me written materials.
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.