- Do you focus on one topic/book/course/project/article at a time, or split your time between multiple things?
- Do you use any tools to track your resources, todos, notes, or goals?
- Are there any pain points you have while learning, or are there any tools you wish existed?
A customer called me at 5 pm. They had a possible six figure hardware sale, but a key aspect of their hardware was too slow, their only embedded software/hardware guy was no longer working there, and they had to have the new code in 24 hours for a demo.
The software component to be sped up was three cores running handwritten assembly, and had been optimized by several people over four years.
The total of my embedded software experience was fooling around with an Arduino. I'd never written assembler before and never see this processor or its family before.
This was going to be good.
I wrote down the problem, and did the math to find out what the solution would have to look like.
It's hugely important to define the problem, and constrain the solution as much as possible. Nailing these down is probably the single most important "trick" problem solving.
With the problem defined, and the solution constrained, I printed the entire processor manual, and read/scanned it through in one sitting. I then went back over the memory and instruction timing sections, since that was going to be the hardest part.
I at least, learn much better by first scanning through a paper book on a subject. This lets you get the big picture all in your head at once, and see how things connect. Unlike just reading an overview, you also get to see the hard details that make up the way the system works. Then go back through later for the sections that matter for the problem you are working on.
I hooked up the customers hardware to the computer, flashed code the existing code to it, then changed the code to turn a status LED off. This was just to verify that I had the code to hardware toolchain working.
I've learned to bite off a small piece at a time, and then build up, rather than trying to solve everything at one go. The first code I ran on the processor just changed a status LED. This let me focus on as small of a chunk as possible, and deal with getting the new IDE configured, etc, without having to worry about the whole class of problems that would come from running my new algo.
I know I need X amount of sleep to solve problems. Even with a crazy deadline, knew I'd do still come out ahead. I went to bed at my usual time.
When I woke up, I knew how to solve the problem. The solution was similar to drawing a diagonal line on a computer screen - which is a really easy problem.
I've found that you can think in your sleep. Maybe this is just me again, but I've learned that as long as I clearly layout a problem, solution, and tools before I sleep, I wake up with the answer. I don't even wonder anymore if it's going to happen. Perhaps this is just the result of a lot of experience, but it never fails. If I'm stuck on something during the day, I just take a shower or a nap and know the answer afterwords.
In optimization, the algorithm usually matters far more than anything else. It wasn't that I was the king of assembly language programmers, it was just that I was doing an entirely different thing than the previous programmers had been optimizing. I started with "what would the ideal solution to this problem be", and they started with "let's translate a hardware concept to software".
The second biggest trick to working with a new problem is visualization. I've learned that I can hugely increase my speed of understanding by building tools to visualize the problem and what my code is doing to solve it. For example in the recent, awesome, Halite programming competition, I built a tool that would let me output annotated html5 game maps and documents from within my code. Here's an example visualization output, straight from source code http://braino.org/thoughts/halite_the_simple_way.html
OODA loops really do matter, and really are constrained by how much you can see how fast.
After breakfast, I worked out the assembly instructions I'd need, tracking the timing and register values on graph paper. I read up carefully in the docs on each instruction I'd need.
By lunch time I had a paper version that should work, and by 3pm I had it running in the product and had learned how to use an oscilloscope. The customer picked up the hardware and got the sale. The new version used one core instead of three and was measurably, literally ten thousand times improved.
I was now a carded member of the Real Programmers Society.
- This is something that occurs to me too, which is why I always scribble the hardest problem I have at hand before I sleep every night. Does wonders. :)
Problem solving is a great way to learn quickly but make sure you stay around the subject to understand and acquire knowledge for the long term.
I don't have the time to put these in any coherent order, so I'll just list some:
- Bookmarks. I find much of my information online. I make aggressive use of tags, and I found that organizing them into folders is too difficult and a waste of time (unless grouping them for a project/talk temporarily); the tree structure doesn't lend itself well to a graph of concepts. I have ~10k bookmarks. I keep them; you never know when they'll come in handy, even if only for trivia. Figuring out what tags are appropriate forces me to extract key material.
- Maintain a reading list/backlog. I have short, medium, and long-term lists. Go through them on occasion and re-order them by interest/importance. Remove ones you know you won't have time for.
- Learn to speed read. I find it difficult on a screen, but easy on paper.
- Hands-on experience: if you're programming, go hack on your favorite project, look at bug reports, or write your own. Struggle through problems before you give up and look online.
- My time is split between many things. I use Org mode to organize my thoughts and agenda. Sometimes I can do the entire project in Org mode (e.g. https://mikegerwitz.com/projects/sapsf/tree/slides.org, but I left my time tracking private). It also integrates with my mail client (Gnus), where I live a good chunk of my life outside of work.
- While I read many articles and blogs and stuff online, for any in-depth material, I buy the book or print the paper and read offline. I have a system with 5 different color pens that I use to aggressively mark up and underline (blue general concepts, red a problem, green a solution, purple a technical detail, black misc.). I have a Bamboo tablet, but I still prefer paper.
- As I mentioned in another one of my comments (and as adamnemecek mentioned), read a book multiple times (http://pne.people.si.umich.edu/PDF/howtoread.pdf). It not only helps with absorbing the information and selecting what is important to you for further study (which is important given limited time), but also helps if you can't often finish books; after a few iterations, you'll have a good idea on all of the concepts and know _what information exists_ and _where to find it later_ when you actually need it. Discovery is the most important (thus my bookmarks)---material is always there to reference.
- I don't have time to watch videos---I prefer transcripts, which I can also search through. If I do need to watch a video (either because it explains a concept better or because there is no alternative), I watch it at 2--2.5x and slow down when I get to something I'm having trouble keeping up with. Some people talk slowly even at 2x. :x
- Get rid of distractions. One of the best things I did was create an agenda in Org mode, because once I complete a daily task (e.g. reading news sites; checking mail; checking GNU Social), I _stop_ and move onto another task. No peering at my e-mail or news sites 20 times while I'm doing another task.
- Similar to the previous: I only work on personal things at night. I have a family, and I want to spend time with them---I feel guilty if I work during the day when the kids want to play, and all the noise is a distraction; it breaks flow constantly. Wait until a calm point.
- Iterate over your system. Everything I do has evolved over the course of many years. The learning curve for some tools will slow you down, but can be very rewarding. The iterative process can slow you down. But that's not always the point: a good system can have returns in the long run, but it also _reduces stress_; you want to enjoy learning, enjoy the tasks you're doing, and not have to worry about other things. This might involve writing scripts, too.
I have more things, but that'll have to do for now.
1. bookmarks: pinboard.in / chrome plugin, add bookmark - add any relevant tags
2. backlog: todoist.com with tagging
3. speed read: beelinereader.com / found this to be useful but didnt use that often
4. reading offline: kindle
5. watching videos faster: video speed controller from chrome store
This approach has the advantage that it lets you decide what's important. I also like to believe that it establishes better connections between the single ideas.
I would say that goals are counterproductive until you are somewhat comfortable but not when starting out. Like yeah sure, you should make some progress but you are in an uncharted territory, the best thing you can do is to walk around a bit and make sure you stay engaged.
If you move to a new city, you probably walk around the neighborhood for a bit, then to the neighborhood next to yours etc etc.
I find it valuable for another reason: I'm always constrained for time, so I might not get through an entire book. If that book is deeply technical, it discourages me from continuing, because I have to take the time to re-skim what was read previously.
I somewhat recently started trying the above method. With multiple iterations through the book, I can get an idea of the information and at the very least know where it find it and that it exists. Depending on the iteration, I'll have some notes to fall back on, or have some important concepts underlined.
Those are good, but you should also watch professionals use the tools on really complicated projects in person or in screencasts. While you won't be able to follow along fast enough and will be in way over your head, you will learn what's possible and be able to remember in the future when you run into a problem that needs complex radial symmetry, or whatever, that there a way that is much faster.
It also broadens your notion of what is possible in the application, rather than trying to reason from the ground up of the simple tools you have learned in a beginner tutorial.
> it is like throwing mud to the wall hoping that it sticks
I must have not explained it well because that's the exact opposite of what I'm talking about. It's not about what sticks, it's about creating the connect-the-dots
> It's much more effective to focus on each topic and try to remember and repeat the informations just read.
Effective for what? Assuming that a neural net is a good approximation of the human learning model, why do nns tend to be be trained over multiple epochs?
You're not reading a book five times, cover to cover. That's not a productive use of your time. Instead, you should breeze through the table of contents. Skim the first chapter. Still interested? Skip to the last chapter and read that. Jump around to the parts that interest you. Read through it again with a broad outline of what you're reading. Encounter a boring section? Skip ahead by twenty pages or drop the book altogether.
This is the best strategy for reading books for knowledge, and not just to say you've read a certain book.
My tip is to make sure you understand the subject. By putting it in your own words. A problem with reading is that it's easy to fool ourselves into thinking that we know something when in reality we don't. We need to constantly test ourselves.
It also describes the next step "analytical reading" which comprises of mostly asking questions about the topic in general and about the author's intent.
How do you fast read it? It's more like skimming it rather than actually understanding it. It would be frustrating for me, I'm more like a perfectionist who hates to leave behind not understood paragraphs. The idea is neat though, I lean the same way, but it's not true how I read books.
I have two learning modes. When I first come across a new topic, e.g. hadoop, I will go broad and skim as many learning materials as I can to get an idea of the lay of the land. Once I feel confident I have a handle on the major parts and technologies involved, I'll switch to the second learning mode and work through the subjects / technologies one by one by searching online for "best way to learn X", figuring out what the common denominator is, and then working my way through that while taking notes in onenote.
The note-taking is crucial for retention as well as keeping track of salient points (it's all in a onenote notebook, so I can find something relevant again even if I don't recall the particular book it was in).
What I wish existed was a sort of wikipedia for learning, keeping track of every subject / technology and giving a reference to the best learning materials in a crowd-sourced way. Right now learning sites focus on their own content, but it's not always the best, and it is not crowd-sourced. The best hits for learning resources are usually stackoverflow or quora links, but neither are the right format for such a thing.
This. A friend of mine (senior sysadmin on a different team) has ranted about how his boss put tasks like "Learn Docker" in his list of goals for the year. First, such a task is hilariously underdefined. Second, if you're not going to apply the knowledge, it will be forgotten within a few weeks, and time spent studying it will be wasted.
I write (private) wiki pages for myself when learning a new tool or tech. However, I think the process of taking in information and rewriting it in my own words is more valuable than the wiki pages themselves. Plus it's a handy way to store relevant links and brush up on a topic if I don't engage with it for awhile.
The common thread in both is mastering the foundations. I know this is controversial, but I believe in book learning before playing whack-a-mole around the internet, simply because you aren't at the point where you can differentiate the signal from the noise.
After the foundations, I learn on a need-to-know basis, which is generally more applicative: if you are trying something that's never been done before, then the perspective is top-down instead of bottom-up.
I don't use notes, todos, online tracking, or whatever goal-oriented resources people are using. I don't see learning as a goal-oriented exercise so much as an accidental accumulation of knowledge. Knowledge gained best from a genuine interest in the subject at hand, which often leads into a genuine struggle to learn some topic, either because it is genuinely difficult or it something you find boring but necessary to learn to continue.
I'm an autodidact, and really, the best advice I can give is learn yourself first. Be absolutely honest with yourself about your interests, your limitations, and the answers, via a long journey of trial and error, will eventually come to you. The fact is, we aren't all able to fit into a mold, and no matter how much advice you read... advice reading is pretty much worthless without a grounding on failure.
Add text and images quickly, so you can type along with a lecture, or by copying and pasting text, html or pdf from documents you are reading. At the same time it must be easy to add and scale images.
Tidy up and restructure your note. Just typing your notes is not enough. You also need to think about it, and restructuring or tidying up your notes is a great way to do that. The tool you use should not make you redo or rewrite the notes completely. It should just be click and dragging without messing up the formatting.
Show structure in multiple ways (colors, sizes, shapes, connections etc). Making notes in a text editor is limited. You need something that does not just scroll up and down, but also left and right. Something that looks more like a diagram or a mindmap, to which you can also add connections, labels, arrows, and colors. Having notes that look more like infographics helps me alot to remember or retrieve what is in them.
Have overview and detail in the same map without to much clutter. I myself like having notes on a topic in one document, but it must still be easy to show the structure and the details.
I am pretty pleased about how all this works in Breakdown Notes (my project). If you would like to check it out I suggest you take a look at an example map about english grammar:
I pick a project that interests me at some point; currently "I'd like to have an internet music player that sits on my cupboard and doesn't require my tablet".
* decide on platform (CC3200, because it has wifi, enough processing power,
and I happened to have one)
* build something that decodes an MP3 stream (investigate, pick Helix as the decoder,
make it run on the CC)
* think about hardware (DAC, amplifier)
* think about enclosure (wood, how to do front panel)
For tracking my progress, I've started to use Emacs org mode.
The key is that I must have something I want to accomplish as a reason to learn something new. For instance, if I just decide to learn a new programming language, I will lose interest very quickly. But if I decide I wan't to create a new app, I can then use that same programming language for the job and I will consume every information I can in order to make it happen. Usually using google and youtube to find the resources. I start from the basic I need to start and go on from there.
I've used that method to learn new programming languages, surf fishing, technical analysis/investments in the stock market, grow plants, electronics, cooking, etc.
TLDR; focusing on a project makes it easier to learn as you need the information in order to make it happen
For me, I deliberately split across multiple topics/books because my brain has different thresholds of concentration depending on time of day. The early mornings are best for more challenging subjects (e.g. math, deep learning algorithms, etc). At night, it's easier to read softer topics like history and politics. I think it's important to pay attention to your brain's energy levels and when/how it gets distracted. With that knowledge, you optimize your learning schedule around that.
>- Do you use any tools to track your resources, todos, notes, or goals?
Since learning time is finite, I think it's a important to put together a little curriculum of all the topics you want to learn. Prioritize them.
>Are there any pain points you have while learning
Another piece of advice that nobody ever seems to emphasize (but I wish I had known early in life) is that there are topics that will be a waste of time to learn. In my case, I regret I spent hours on PowerBuilder, IBM DB2, and DOS batch scripting with VBScript. It doesn't mean those skills are bad for others but a little research would have made me realize there were other more important skills to spend precious hours on. (Time spent learning X is time not spent on learning Y.) The tldr is that people will often evangelize things for you to learn that you really don't need to learn. They have good intentions with their advice but they don't know the complete picture of your life's goals.
For casual learning, I split my time across various subjects and do whatever feels interesting. For serious learning like a certification, I set goals based on e.g. time spent studying.
I use plain text files, either a single file or a folder full of them. I try to develop a sort of learning system for the subject in question.
> Pain points
I was too reliant on outside sources before and did not spend enough time creating "my own" knowledge through hypothesis, testing, measuring, etc. Nowadays I realize I have very little need for most of my books; it's more fun to see what I can come up with on my own.
I also wrote up a "learning ladder" that ranks various forms of study; for example before opening a book or a browser tab on a topic I will check to see if there's a short YouTube video available. After that I might look for an ELI5 on Reddit. Then eventually you get to books.
While that may seem obvious, it represents my taking responsibility for my own learning and I am a more motivated person because I created the ladder by myself and continually work on it. I have hundreds of these systems in areas from learning to fitness to work operations to finances, etc. When I go on vacation it's the #1 "book" I enjoy reading and pondering (I save all the .md files to Dropbox for reading on my phone).
Any time you find some thing you want to learn - add a card to Anki. Anki will make sure you never forget and truly understand the topic.
I highly recommend AnkiApp: https://www.ankiapp.com
Here's the approach I use:
- Every time you come across a new term or concept, you create a new "notebook"/document. That's right, one notebook per concept. The title of the notebook is the name of the concept.
- You create a summary for the concept using bullet points. What you're trying to maximize with this set of bullet points is the speed at which, in the future, you can re-read them and achieve a similar brain state to what you had when you originally learned the concept.
- You can then obviously have extended notes below that where you go into more detail.
- Then, crucially, you create something akin to a regex that will allow you to quickly and unambiguously look the concept up in the future. If you just learned what a rectified linear unit is, your pattern might simply be:
rlu | (rectified linear unit)
- You then have a hotkey on your computer -- I use Ctrl-Q, that brings up a text box where you can type the name of the concept you want to bring up (ex. "rlu"). When you press ENTER, it doesn't give you search results if there's an exact match, but instead directly opens the document and makes it instantly viewable / editable.
- As your concept graph starts to grow, you have links within your notebooks to related concepts as they're referenced.
- Each time you read an article that is important to your understanding of a concept, you quickly open up that notebook and add that article, and perhaps one or two bullet points that contain the key things you learned that expanded your sense of that concept.
- This same system can be used for more than learning text book information. You can use it if your a project manager to keep tabs on the millions of things you have to juggle, you can have notebooks for people, for lists, and you can have "regexes" for "programs"/scripts, for web pages, for files/directories, etc, etc.
- More general than "regexes" are context free grammars. In this context what that means is the ability to have named "subroutines" for your regexes. For example, if you end up using RLU as a sub-part of a lot of other notebook regexes, then you might define $rlu to be a short form for (rlu | (rectified linear unit)).
I warmly recommend Pragmatic Thinking and Learning by Andy Hunt and Alex Martelli’s lecture “Good Enough is Good Enough!” from EuroPython 2013: https://www.youtube.com/watch?v=gHG9FRSlPxw
More notes on learning: https://www.simongriffee.com/what/learning/
If you don't use Anki - you really, really should. I'd be lost without it - it's one of the greatest life-hacks I have. Without it, I don't really feel like I've learned something "for life", only just for a moment.
Also, reading multiple textbooks on the same topic is in general much better than just reading one, preferably in slightly increasing complexity.
Gwern calculated the total time spent reviewing the average card is 2 mins across your lifespan (https://www.gwern.net/Spaced%20 repetition) - so anything worth ~3mins investment to learn can go in Anki and you'll never forget it. It's magic.
It's also an amazingly designed piece of software in terms of functionality, even if it does have a bit of a learning curve.
Honestly, my only complaint is that I can't figure out how to give them money! I'd love to donate to them but can't seem to :(
As for learning I usually mind map concepts I thought were interesting and then review the mind maps and create flash cards. It depends on the content however.
If it is something actionable like learning a programming language, I try to use the knowledge straightaway and build things. :)
Prior to learning a new topic, I try to make mind/concept map of the material based on my initial understanding from reading articles or browsing books, docs and examples. It also helps to have an end goal or project in mind to connect concepts to actual outcomes. You can also try explaining what you just learned to a non-technical person; forcing you to "make sense" of a concept while converting to non-technical jargon.
Overall, it just takes time. After years as an autodidact, I haven't found many short cuts around hard work. There are many great techniques out there--some will work for you and others won't--but consistent practice is usually the underlying theme.
2. Try it.
3. Reflect on what went wrong.
4. Go to 1.
Sometimes I don't have a project to work on, but I'm interested in something. For these things I'll push to use on new projects at my company, and will read a book or two about them prior to convincing people its a good idea. This isn't always ideal because the knowledge doesn't really stick without applying it to projects, but it scratches my itch to a certain extent.
I find that if I read three books by different authors on let's say React for example, which are all meant to cover the basics, I learn much more than by reading one book three times. The difference in the authors voices and inevitable variability of emphasis and style throughout, really helps me stay engaged and pick up the things I might have missed in the last book.
I'll usually do this first, then move on to tutorials and deep dive type books which are mostly a breeze by the time I get to them because of the very solid fundamental foundation provided by the initial book set.
[ ] Define a subject, and a goal
[ ] Get resources
[ ] Create a topic list
[ ] Filter the resources and assign resources to the topic list
[ ] Think about possible projects
- For each topic
[ ] Collect data in a reference note
[ ] Create flashcards
[ ] Search and create questions / exercises
[ ] Explain the subject in a piece of paper (Feynman's technique)
[ ] Apply the knowledge in quizzes and practical projects
[ ] With notes, explanation, quizzes and flashcards create a KL
> I focus on topics, not resources. But I split my time into multiple disciplines.
> Yes. Evernote(Premium)
> Yes, a good markdown 'platform' compatible with Linux/Windows/Android
1. try to find a overarching synopsis of the main topic or goal. This can be done by looking at a summary article or by skimming the summaries of a textbook or by checking an expanded table of contents
2. Extract major topics and write these on a spreadsheet/graphical program/(giant) index card/ paper. If you used index cards or a graphical program or index cards try to discern dependencies between these topics by using the gui tools or simply laying out index cards on the ground.
3. Find resources that explain the topics. The resources do not need to be from the same resource. One source can explain topics a,b,c well but not d. You can use another resource for topic d.
4. map projects to topics: extremely important. After finding out the topics and associated resources, you should be able to come up with applications of the topics. These could be as simple as solving problems from a textbook or they can be grand like building a motorcycle (actually, that's too grand). Keep the primary goal to be learning the topics you set out to learn or completing your goal.
5. execute the projects
6. check off topics as you encounter them
7. reflect on the results of the project or application
8. if you encounter difficulties find more resources and drill down on topics you found interesting or challenging.
Not perfect, but its working well for me. You can start from practical applications or theoretical concepts. Books are great because they contain a structured approach to a topic. ALWAYS MAKE SURE THE BOOK HAS PROBLEMS THAT HAVE (some)ANSWERS!! You should be able to do quick knowledge checks.
topic based learning is more difficult and I feel like it's like making your own sandwich vs buying a prepackaged one.
While learning, I try to split off a little piece of myself into a sort of adversary, whose job it is to get me to do basic problems / tasks, in order to demonstrate that I don't remember as much as I think I do.
This might happen in the form of spending an hour one morning leafing through older material, and setting aside things for me to solve / re-prove. It's pretty simple, and I take some kind of perverse joy in finding areas where I thought I would remember much better.
For noob stuff, I make and quiz myself with physical cue cards. The act of writing the card and the answer seems to be 75% of the memorisation i need but i forget quickly... related to that, i write myself 'guides' that I wish i had read weeks/months before when i didn't know anything. something about writing the subject down as if i'm teaching it let's me anchor the beginning at a level that i can treat as a given and then baby steps all the way to the end. it's a bit Feynman-ish in that it really does force you to acknowledge when you're skipping over something and just rote-memorising.
Also, treat black boxes as a known unknown that you can always go back to. You often have to link up a dozen black boxes to get anywhere and if you go down each rabbit hole, you'll never get to the end. Better to play with them, get a feel for how they are behaving and dive in if/when they aren't doing as expected.
Quiz yourself. After a while it gets quite relaxing to glide over problems that stumped you when you first thought your should write them down. helps remind you that you _are_ learning.
Lot's of books/articles etc covering the same topic and re-reading them. You're different each time and you never know when you are _ready_ to learn that particular thing.
There is also a book called "Cognitive Productivity" by a professor at Simon Fraser university I recommend you check out.
Sadly there is not a lot on this subject. A good example of this is the fact that right now, the only traditionally published book on this topic is literally called "How To Read" and was published in the 1940's.
- - - - -
To directly answer the question though, you should:
1. Read a book and use a pen instead of a highlighter. This allows you to not only underline but also write in the margins insights
2. Type up your raw notes
3. Take your raw notes and the synthesize them into a higher level summary of the main points
4. THEN, THE MOST IMPORTANT STEP, take your synthesized notes and create a "concept map" of them, something visual. Mind Maps are a good example of this, but they're only 1 type of concept map. This is extraordinarily easy to remember, and ideally you want to create a visual diagram for each book you read. These pictures or patterns are incredibly easy (comparably) to store in long term memory than recalling say 3 pages of notes. Also they are far easier to draw and convey to another person.
Here it is:
This means I need to understand the theory first and work down to practical examples (many people learn the other way around but not me). I need to understand how one set of abstractions or theories connects to others that I may understand better. I like to go back to origins, understand motivations, follow the evolution, and see what paths are thought to be dead ends (like machine learning was thought to be a dead end by many people around 2005). I only really understand things if I write them down and preferably write about them. I learn best when I learn with other people, my wife jokes that when I want to learn something I start a company.
Given my learning style, yes, I need to be learning several things in parallel, helps with the connections. I also tend to read too quickly so having three or so learning themes at any time helps me to slow down and reflect.
I have been tracking my learning in granular detail for about ten years using Excel. I am also tracking it on TeamFit.co Every year I build a learning plan (goals, resources, evidence) and track against that.
Usually, I want to learn something because I want to do something with that knowledge. So as an example, if I wanted to develop an app on a platform or in a language I have never used before, I would start by reading some general knowledge about the language or platform, to get my mind going. Maybe grabbing a book or finding some good online basic tutorials. I usually never finish the books, because I often get to a point where I understand enough to start asking specific questions that I need answered in order to make progress on my project. So I stop with the general knowledge, as I have enough understanding to actually start implementing things, and I start researching the specific questions I have for making progress on my app. And I just start executing and working on it, and researching answers as I go. This way, I learn as I go, and I keep myself motivated by actually having deliverables at the end of each "lesson" I set for myself.
If I get no answers, I usually grind away at the problem until I lose interest, can ask a better question, or make enough progress that I can answer my own question.
Useful answers include offering:
- a suggestion to use alternative solution with acceptable trade-offs
- a different approach to how I solve my problem
- a specific answer to the question I asked
- to collaborate with me in finding a solution
- a supportive comment (the cutting edge can be lonely!)
- understanding about a trade-off or consequence of how I am approaching the problem
- a suggestion on improving the quality of the question
- a referral to someone who knows the answer
I split my time between multiple topics, generally aiming for variety over depth, and collect recommendations for books / speakers from various places (friends, Hacker News, the evening news, etc).
I've found that having multiple simultanous books or project s is helpful, because they can interact in interesting ways E.g. one author has accidental insight into the topic of a second book, for instance, or a footnote to a problem in one project solves a major problem for the other project.
There is a difference between knowing that, and knowing how.
When you want to learn that something is the case, read.*
When you want to learn how something is done, do.
If you want to learn how to do something, and you are not doing the thing, then you might find yourself not learning.
* You can take notes, summarize, and repeat.
What has worked for me is having multiple periods of immersion into a concept or topic, while referring to multiple sources, with notes  summarizing small bits as I learn them. I keep refactoring those notes as my understanding grows, to include coherent maps of larger and larger chunks. On short time scales, my learning is not measurable, but experience indicates that my understanding grows over time. Looking back, my periods of immersion range from a few hours/days, while I tend to revisit topics every few weeks/months. I guess this falls under the umbrella of spaced repetition methods.
Since my interests and pursuits are very diverse, and I'm seldom "finished" with something, I don't like the psychological weight of todo lists . I maintain lists of interesting stuff , and several hundred browser tabs  but they're mostly not things to be checked off, and languish peacefully for long periods. That said, I'm on the lookout for better knowledge/idea management workflows and software. What I currently use is organically grown, and very messy.
That was for theoretical understanding. Practice helps, for things one "does".
: Venkatesh Rao: A Big Little Idea Called Legibility -- https://www.ribbonfarm.com/2010/07/26/a-big-little-idea-call...
: Markdown files, or scribbles/diagrams on scratch paper
: Scott Hanselman: It's not what you read, it's what you ignore -- https://www.hanselman.com/blog/ItsNotWhatYouReadItsWhatYouIg...
: Zim Wiki notebook -- http://zim-wiki.org/manual/Help/Notebooks.html
: I <3 Firefox and the TabGroups extension
1) Look for verticals/lists of resources. These exist in all fields, awesome-lists are just an engineering example, universities keep lists of open courses, list of book recommendations or lists of open-sourced books.
2) Look for key figures in that field. PhD Researchers, Conference Presenters, TEDx Talkers, Professors, Founders of Companies in that field. Follow their pages/blogs/twitter accounts and ask them what resources do they recommend for beginners. Compile your own vertical of resources based on cross matching the resources here with the ones you found in other verticals.
3) Look for courses, new ones are usually offered on MOOC Platforms, archived ones can be found on university websites. Check the reviews of such courses and pick the most beginner friendly one. Depending on the field, if it's not technical then you will have to look for courses elsewhere, for example: The Great Courses.
By now you should know, roughly, the best resources (Books, Articles and Courses) and how to find more (verticals and people in that field).
4) Learn the terminology. One way to learn the terminology of a field is to pick the book you decided is best to start with using the previous 3 steps, open it and go to the index section, read the index and start googling terms as you come across them, for example: If I am exploring Data Engineering and I come across the word or term "stream processing" then I will start googling that term. Familiarise yourself with as much terms as possible.
5) Commit to reading at least 1 book, going through 1 course and trying to apply as much of what you learned as possible. Technical subjects are the easiest to apply this step to, since you can start a side-project at anytime.
P.S. you can always ask for guidance in this, you don't have to repeat all the steps for all fields, for example, you can submit an "Ask HN" post asking for resources about X topic or a question on a related Subreddit such as: /r/PostgreSQL.
Best of luck!
I focus on the thing that I'm most interested in at the moment. That is rarely an entire book, though I've done that too.
If I feel like I need to take notes to keep track of what's going on, I will do so. I might also leave a note about things I've skipped or glossed over and should want to (re)visit again later.
The biggest pain point is usually scattered information, or information that assumes some background you don't have and doesn't give you enough clues to fill in.
1) Mastery based learning is generally the most effective process (learning each axiom of a topic to 100% before moving onto the harder topic)
2) Spiral based learning is an effective add-on to mastery based to keep you remembering the things you've learned (coming back to a topic just at the point of forgetting keeps you retaining knowledge)
3) The content you learn off of (video, text, etc) has different attributes which may correlate to better transferring of knowledge: Shorter videos, hand-written visuals, enthusiastic voice, have all been shown to correlate with better learning outcomes.
4) The motivation you have for the topic you're learning and how much closer it exists to intrinsic/extrinsic motivation dictates how well you'll absorb a topic. The closer to intrinsic, the more effective learning will be. Project-based learning generally falls into this category: projects that interest you motivate you to learn more.
Now with all of that in mind, to answer your questions:
> Do you focus on one topic/book/course/project/article at a time, or split your time between multiple things?
(1) would suggest that you should not split your time, at least at first, unless you are trying to find a better explanation (3)
> Do you use any tools to track your resources, todos, notes, or goals?
Most of the suggestions sound like meta work. I wouldn't suggest tracking todos so much as perhaps writing down the things you've learned to prove to yourself of (1) mastery or to come back to later for (2) spiraling.
> Are there any pain points you have while learning, or are there any tools you wish existed?
Sounds like you are trying to make a tool to help people learn/track learning at a high, abstract level. Because there is no one right solution to everything because of (3) and (4), whatever tool you create may not actually help anyone unless it's more domain-specific and less abstract.
Persistent effort. Work it out yourself. Don't just read it, think it, play with the concept until you can generate examples and explain them to others.
You can't! That's what makes computer programming so special - no lab needed. Anyone wishing to learn physics or chemistry better have access to a lab sooner or later. That's just the reality of it.
Please? Pretty please? :)
Focusing if the topic I learn is focused itself or not focusing if it's very broad.
For non-development topics (say, math) it's again a mixture of reading books, watching videos, working exercises, etc. And I try to attack problems from multiple angles, by using different books and resources. Just to illustrate with an example:
Last night I started working through How To Prove It by Daniel J. Velleman. I got to the Chapter 1 exercises, and hit a point where I needed to know if a given number was prime or not in order to verify my answer. It was a number larger than the list of primes I have memorized, and I didn't feel like testing all the possible factors by hand, so I just fired up R on my laptop, loaded the matlab library and used the isprime() function.
Later in those same exercises I got to a point where I had an answer, but wasn't sure if it was correct or not, so I just googled until I found a guy's blog where he posted his answers to the same problems. My answer matched his, so I felt fairly confident that it was right (of course, we might have both made the same mistake).
Had I not found that guy's blog, my plan was to post a question to math.stackexchange.com or one of the reddit.com math forums, asking if somebody could verify my answer.
So I started with a book, and eventually used a number of other resources as part of my overall learning experience (a scientific calculator was mixed in there somewhere as well, before I pulled out R).
This might lead one to ask "well, how did you learn R?" First of all, I wouldn't yet rank my R skills very high, but to the extent that I know some R, it was from (again) a mix of sources:
1. A bunch of Coursera classes, including several of the ones in the Johns Hopkins Data Science track, and the Duke "Probability and Statistics with R" track.
2. Working through parts of several R books, including R In Action, Learning R, Using R For Statistics, etc.
3. Trial and error, playing around, using the built-in docs, etc.
That's kinda it. I take notes using pencil and paper, sometimes a plain text file, occasional an OpenOffice Writer document, and sometimes a wiki (I keep a MediaWiki instance running locally).
I find it helpful to type examples as I read too (for programming stuff)
Make anki cards for key points.
If I'm actually dedicating time to studying that's how I do it, haven't had that session in a while though.
1) Read the documentation
2) Sometimes, do a tutorial.
3) Build a small project and ask questions via Twitter/IRC/Slack along the way.
def learn(thing, max_time=0, max_attempts=1):
while run_time < max_time:
while attempts < max_attempts:
attempts =+ 1
if do(thing) = 0
Edit: I don't write code very much, and certainly don't claim to earn my living on it.
- find reliable resource/book to read from.
- read and make notes.
- refer notes to make things stick.