Everyone has different ways of learning, and I've read a few interesting articles on here about it. Some people are very visual learners, some like...
For further actions, you may consider blocking this person and/or reporting abuse
If you want to know more about how to learn effectively, check out The Learning Scientists podcast. They discuss learning techniques and the science that informs and supports them. I started to apply some of those techniques while I was in uni and they made a huge difference. As an example, I used to dread exams that required short-essay answers. I just couldn't recall enough detail about topics to write something coherent under exam conditions. But after practicing a few learning techniques it became so much easier (specifically retrieval practice, elaboration, and dual coding, but see that last link for articles about 3 more techniques that are also important)
So my process involves finding the highest quality material I can (code, docs, web articles, books, research papers, whatever), and repeatedly studying it, noting questions whenever something doesn't quite make sense and trying to answer them when I've finished reading the article/doc/book/code/etc. Sometimes answering a question will involve more reading, but sometimes it will involve doing an experiment (e.g., writing some code and then changing it so see what happens, i.e., trial and error).
As I find answers to my questions I again read the material that prompted the question to see if my new understanding provides more insight into anything I might have misunderstood before.
I also takes notes as I go (in markdown), building up an outline of the topic and filling in specific details. I'll use those details to create flash cards (using Anki) that I use for retrieval practice.
This might seem like overkill if you just want to learn how to use a new framework, but I do it for anything complex that I really want to understand well. It's how I learn about large software projects that I work on and it's allowed me to quickly learn as much as some people who've been working on it for years.
Thank you so much for this! I will check out the podcast/techniques you mentioned, sounds interesting :)
Meta comment: You are asking exactly the right questions. A decent mentor would be ecstatic to have the opportunity to guide you.
To answer your question, I primarily google it. I will spend an exorbitant amount of time reading posts, watching talks, etc. However, the key for this to work is to develop a "filter" for knowing when the content is not going to answer the precise question you have. Then just skip it and move on to the next one.
Once you have a hint of understanding, then it is time for practice. A solid understanding by research alone is ideal, but I don't find this to be achievable in many cases. Even research scientists do experiments.
I usually end up practicing on working code that I already know. Then I live with it for a while to see what falls out -- what becomes harder and what becomes easier. Some tactics are just bad for general use, but usually every one has a trade-off. The trick is to find the one with negative trade-offs that have little-to-no impact for your situation, so the net gain is positive.
"A solid understanding by research alone is ideal, but I don't find this to be achievable in many cases". This was a beautiful way of putting it. True in everything in life.
Mental load is a scarce resource, so knowing 'just enough' can be a skill. The big trick is of course to be/remain aware of what you don't know, so you can recognize when you need to acquire additional knowledge or understanding.
In my opinion, and experience from working with a lot of different people, I usually start out by making assumptions on the overall architecture and model based on talks/briefing. Most of the time that's enough to get you started for a while, until one of those assumptions get debunked thanks to code displaying a different implementation of the model or architecture and it's back yo yhe drawing board for context etc.
In the ideal world, code shows intent and by looking at folders, files and naming you get an understanding of how it all fits together what who does what. Unfortunately, reality has its say here and dares to throw that around.
Even in high performing and clean code type of teams can this be the case, so I don't feel as if we could have a better way to tackle this. You start, revisit, go again. Rinse and repeat.
Thanks for replying!
Yeah that sounds like the only option really, try things and see if they work. I just find it hard not knowing if what I'm doing is 'right' or not - especially when working alone.
Maybe it's a good idea to share the work more and get more people's opinions/perspectives.
That's always a good idea. One of the reasons I open source my work.
For me, I normally go to the official documentation, I personally use the Android documentation for my learning. If I'm not satisfied with the documentation, I go to articles on some of my bookmarked websites. Explaining difficult topics in ways that people understand isn't so easy, so I take note when I see a blogs/websites that do it well.
Sometimes reading the documentation might not help initially, like I remember reading different articles about RxJava but I still couldn't get it. It was a conference video I watched that really made me understand it, from there I could now go to the documentation and continue learning since I understood the basics.
So yes, sometimes videos help, you could follow the video, develop a project and then tweak it to see how it responds, that could help you understand how it works.
After understanding the basics about a topic, with the help of documentation, blogs or videos, and I want to have a deeper understanding of it, I normally go on to read more in the documentation.
Every piece of software (framework, lib, language etc.) is a solution to some problem. If you are learning new software start with understanding of the problem the software is designed to solve. The problem gives meaning to a solution and lets you see why it is done this way. Many times you will see where the solution is not optimal and how it can be improved or where the solution is really smart and beautiful. Also it helps after understanding the problem to first think for a while how you would solve the problem yourself.
The best way I've found to learn is to do a project in that particular language or framework. I try to use an Agile method where I define an Epic, User Stories and Tasks and work my way through it. This would also include Spikes to learn particular aspects.
Beyond that, it's just a matter of applying basic design principles while coding, things like SOLID (if it's a OOP language), DRY and YAGNI.
Try adding features to the codebase is also a way to get more insight into the codebase itself.
Is it flexible enough to easily add/change features ?
Is it performant enough for current feature ?
Is there better way to improve it ?
You will get even more questions alongside with more features added.
Good advice. Also valuable for more experienced developers who joined a new team/company and need to develop their understanding of the codebase. Try to write unit or integration tests to reproduce known bugs. How easy it will be? What will you need to know to reproduce user actions programmatically?
Thanks for this!
My process is as follows, start from shallow and move into the deep end.
number 5 I found to be very critical in finding 3 books because it gives 3 perspectives on the topic typically from very experienced authors.
Thanks for this!
Probably late to the party but just wanted to add my 2 cents in this great ocean of advices.
I usually swim in shallow waters with "just enough" understanding to get the job done. Sometimes the tasks at hand will pull you in to more deep waters where you have to learn more in order to do the work. That is when reading the documentation properly (or other great tutorials material on the subject) come in handy. Of course if its coding that we are talking about it greatly helps to be accustomed to using a debugger so you can see deep in your code.
Most probably people you see having deep knowledge are people that their assignments/work forced them to dive deep and understand the concepts in order to deliver.
The problem with reading is people stop when they reach a point where lot of things they don't understand. This is the lost opportunity. Because by keep reading, they would be able to build a list of vocabularies that later on can help them to connect the dots. It also help them in forming the questions to ask other experts. Quite often, when meeting these people, they don't know what to ask, which again another lost opportunity. I'm still struggle on building the questions part :P
The single best way of learning is when you "depend" on the project you are building. Which means you will learn things very quickly when you have some stake in the outcome.
From a drastic point of view: Build a StartUp with just that new technology or code/pattern.
Since this is not highly recommended except you are rich and don't need income, maybe choose a problem you solve for yourself or a friend. It is important to get excited about it.
And then build it and read blog posts/articles along the way. There you will also identify quite quickly what works and what is just bulls*t.
Humans learn the fastest when their life or outcome depend on it. Use this concept in a reduced way and build something you want to present at a MeetUp or a tool you want to publish in a month or so.
What works best for me is to start a list of ideas in my day-to-day life (a bookmarking service I can use from the terminal, a desktop push notifcation service when there is a new good article or podcast out etc. etc.). Collect them for a few weeks or months. Also collect the concepts/programming languages you want to learn.
After both lists are long enough and some time passed, pick the technology you still really want to dig deeper on a project you still want to have.
Nice article! I always found a "top down, bottom up" approach to learning new things speeds up my comprehension of things. Top down as in the theory/history/idea, bottom up being the implementation of said theory.
I totally agree it's not necessarily writing the code or the syntax. Once you know what it is you need to achieve, you can always look the nuance of things up.
It's all practice at the end of the day :)
I resume the answer in two words: how? and why? For me are the base for deeper understanding.