This is a wonderfully lucid and subtle comment. I think any earnest programmer who wants to get better would do well to study your contributions to this thread

This is a wonderfully lucid and subtle comment. I think any earnest programmer who wants to get better would do well to study your contributions to this thread until they are sure they understand them. For a domain expert in their domain of expertise, [long explicit names] are overhead. Once you pass a certain threshold of complexity and/or time-investment, a well-designed program becomes its own domain of expertise. At that point there is great leverage to be had in finding a compact notation suitable for the recurring concepts of the system. In some ways, finding such a notation is how one ensures that the system has a good design and will keep it. As you point out, it (critically) is what enables us to keep more complex things in our heads. It also becomes an intimate part of the creative process – a good notation suggests new concepts and hints at how the system should grow. Long explicit names are exactly what you don't want when it comes to the core concepts of a well-designed system. They are useful for things that aren't familiar and so need to be spelled out. But in a well-designed system, the most important concepts are familiar and it is a poor use of our limited cognitive capacity to constantly spell them out, for much the same reason that we prefer to say "gas" instead of "liquid hydrocarbons". Since cognitive capacity is our principal bottleneck in software, this is a big deal.