The year was 2017, early Jan or probably Feb. I had recently joined a project and was asked to start working on two major applications. I clearly remember the day – I was at my office desk and was going through code. To give some context to it, that code was completely written by a person who had left the project a few days back. No other team member had ever gone through it until I was given the task. The codebase was all over the place but it was doing the job that it was supposed to do. For me, it was a bit exciting at first when I started refactoring it and rewriting some simple stuff here and there.
Things became chaotic on that day. I was asked to solve a problem requiring me to integrate three tools with it. And with a deadline. Before that, I never had a systematic approach to learning engineering concepts. In fact, I never ever thought about having “any” learning approach at all in the first place. I had always relied only on StackOverflow, a little bit of google search, and a little bit of blog-reading here and there. The main aim being to just get the job done. With the aforementioned event, it became apparent to me that this way of learning things, in an ad hoc manner, is non-adequate and unsustainable in the long run. I realised this because out of those 3 tools, I had worked on a couple of them before. But was not able to recollect anything. To become better at what I do on a daily-to-daily basis as a software engineer – it was clear that I have to commit to a pragmatic approach to learning concepts differently and efficiently. So I adopted one.
Over the years, as I have become more experienced, the approach has taken different forms. I have customised it multiple times according to my need. But more or less the core framework has remained the same. In this article, I will be sharing with you the process and the mindset throughout the process in detail:
The approach is simple to follow and it’s segregated into 5 key phases:
- Selection/Ideating Phase
- Scheduling Phase
- Starting Phase
- Learning and Implementing Phase
- Revision Phase
Selection or Ideating Phase
For me, the selection of a particular engineering topic to learn usually emerges from a few events. One of them and the most common one is when I encounter a practical problem. It may be from my job or my side-project or from my tuition class (I used to teach people before). A problem poses challenges. To overcome them I do a quick google search and note down the concepts that I have to learn to solve them. Before proceeding further, I do a quick check with community/friends/colleagues to know whether they have already faced it. If yes, how did they overcome the problem. If not, how would they approach the problem.
Another reason for zeroing in on a topic is if it is closely related to any other topic that I already know or am learning. For example, if I am learning HTML, I would also put the below topics on my learning radar, if I don’t know already:
What if I get multiple requests from the community on a particular topic? I try my best to answer them as per my knowledge. But the software engineering field is so vast and ever-changing that it is undoubtedly impossible for someone to know maximum things. If I see that it will add value to the community, I give it a try.
I keep a learning backlog document, in the form of a “Kanban board “. From time to time I add topics, revisit the list and pick up a concept from there. It helps me to keep a track of the progress made and also plan for my future learning path. Give it a try.
Sometimes I feel like getting my hands dirty with the trending topics or some new idea that I have. Also, the areas which I feel will become relevant 5-10 years from now. So l learn them whenever I get some bandwidth out of my daily learning schedule. Check out my machine learning blog series (if not done already).
Lastly, the most important concepts that I love learning are the Core Engineering fundamentals. These are most likely to never become obsolete. Think refactoring, networking, clean coding, design principles, design patterns, testability, data structures, algorithms etc.
Once selected, things become a little bit interesting when I try to schedule the selected topics. I add priority tags to each of the topics on my Kanban board. For setting the priority, I follow the “Eisenhower Decision Matrix” and label the topics as:
- Urgent and Important
- Non-urgent and Important
- Urgent and Not important
- Non-urgent and Not important
I then pick up the topic according to its set priority level and put it into the “In-Progress” column on my Kanban board.
Once it is done, I analyse and try to find out the approximate time it would take me to complete learning the topic, only to the point that I want or I need to learn. Sometimes deeper, other times at the surface level. I fill up the “From-Date” and “Due-Date” columns on the board accordingly. When this is also done, the only thing left is to schedule it and just start.
If it is work-related, I also evaluate whether I could learn it during office hours. If not, at what time of the day should I learn it – early morning, mid-morning, afternoon, evening, or at night. I usually avoid learning at night, late-night, when I am overwhelmed with other things or when I feel that my cognitive load is on the higher side.
Take a pause and you can get to realise that too as it is not so difficult to evaluate your current situation.
This phase is probably the most dreaded one. Aristotle rightly said:
“Well begun is half done”
But you don’t always have to start well when it comes to learning. Especially in software engineering, where the most difficult phase is to start. This is true for most software engineers, experienced and non-experienced alike. The approach that I follow to begin learning a concept is as follows:
At first, I do a normal google search on the item and glance over its search results on the first couple of pages. Then I do a casual search on the social media platforms (Youtube, Twitter, LinkedIn) and skim through their search results to see what people are talking about on that subject. These activities help me to put my mind in the correct frame to learn. They also provide me with an initial motivation to participate in meaningful conversations later on when I would have grasped the concepts. If present, I like to read the Wikipedia page on that topic too. It helps me to get a context overview – history, common problems it is solving, competitors, future outlook etc. By the end of this, I would have already assumed how difficult/simple and time-consuming it would be or how deep I need to delve into it. With the required information fed into my brain, it’s time to completely immerse myself into the “Learning and Implementing” phase.
Learning and Implementing Phase
There is nothing fancy in what I do in the “Learning and Implementing” phase. I follow the same route as most experienced or self-taught engineers take. First I either enrol myself on a MOOC (Massive Open Online Course) or search for a YouTube tutorial on the topic. Things which I keep in mind while selecting a course or tutorial are:
- Recommendation from someone
- The channel/instructor
- The number of views, likes, comments or reviews
I simply don’t like to spend time on videos that would provide little to no value in my learning journey.
At first, I target a section in the tutorial. Along with the instructor, I go through each sub-sections inside it. If I know something already, I skip it or play it in the fast-forward mode. While going through the videos, I do the stuff, that the instructor shows, on my machine. Many people wait for all sections to complete before they start doing the hands-on. Probably it works for them, but for me, it doesn’t. I also ensure that I understand the things being taught. I never skip any concept without having an understanding. If that requires me to move at a snail’s pace, that’s fine for me. Side-by-side I take notes from the videos. Taking notes helps me to clear my understanding and act as a future reference which helps me in revision (more on this in the next section). It’s not an exaggeration when I say that my machine is full of such learning notes.
At the end of each section, I go through the notes and try to experiment with some hands-on that were not shown in the videos. This activity helps me to solidify my understanding of the concepts. If I get stuck somewhere, often I open the official documentation (if it’s there) and understand the portion which talks about that. If I come across something trivial, I skip the documentation part and start searching in StackOverflow or blogs. This approach keeps me sane and stops me from overthinking, overdoing things, overloading myself or overspending time.
If any section does not resonate with my “Selection/Ideating” phase, I skip that section too. For example, when I was learning Java from an online tutorial I skipped the section which talked about JavaFX and learned it later only when I wanted to create a desktop application.
Lastly, it goes without saying that whatever I learn I try to record most of them in the form of blogs or code repositories. A win-win for both me and for people who read them.
I used to be that guy who would forget most of the topic after learning it, gradually over a period of time. Have you heard about the “Ebbinghaus Curve of Forgetting” ? Not so much now. Thanks to the “Active Recall” and “Spaced Repetition” concepts. As part of “Active Recall”, I open my notes or blogs, read line-by-line and try to remember the concepts by retrieving information from my brain. If I am not able to, I go through the section again from the same video or some different video and do some hands-on. There is no harm in mixing up things in this case!! If I visit the official documentation again, I ensure that I read it thoroughly and take away some more new information. Repeating this process at a regular interval, over a while, is what ensures that I do what is popularly known as “Spaced Repetition”. This helps to flatten out the “Forgetting Curve” and moves me toward the path of becoming an expert.
I hope you have enjoyed this article.