Taro Logo
92

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

Profile picture
Anonymous User at Taro Communitya year ago

When learning new things, I often find that I don't know this, don't know the best practice in that, and so on. If I go down these rabbit holes, a lot of time is spent and not much progress is made in the original project. If this is a scene at work, usually there are external factors to guide you not to go down these rabbit holes, be it the deadline on a task or advice from colleagues. But how to manage this while building side projects? Especially, time after work is equally precious that you sacrificed doing other things to build a skill, and progress gives motivation. But at the same time, going down these knowledge rabbit holes also builds knowledge, and be more niche. How would you trade off knowing everything vs progress in side projects?

4.7K
2

Discussion

(2 comments)
  • 42
    Profile picture
    Senior Software Engineer at Series C Startup
    a year ago

    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

  • 85
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    a year ago

    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: