I have created a learning framework for myself to learn literally anything.
First of all It’s not going to be easy to get started learning something new because there are many holes in your mental model about the material and the aim of the learning is to fill those holes.
We’re living in an information era. You can drawn yourself in surfing the web/docs/articles if you are some kind of perfectionism to convince yourself that you’re learning. But that’s the trap. You should spend about 30-40% of your time learning the material and 60-70% of your time applying it and then under the process you’ll find: “Oh I don’t know how or what is X” then you go to learn about X specifically. This works best. In other words as you will be applying what you have learned so far you start “learning on demand”. In other words filling the individual holes. This loop will force you to learn the topic.
Overall a pretty good summary of how to teach yourself new skills. I personally went far too much into unguided learning early in my software journey. I took on personal projects that were far too ambitious and floundered with problems that would have been 10x easier if I'd focused on grasping fundamentals.<p>What's missing in this post is that it entirely focused in isolated learning, away from tutors and other forms of interpersonal teaching. Any approach to learning stuff "quickly" should take seriously Bloom's 2 Sigma Problem. [1]<p>Partly offloading your learning problem onto an expert tutor trained in master learning has a good chance of vastly exceeding any learning approach a novice can adopt on their own. The internet has thus far failed to support this learning model, I think because it would be incredibly expensive for students.<p>1. <a href="https://en.wikipedia.org/wiki/Bloom%27s_2_sigma_problem" rel="nofollow">https://en.wikipedia.org/wiki/Bloom%27s_2_sigma_problem</a>
I must say it's worth mentioning that as you build up a library of knowledge and experience in your mind, learning new things become more transitional than exploratory. Picture spoken languages for example. At first it's daunting and most languages have their quirks but overall after a few you find your marks easily.<p>The effort becomes a memory concern where cheat sheets are how you transition or learn quickly into a new space.<p>I'm a polyglot in software development. I can work with most tech stack within 2-3 weeks and be efficient within 3-6 months, idiomatic within a year maximum. A big part of that is due to relatability between spaces. Every toilet has a flushing button and every kitchen has a sink and every language had a form of exposing positive or negative response.<p>My advice is always throw yourself in and swim. Find whatever swimlane or swimming aid available and move forward.<p>One caveat is learning spaces that are constantly shifting. For example, Swift. What a mess. Look up anything in that language and find 5 ways to do something, 3 expired, 1 manageable and 1 undocumented that works. It's sad but know that that's the outlier, not the average!
What a strange article.<p>First, there is no need to put pressure on yourself to learn 'quickly' - that's counter productive.<p>Second, you need to find a good teacher.<p>Finding good teachers <i>is</i> how you learn 'quickly'. Now the way to do that is to have parents who can help you.<p>Really, the way to learn 'quickly', is to be born into a family that's loving and competent at life. Then it just happens - by the time you develop the ability and interest in looking around to figure out what's going on, you'll have been in after-school activities and a good school for like 10 years.<p>There's a bit of an escape hatch - if you're good at academics or sports, you'll get to have secondary father/mother figures and that'll be your chance to catch up. If you don't, you're kind of fucked :)<p>If you weren't born with loving and competent parents, you'll be floundering through-out life, in relationships, in your career, in lack of self esteem. It's a near guarantee, because whatever short comings your parents had, you'll be solving and then some. That's just how life goes.<p>Anyhoo :)
Learning quickly only works when every situation favors you. Because learning requires time while knowing doesn't. In this context, to be learned means to craft on your own. And only by knowing things do you get to master things.<p>If the above lines made sense to you, then only read the following paragraphs because I don't know if you can relate to this or not.<p>Learning quickly happens when you can know things quickly. That way you will have time to explore a lot and test a lot. Going through tutorials and documentation just allows you to know things. Therefore the quality of tutorials or mentors helps to grasp quickly because they just tell you what to know.<p>Real learning happens after you know things. Throughout my life, I got confused between knowing and learning. I can read or hear facts such that it allows me to recall the fact. But there were cases where I actually didn't understand the fact as I hadn't absorbed it completely. I just knew how things were but not the idea and reason why they were such.<p>When you want to truly learn something, to the finest detail, it really really requires a lot of effort and dedication. Picking up new skills is relatively easy. It just requires knowing enough to go through and solve your problems. But honing the skill to master level is really difficult.<p>Think about drawing sketches. You can just watch a tutorial on it and draw. Then close the tutorial and repeat it. You now know how to create at that pose. But when you want to change it, you will have to know about shading, pose, color, etc. Even if you know them, it's hard to use them because you may have never learned about them. Because to learn about colors, pose, shading requires experience and time. The more quickly you can iterate through it, the better you get about your preferences and style. Knowing them will only give you a shortcut. Learning them will give you a lot of creative freedom.
So-called programming "tutorials" have never sat right with me. The idea is fundamentally wrong. It's like trying to learn painting by watching a series of videos in which you're taught which parts of canvas to paint what exact hue to recreate famous works of art, instead of being taught how to mix paints, negative space, and color theory.<p>"I'm stuck in tutorial hell, I understand the tutorials for how to multiply 3 digit and the tutorial for how to multiply 4 digit numbers. But when I try to multiply 5 digit numbers on my own, I just can't figure it out and have to go look up a tut."<p>Programming shouldn't be taught piecewise via 15 minute videos on YouTube of how to accomplish one particular specific task. It needs to be built from the ground up, from first principles of the environment in which you're programming, and the instruction given to pupils must be "determine the solution you need, break it into a series of building block steps, and then perform those building blocks." Not "try to re-create the tutorial of how to make a React component send a JSON request step by step without looking at the video." But no one makes video "tutorials" about the building blocks. Which is a shame, because that's the actual learning part.
I'm thinking of writing an anti-blog post on how to learn stuff slowly. In my experience, the subset of "stuff" that I mastered and differentiate my skills from others is actually the "stuff" that cannot be learned quickly. It's often not so black and white how to learn this "stuff". It requires years of deliberate practice, there will be no tutorials, there will be no king's road (guided learning), there will be no mentors that can help you, there will be periods with no progression, there will be setbacks, there will be periods with no practice at all.<p>P.S. Teach yourself programming in 10 years might be a good example as well: <a href="https://norvig.com/21-days.html" rel="nofollow">https://norvig.com/21-days.html</a>
I think every successful learner in CS or programming is doing a large amount of experimenting. Many books I've read encouraged or even required the reader to extend the software or algorithms written by the authors.<p>Growing in a poor Eastern European country with a cheap Z80 computer, meant experimenting was needed for me to learn as a kid. There were only a handful books about Z80 programming and all were about Basic and also very basic. The other books were either in abstract CS territory, full of high level math or about some big iron machines and languages that did not run on my Z80.<p>So after reading somewhere that I can poke some address to obtain a particular effect, without explaining why, the next question was what happens if I poke another address?
Not sure if this qualifies as "quickly" but my best strategy is to put myself into situations that force me to learn the thing I want to learn.<p>It's the difference between "learn a thing before you commit to doing it" and "commit to doing, and thus learn"
> If you're anything like me, you don't like making mistakes. You want everything to go perfectly, the very first time. This mindset is generally helpful in life...<p>I'd say that it's normal to feel that way but that it's directly detrimental to learning. If you want to learn something outside your comfort zone you must first learn to recognize, identify and embrace the fact that you are outside your comfort zone.<p>Wanting things not to go catastrophically wrong is one thing but not letting yourself play, experiment, or even try, because you want everything to go perfectly the very first time, is probably one of the most unhelpful things in all of life.
I glanced at the article and there are some good tips here, but I really enjoyed seeing an actual hit counter at the bottom. :) Love the throwback to a simpler web, even though this one is surely much more complicated under the hood.
My latest way of learning a new programing language quickly is to actually understand how to read and navigate the API/Documentation properly, followed by learning compiler/interpreter error messages and what they mean. Understanding the syntax sorts itself out through sitting down and commencing coding something... It's not something I will directly study in a book.
A good summary including many of the common techniques of how to learn something. One of the things I always ask myself at the beginning is why. I might see something that is interesting and get temporarily motivated to do it, but if I stop myself and ask why, I'll often discover I'm just riding someone else's interest.
Where I tend to get stuck is somewhere between the “make something similar to tic-tac-toe, like bingo” and “make a level editor for beat saber”.<p>It’s a difference both in scale, and in divergence from the known. While I’ve built large systems for work, it’s usually on the scale of ~1000 development hours and 10-100k+ LOC. Most of my personal projects are basically toys, a few hundred LOC and do-able in an afternoon. I’d like to be able to build medium-scale things without dedicating a significant chunk of my life to them.<p>The other facet, divergence from the known, is the other sticking point. Given a tic-tac-toe board it’s pretty obvious how to build bingo. I don’t even know what I don’t know about how to build a 3D editor, so it’s hard to get started. (I have this problem with math, too; since so many concepts build on each other, it’s hard to jump in and do something interesting.)
Nice article! Also consider reading a book <i>after</i> you've got some practice. Things will make much more sense than if you do it without prior experience and you'll get much more in depth understanding of the subject.
I greatly prefer books over videos when it comes to learning programming topics.<p>I'm always disappointed when I am directed to a video, rather than text, when I'm searching for a particular topic.<p>It takes a long time to seek to what you want, and you're forced to learn at the speed of the presenter, rather than your own speed, as with text.<p>I also find it easier to learn things offline. I had to get up and running with the Spring Framework quickly, and what worked was putting the documentation onto the Kindle.
Thanks for the insights. I followed one of your links, namely your link to DEV (0). And found this guy's work (1) where he publicly details working through "Eloquent Javascript". Useful.
(0)<a href="https://dev.to/" rel="nofollow">https://dev.to/</a>
(1)<a href="https://dev.to/prerana1821" rel="nofollow">https://dev.to/prerana1821</a>
One thing that has helped me to learn better is not immediately ask for help but try to solve it on your own. While it might not be possible for everything, trying to solve on problem by yourself in a day goes a long way.<p>For example in programming, when I stumble on a problem, not immediately going to SO for an answer but thinking about it for a while has helped me to learn better.
Focus on the high level abstraction<p>When learning something new, I’ve found it’s helpful to hear the top experts engaging with one-another about the topic. Not to hear what they think, but to hear how they think, and in particular, the level of abstraction in which they’re working.
Speed is not usually a problem, at least for me. The real problem is _retention_. That is, specifically, being able to recall what I learned if I stop using it regularly for as little as even a couple of months. If anyone has some _real_ tips on how to improve that, please share.