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 to sketch things out, read articles, or watch videos.
My question is: if you have a topic you want to learn, and you want to know everything there is to know about it, and gain a deep knowledge and understanding of it, where do you start? What is your process?
I find that some articles I'm reading are relatively opinionated, or not written with beginners in mind. They can sometimes skip over the structure/architecture of a project and why it is this way. Video tutorials are good but make me follow an example project, which I can't always apply to my own work.
I suspect it really is just 'trial and error' and building up that understanding over time. But I'm just curious. I'm fascinated by people who can tell me how and why things work, when often I feel like I just 'know enough to do the job'.
It's hard to explain but it's not so much about writing the code, or the syntax. It's the overall concept of how things tie together and why things are done in a certain way.
Top comments (21)
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.