It is not the defining characteristic of "10x developers" like Carmack. He's of an especially rarified sort and not really someone to look at as a role model in the first place because his experience and background is so idiosyncratic.

What we're talking about here is just an essential characteristic of "competent developers" and is among the array of characteristics that distinguish early-career developers from more genuinely senior ones. Your stepwise growth of the skill is very highly correlated with what value you'll provide as a developer (and therefore what roles and rates you can pursue).

Next time you encounter a frustration like you found in (2), don't just blindly update ImGui and hope for the best. If you think it might be the problem (a great insight because you were modeling it!), open your local version of ImGui and see if you can find where it's a causing problem, because you're now going to be very invested in reading ImGui closely (to find the issue) and you're going to learn so much that will help you better model ImGui in the future, as well as better model other utilities.

After you've put some effort into that, and hopefully even found the issue (but perhaps not), then go to GitHub and try to use changelogs, issues, PR's, etc to see if you can find some specific commits that might be related to the issue. Analyze those commits yourself and see what you can learn from them, improving your understanding about utilities like ImGui and how they're implemented and where bugs like the one you encountered might lurk so you can track them down more quickly in the future. Only then should you consider updating your local version.

And while you might be reading this and thinking "who's got time for that?!", it doesn't really take that much time once you get the hang of it through practice, and every time you do it, you're making huge investments into your own proficiency and value (-> future roles and rates). Don't skimp, just do it!

(As for #1 - "getting tired" -- aspiring athletes, whether professional or amateur, get tired during training too. And that's okay, because again, it's all a process of development and growth. To train, you push as far through the tiredness as you can, and then make the compromises you need to, always trying to push yourself a little bit farther before you do. By doing this, that wall of tiredness moves further and further out and you become that much more capable and productive.)

> what supporting utilities it references, how those utilities work and what constraints they impose

The responsibility isn't to memorize and model every function called up and down your whole stack. Often, you don't even have full insight into that if you wanted it and of course you couldn't hold that all in your head even if you wanted to. But you don't need to.

The responsibility is simply to thoroughly understand how each function you call works insofar as you're using it.

You should be confident, not hopeful, that the state you've arranged for that function call is a valid state for it, you should have a informed, not incurious, sense of its general behavior characteristics (fast or slow, high or low resource demands, thread safety, etc), and you should be able to make informed predictions about what its output should like given the state you pass in.

It's actual implementation will often be opaque, or at least opaque at some depth, but between the function's documentation, any access to its source, and your own insight of how something like that function would likely or necessarily implemented, you can and should be able to fully model it for the purposes of your own invocation.

If you work close to the metal you only have 1-2 levels of abstraction. If you need to call a library which calls a library which calls a VM which calls some syscall you simply don't have the brain to trace down all those -- plus you are not allowed the luxuries of tracing it down because the ticket is wanted ASAP.

Getting the right job is the only thing needed to take you away from this hell.