How to avoid going down the rabbit holes when learning new things?

I strongly believe that all learning must be tied to action, especially when it comes to software. Otherwise, it won't stick, and your time will have been spent inefficiently. I cover this in-depth in this discussion here: "How do you manage knowledge you gain from reading?"

I like how you mentioned rabbit holes as this is a trap I've seen many software engineers fall into. As mentioned before, you can evaluate whether a learning "rabbit hole" is worthwhile by seeing how tied it is to action. Here's an example of a good rabbit hole vs. a bad rabbit hole.

Good Rabbit Hole - Debugging

Let's say you are a front-end engineer with a super classic bug: The UI isn't showing the thing you expect it too. You start diving into the issue, which leads you down the following path:

• You check the rendering code - When the UI layer receives the data model, it draws the proper components. It is good and not the root cause of the bug.
• You check the code parsing the API response from the server - The JSON sent by the server isn't getting mangled by the client. However, you realize that the sent JSON by the server isn't what you expect... You have found a downstream issue but not the root cause.
• You check the API layer - Your journey has now taken you to the back-end. After talking with your back-end teammate and having them break down how the server constructs the JSON to send to the client, you debug the endpoint together. The logic converts models into JSONs just fine, so the issue must be even deeper...
• You check the database reading layer - You work with a database infrastructure engineer on your team to go over how the back-end logic is querying your system's underlying SQL database. Aha! It turns out that the query for this endpoint isn't converting the pulled SQL row into a proper model to pass to the API layer, passing a 0/1 instead of true/false for a boolean value.

This debugging path led you down a deeper and deeper journey where you organically unraveled the many layers of your team's entire stack. You collaborated with teammates and went through each piece of the system in a directly relevant context (i.e. "How does it contribute to the flow of my bug?"). Since all of this learning was directly tied to an outcome, all the knowledge you gained here will be much more seared into your mind. Humans are terrible at remembering raw knowledge, but they are great at remembering experiences. This debugging experience is what allows the deep system knowledge you gained to thrive within your brain.

Bad Rabbit Hole - Aimless Code Reading

You are an Android engineer, and you write a beautiful chunk of code to make an API call with the famous networking library Retrofit. You think it would be cool understanding how it works "underneath the hood", so you command-click into the library's source code and start reading through it.

After an hour of reading through layers upon layers of abstraction you don't understand, you stop, not having really learned anything. It turns out that reading thousands of lines of code written across several years and dozens of versions is extremely hard. After a few weeks, you forget everything you consumed from this experience.

This rabbit hole was bad as it wasn't tied to action - It was done "just because" and naively optimistically.

In conclusion: It feels good to unwrap abstractions, but you should only do it when you have a concrete reason to. Software is infinitely complex, and it evolves extremely quickly. This means that there are an infinite number of abstractions you can unwrap, almost all of which are useless to you. Pick your battles and only unwrap those that will help you accomplish things - Only then will the wisdom stick. So if you have a cool new feature you want to add to your side project and you can't figure it out with your current understanding, then it makes sense to go deeper into the surrounding system.

Related resources:

• "How can I root cause bugs faster?"
• "How can I become more independent and better at unblocking myself with tricky technical issues?"

This is a great question, and one that I often struggle with as someone who loves to read books and take tons of highlights and retain only a few things.

I think I've found my groove at this point though. Here's my advice:

1. Let yourself know that it's ok to go down those learning rabbit holes. Life isn't all about the side projects you accomplish. If you're having fun learning, let yourself enjoy it.
2. With that in mind, it's important to make sure you are actually learning. There are a bunch of approaches to this. Here's a few...
   1. Build a second brain from what you are learning: https://www.youtube.com/watch?v=K-ssUVyfn5g. Take notes and categorize to better your retention.
   2. If reading a book, use Readwise so they refresh you on your highlights, and read with the goal in mind of getting little snippets you will be reminded about that will be valuable to you.
   3. Reverse your learning. Focus on the side project, and when you hit a roadblock, do some learning. Once you got yourself past that roadblock, continue on the side project.

I hope these tips help. If you find my advice helpful, feel free to follow me on LinkedIn:

www.linkedin.com/comm/mynetwork/discovery-see-all?usecase=PEOPLE_FOLLOWS&followMember=jordancutler1