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.

I don't know the details, but this could exactly be the proof, not the counter-proof. They do different things, but they may not perform ordinary jobs very well. What if we ask John Carmack to play with CSS, move those pixels so the UI looks "perfect"?

The hard part for me is then translating his ideas into vectorized numpy for speed, but at least I get the right answer to check against.

- Think through and write on paper in pseudo code first;

- Run written code in head, or on paper if they don't have the capacity, a couple of times before pressing that BUILD menu item;

- Restrain from using libraries if a custom, better solution is possible;

But then I think, it probably doesn't make a lot of sense if you work as a frontend pushing out JS, or as a data eng writing Python code which calls some Scala code which runs in JVM which is highly complicated, because the whole industry is "AGILE" and the chain is way too long. You need to get into the right job, to nurture such a mindset. The old timers got lucky. They started with 6502 bare metal.

That's why I'm pushing myself to get out of Data Engineering, to do something lower level, until I get deep into the basement. I probably won't succeed here but it's fun to try.