The challenge

In today's fast-paced technological landscape, staying up to date with the latest developments in frameworks has become an essential part of our daily routine. Just the other day, I revisited some documentation I had used about a month ago, only to find a variety of changes, updates and new features. I felt I had to re-write some parts of my code just to stay in the loop.

Equally often at work, I have to do tasks using a new library or framework. While I concentrate on solving a specific issue, I might still feel I am missing the bigger picture once the task is complete. It's frustrating to have this "patchwork" understanding, where you grasp various bits and pieces, but cannot quite see how everything fits together as a whole.

This is why I am always trying to be vigilant and adaptive. So, what is the most effective way to keep learning new things without getting (too) overwhelmed? 🤔

Approaching learning

Depending on your personal preferences, you might feel more at ease either by first absorbing all the theoretical information before diving into a project or by jumping straight into building something while you are still figuring out the details.

Active vs Passive learning

In passive learning, the learner absorbs information without actively engaging with the material. When you listen to a lecture or read a book, you receive data that you do not necessarily process at the same time. This is why note-taking during lectures is so important. You solidify the knowledge by going back and re-living the process of receiving the information through your notes.

In active learning, on the other hand, the learner actively participates in the process. The theory might not be there first, but instead, you get to figure it out by solving a problem, discussing it with others, trying things out, failing and starting again till you get it right.

Finding balance

Finding a good balance in distributing time between passive and active learning can be a task in itself! I used to feel more confident having a theoretical background on a topic but realised pretty early on that this does not always translate to better coding by itself.

I remember when I first started learning React, how I'd spend hours reading and watching courses trying to understand the lifecycle of components. The first time I started understanding these concepts was when my useEffects were not working as expected, either by unstoppably rendering something or by not rendering something at all (React devs, I know you've probably been there too 🥲).

In this case, I had to shift my efforts towards more active ways to engage with the material. Active learning can be frightening at times because it requires you to fail again and again till you have your big breakthrough. Building something that works requires you to define the problem, split it into smaller ones, and find these weird edge cases that keep breaking things randomly and give you lots of headaches. Your code will force you to read that documentation again in context, rather than in an abstract theoretical way.

So, how do you break the barrier between consuming information and actually putting that knowledge into practice?

The goal is important

Taking some proper time to define my goal correctly has helped me a lot in managing my learning. Before I start working on something new, I ask myself:

1. What's my motivation for learning X?

2. Are there any related technologies I am already familiar with?

3. How deep do I want my understanding of X to be?

4. How much time am I able to allocate for learning X right now?

5. How does learning X contribute to my self-improvement?

By answering each one of these questions, not only I can correctly allocate time and resources but even decide when it is the right time to delve into something new.

I want to learn ...

So, let's say you want to learn Django!

This statement is rather vague and might not inspire you to get started. So, I will attempt to address the questions mentioned earlier for this particular example:

1. What's my motivation for learning X?

   You might have been working in one specific technology for a long time and now want to explore something new, Python in this case. You may want to experience building some of the things you already know (e.g. an API) with another framework.

2. Are there any related technologies I am already familiar with?
   For instance, if you're familiar with creating an API using Node.js and Express, you can apply some of that knowledge when working with Django.

3. How deep do I want my understanding of X to be?
   You may be interested in learning the basics for now, creating simple endpoints and experiencing some of the main tools offered by the framework.

4. How much time am I able to allocate for learning X right now?
   If you only have some spare time in the upcoming two weeks, it's better not to plan for learning materials that require more time to complete, as they might end up unfinished.

5. How does learning X contribute to my self-improvement?
   This will help you understand the concepts of API more universally. Since you know how to develop this with Javascript tools, doing it in another language/framework will help you decouple the concept from the implementation. That means an easier and smoother learning process if you decide to learn to do this in Java or Ruby a year later.

Tracing down the right material

I honestly find this part the most challenging and it can often be a matter of trial and error.

What's wrong with the docs?

Somebody could argue that reading the documentation should be the first step. Although I consider myself a huge documentation advocate, I find that this is not always the best choice when you are picking something up for the first time.

I am sure I am not alone in thinking that many of the official docs are not always written with the average user's interest in mind. Maybe you have heard the term "curse of knowledge" before, which refers to the cognitive bias of an individual that has a deep understanding of a particular subject but finds it extremely difficult to communicate it. I find this is quite often the case with people writing official documentation. The writer often assumes that everybody reading them shares a similar level of prior knowledge or even interest for that matter on the subject, which is not always the case. Sometimes you just want to bootstrap your project and see a simple message on your screen. But if the docs cannot help you get past that very first step, how are they even supposed to take you to more advanced concepts?

(Just want to make it clear that there is also lots of good documentation out there which is extremely intuitive and helpful. We have also recently seen many teams releasing updated or completely rewritten versions of their docs, to meet the users' current needs, new best practices, etc.)

Online courses - empathy in learning?

And this brings the next point forward: empathy. I sense that this is one of the main reasons online courses are so popular (regardless of the hosting platform). I have noticed many instructors even have their own following if they possess the winning qualities of engaging delivery, storytelling and motivating attitude.

This unveils a fascinating aspect of learning: we do not necessarily learn from the source that has the most "correct" information, but from the source that can convey it instinctively (even when the information might not be entirely correct or complete in the traditional sense).

I would say that if you find an instructor that helps you understand things on a certain level, stick with them. The more you get familiar with the subject of your choice, the more you can go back and integrate tighter processes to refine that knowledge, such as deep diving into the docs or reading that super technical book.

Example repositories

Sample repositories (for instance, on GitHub) serve as excellent educational resources. By examining these, you can learn about project architecture, code organization, and specific patterns and techniques. Comparing various implementations of similar ideas can provide valuable insights into a particular technology, enhancing your comprehension of its capabilities, limitations and common issues.

"Real world" React repositories

As a suggestion, you can search for "repositories to master X technology," and you'll be presented with a variety of options.

React coding challenges

Manage your expectations

Another important aspect here is to have a clear idea of what it is that you expect at the end of a learning cycle. Expecting too much is equally unhelpful as expecting too little, in the sense that you do not get to properly evaluate your progress.

If you aspire to build an extremely complex system in a week, that's probably not going to happen. Developing the stamina to keep learning something over a longer period of time is a very useful skill. Breaking down a complex task into pieces and working on it one piece at a time will help you get further without getting overwhelmed.

Working in cycles

Much like in software sprints, you can apply the same approach to learning. Once you have found the right material that works for you, you can assign the necessary number of days needed to go through it.

You can split your available material into tickets: in each ticket, you can add a brief description and the goals you want to achieve upon completion. Feel free to tag them as well, so you can navigate easily among different references during studying time.

While this method may seem a bit tedious, it enables you to track your progress and easily find references. It also serves as a means of self-accountability, allowing you to evaluate your own performance, identify and address any gaps, and ultimately enhance your skills.

A practical example

Before wrapping things up, I'd like to share a personal example with you. As learning plays a significant role in my everyday life, having an efficient system in place to streamline the process is very important for me and helps me be more efficient and calm.

Imagine you've been given a task

One of my recent learning projects is building a fully functional message board app, where users can post, like, and comment on messages, as well as talking privately with other users. I am trying to be playful in what I want to build, and be imaginative when designing it! Having fun when learning keeps me motivated and boosts my spirits! 😄

Setting things up

In this case, I am exploring managing a bigger project from the very beginning, setting up everything and working on all features end-to-end. My ideas keep expanding the more time I spend on it and the more I learn about the tools I am using. Regardless, I work on it only one week at a time, so that I have time to properly absorb new concepts, revise properly and generally have a break in between things.

For this, I initially spend some time setting up a GitHub repo, which I treat just as any other project. If I have front and back end, I will usually opt for a monorepo, since I find it easier to manage. After the initial setup, I deploy the project right away. As I'll be branching out to develop various parts of the application, this approach ensures that I have preview links readily available and can promptly identify any potential deployment issues.

GitHub repo of a messaging app I am currently building

Vercel deployment of the same app :)

Divide and conquer!

I personally enjoy using the same tools I use for my tickets like the GitHub Kanban board or Linear. I split the original task and add all available material there: descriptions of expected behaviour, documentation, helpful references as well as exercises I want to practice with. For each item, I note down my objectives in a dedicated section, so I know when to consider something complete. Whenever I start working on a new feature, I create a branch from main and I mark the corresponding ticket as "In progress" in the tool I'm using, and once it's finished, I tag it as "Done".

I use Linear to create, organise and track my tickets

Note-taking and documenting

I feel most of my personal learning happens here :) Let's say I am building a certain functionality, so I researched, looked the docs up, checked a couple of instructional videos and finally found the solution and put the code down!

A week later I will probably remember only 50% of the process of getting to the solution. A month later, probably 10%?

See where this is going? 😅

To make sure I make the most of this process, I write everything down! This happens in two different places:

• READMEs and inline commentary, for code-specific information and

• Notion for the general concepts that occur as part of this process and can be universally applied elsewhere.

Another process that I find particularly helpful and falls under the second category is documentation on my PRs. This makes referencing things much easier and finding potential issues that were probably overlooked in the past. (This is also nice for other developers who might later work on the same repo and want to build new features :))

This is what my "Code Treasury" looks like - I love Notion!

"But if the code is clear enough, you don't need commentary!"

I find this statement unconvincing and see it as a weak justification for reluctance. It's unlikely to find two developers with identical preferences; some may avoid writing comments altogether due to personal conviction, while others could be careless or simply dislike having their code "tainted" by comments.

Even well-written, clear code may not always convey the context in which it was written. In larger features, adding brief comments to explain various parts of the code can be highly beneficial, not just for the team, but also for the author when revisiting the code in the future! Indeed, this is another valuable tool in our learning toolkit! :)

Revise, add, repeat ...

To make the best out of this process, you have to go back and revise! I like to approach my revisions through spaced repetition. Spaced repetition is a learning technique where you review material at increasing intervals of time. The better you remember the material after a reviewing session, the longer the interval can be until the next review.

Now, to be realistic (and honest!), I do not count the days between intervals. Quite often, I need to go back to review something I am currently building at work, so revisions happen organically. However, what I enjoy doing is setting aside time on weekends for this. I typically choose a project I've previously worked on and revisit my Notion notes. Additionally, I may explore more online resources, such as videos and documentation, to strengthen my understanding and gradually expand my knowledge.

I recently revisited the example project I mentioned above after almost a month of inactivity on it. The first thing I did was to check the last branch I had merged in. Through this, I traced the Linear ticket and then all the notes in my Notion database. This allowed me to pick up where I left off quite quickly without any issues.

Notes on how to use Context in tRPC

This time I had a look at how the context data related to authentication is being retrieved, managed and passed into the tRPC routes. I feel that this particular process has started settling in after a few months since I started working with tRPC, so I am more comfortable using this configuration. This time I was also prompted to do some extra digging into the cookies vs sessions approaches in storing state information and expand my knowledge on that front.

Wrapping up

Hopefully, you got some useful info by reading this! Keeping up with all new technologies can be challenging, but the right approach will help you stay up-to-date without feeling overwhelmed. By finding a balance between passive and active learning, setting clear goals, and identifying the right resources, you can efficiently acquire new skills and knowledge. Remember to manage your expectations, take notes, and revise regularly to reinforce your understanding. By following these tips and techniques, you can become a more efficient and confident learner, ready to tackle any new challenge that comes your way.

I am aware that was a long read, so kudos if you reached the end! I would be really curious to see what is your approach to learning new things and what you feel works best for you. Please feel free to write in the comments, will be happy to see you there :)