I think this not generally. I worked together with this amazing engineer, but he really struggled to sometimes explain what he was trying to do. He came up with great solutions, but often took us some time to figure out what he was trying to get at.
An example from something I've had to iterate on: When explaining an event loop multiprocessing runtime sort of thing, I eventually found I had to hand-wave "and your CPU hates that" to establish an appropriate premise to the problem and solution (referring to item-by-item dynamic dispatch with a large number of task types as the specific demon which needed to be slain while discussing that subset of the design). People in the know didn't need more understanding. People not in the know were happy to brush their lack of microarchitectural understanding under the rug. With that premise, both crowds were able to understand what followed.
That wasn't my first attempt. I have a bad habit of trying to explain those missing details as well, especially when it's clear the listener doesn't know them yet -- trying to get them into a position where they could've built the thing themselves -- but that only lands well with like 1-5% of people I've met.
Critically, agreeing with you, that's a communication failure, not an engineering failure. I understood the problem just as well in both cases; I just didn't understand the full extent of the people problem.
You can do things extremely well without having the foggiest about the actual underlying principles, just from observations and intuition. Doubly so if the process can be machine automated, which by this point encompasses nearly everything to some extent. Sufficiently advanced overfitting is indistinguishable from generalization.
Binary is very simple, but scaled up: look what we've created with software.
When it comes to explanation: pulling from rote memory, requires someone to attempt to hold all the short-term details in mind.
There are biological limitations to how well we can do this, but we can also exercise our brains to improve this ability.
But when something is deeply learned, in long-term memory, the effort of recall is much less than rote memory of short-term details. Our context window is limited, fills up, and we must recover. When you're remembering long-term details, context seems easier to swap in and out (sorry to sound like an LLM, but they do simulate thinking).
Whether or not someone is a master of any given domain of knowledge comes from demonstration. Maybe that is teaching the essence of a subject in a way that demonstrates you can visualize and move around the subject with ease. Or maybe you can create something very useful, or tasteful.
We accept that you have spent time in this area and probably can revral truth to us. You are credible.
If you can't demonstrate mastery through teaching, exchanging ideas to bring me closer to your level: them other forms of credentials are sought: like how well they code, or how useful their products become.
But life isn't about usefulness and will just lead to unhappiness. Just be the best version of yourself you can be. Life is too much to understand all at once.
Up to the limits of the Goedels incompletness theorem.
Dependenting on the used notation the formal proof can be very long. For example, Principia Mathematica took about 300 pages to prove that 1 + 1 = 2.
https://commonplacefacts.com/2022/07/27/principia-mathematic...
Yeah, there's this thing called the curse of knowledge. If an engineer has a deep understanding of something, it's not a given that they can explain it well. For them, the topic feels so simple, and they've done it so many times that they may have forgotten other people aren't as knowledgeable. They will throw terms around without explaining them, etc.