I can tell you what limited my confidence as a programmer. It was correctness, or knowing how to deal with stuff so I don't have to check every line of code once I implemented something new that uses the old stuff in a novel way. For some people, it was apparent right away, but I had to discover that once you design something that works in all cases, you don't have to check wether it works as a part of newer code flow, or bigger use case. Only then my confidence started to compound.

In the late 90s to early 2010s it was fashionable to think of code as a graph of dependencies, and as long as you honor those dependencies when changing the code you would be ok. This is simplifying but pernicious POV IMO - reinforced by the zeitgeist that code is truth and comments (in code or otherwise) may not be. This is a cul-de-sac.

Unless developers see things as nouns or verbs, they don't acquire the ability to scale and see the bigger picture, because there is nothing to hold these smaller entities and connections between them (O(entities^2)). The concepts are the bags. Wish someone would explicitly teach us these things, because, sure as hell they didn't teach it in college.

May be people who have a liberal arts background are good at seeing these things, because one of the things they explicitly study is perspective, framing etc. Engineering is quite limited because we don't explicitly study about that.