I think it's a mix of curiosity, lack of deadline pressure - and something else I can't put my finger on.
An example is being comfortable reading a dependency's source code. Once you realize you can do this by going to Github/Gilab - or even navigating to where a function is defined via your editor - you realize it's all layers 'down' and you can go in there as far as you want. Another example is using dev tools to prettify the code (but it's rarely readable).
Another thing is the payoff: how often can you deep dive and make changes to solve your problem? This determines if the reading through a huge library is worth it.
Starts with curiosity but requires lots of time available and a bit of confidence that the endeavor could lead to a solution.
> I think it's a mix of curiosity, lack of deadline pressure - and something else I can't put my finger on.
I'm not sure I agree on lack of deadline pressure.
There's a virtuous cycle somewhere if I squint that's fundamentals -> makes it easier to find where the problem is -> makes you more willing to dive deeper -> leads to stronger fundamentals. In parallel maybe, curiosity -> dive deeper reading other people's code / learning about software -> stronger fundamentals
This all leads to things like "I bet this is a network or protocol level issue in this dependency" -> even in someone else's large, open source codebase, I can quickly track down the problem without needing to understand the entire structure, for example. But gaining that ability to intuit takes time, especially for newer engineers.
Edit:
Technically fearless though isn't really the above example for me, it's more, if the business needs it, and we want to allocate resources, there's nothing I can't build or learn how to build in a reasonable amount of time. When you're layers and layers of abstractions up, you're constrained at each layer on what you're allowed to build. Perhaps a simple definition of being technically fearless is the ability to drop down layers of abstraction as needed to solve problems.
I think John Carmack[1] is technically fearless, for example. Known for video games, but I would hire John in any domain and have no doubt he'd be successful.
That definitely relies on a lack of deadline pressure... which is really about knowing that your team lead trusts your judgement in how you allocate time.
An example is being comfortable reading a dependency's source code. Once you realize you can do this by going to Github/Gilab - or even navigating to where a function is defined via your editor - you realize it's all layers 'down' and you can go in there as far as you want. Another example is using dev tools to prettify the code (but it's rarely readable).
Another thing is the payoff: how often can you deep dive and make changes to solve your problem? This determines if the reading through a huge library is worth it.
Starts with curiosity but requires lots of time available and a bit of confidence that the endeavor could lead to a solution.