Have you ever thought this before? Or any of the following?
What if, instead of thinking the above, you thought:
But how do you get to that point? What strategies are available?
What if the senior engineers on your team don't have time to mentor you?
What if the code your team writes isn't the level of quality you aspire to?
What if your company tasks you with so much work that you have no time left for learning?
Will the things I learn even be useful in my current / future job, or are they just parlor tricks for geeks?
Do I even want to work for a company which would prioritize solving these puzzles, vs. real-world skills like building applications?
Can I afford to take time off work for that long?
Can I afford the associated cost?
Once I graduate, will I get help re-entering the workforce, or will I be on my own?
Are the skills they would teach me practical and useful, or are they all theoretical?
What if you have a family to support and don't want to roll the dice on a new job?
What if you like your team and don't want to roll the dice on a new boss / new set of coworkers?
What if the economy is in a slump and the job market isn't favorable right now?
What if you've tried that already, and ended up in "tutorial hell"?
What if the only tutorials you can find are "Hello world"-style toy apps?
What if there are no tutorials out there for the technology you want to learn?
Instead, use the best "tutorial" out there- open-source code from widely-used libraries.
Even better, contribute to those libraries. Then you can walk into a job interview and say "Do you use Library X? Then you use code that I wrote. I've already contributed to your company's codebase."
"The other thought that has come to mind is to try not to worry about it and try and find fulfillment outside of work."
Any employer who is worth their salt knows that you as a job candidate are unlikely to be 100% familiar with every component of their tech stack. Instead, they look for:
It's this meta-skill of learning-how-to-learn that's most valuable to practice. Engineers who possess this skill don't fear applying for jobs whose requirements include new languages, frameworks, or 3rd-party tools, and they don't have a constant, low-grade fear that the next new hotness will replace the tech stack they're currently familiar with, because they know how to quickly ramp up on those things.
What if your teammates considered you the go-to expert on how your libraries work, because you know their internals so thoroughly?
What if you could arm yourself with the best practices of some of the world's best engineers, because you had analyzed their techniques in real-world codebases?
What if you could not only employ those techniques yourself, but teach them to your team as well?
What if you could confidently explain how the internals of a language like Ruby or Rails work, to job interviewers, teammates, and anyone else?
What if you never again had to worry about your team adopting a new library, because you had a repeatable process for learning the internals of any codebase you want?
What if you had the ability to not only read and learn from code from world-class open-source developers, but contribute to it as well, in effect becoming one of their peers?
Would you still feel like an impostor then?
In my walk-through of the RBENV codebase, you'll learn: