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?
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:
I hope these tips help. If you find my advice helpful, feel free to follow me on LinkedIn:
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.
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:
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.
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.